Resolving differences between proposals on view attribute, content height/width, and content concatenation.

[Henry Stapp]

Hi All,

There have been several threads dealing with multiple views, content
concatenation, and content height/width. This message attempts to
resolve some of the differences between them, to hopefully move
towards a unified final proposal we can incorporate into 0.8.

---- View Attribute -----
a) Both "*" and "all" have been suggested as new values of the view
attribute on the Content element. The intent of these values is
indicate that the content within (or referenced by) the element should
render in all views. We propose that we adopt "all" as the new value
for this purpose.

b) Allowing comma-delimited lists of values in the view attribute has
been suggested. The intent of this is to allow content to be rendered
in multiple views without requiring the creation of multiple Content
elements. However, with the proposal for allowing content to be
included by URI reference, the creation of multiple content elements
becomes less of a burden. We propose that the view attribute be
limited to single values only.

---- Content height/width ----
a) Both height/width and preferredHeight/preferredWidth have been
suggesed as the names of a new attribute on the Content element. We
agree that the new attributes on the Content element should be named
preferredHeight/preferredWidth.

b) Where preferredHeight and/or preferredWidth is specified in more
than one Content element that applies to a view, both the first
occurence and the last occurence have been suggested as the ones to
use. We agree with the proposal that the value from the last
applicable occurence of the preferredHeight/preferredWidth attributes
for a given view should be the ones used.

Thanks,

Brian and Henry
MySpace

[Kevin Brown]

Everything here sounds good to me.

--
~Kevin

[David Glazer]

One question about "comma-delimited lists of values in the view attribute" -- does anyone know whether that's currently supported by any containers, and/or used by any apps?  I think the answer is yes, but don't know for sure.  (And even if so, we could decide to deprecate it; just making sure we take the current state into consideration.)

[Kevin Brown]

It's actually implemented in Shindig, but so far as I know nobody who's Shindig-based is aware of or documenting this fact.

--
~Kevin

[Cassie]

Oh geeze - this teaches me to read my email out of order.
Please ignore my comments on other threads related to this issue. We will indeed take this as the "master thread" for resolving the issues around views and height stuff like Henry mentioned.

However, Henry, there are more issues to resolve which you did not mention:

1. When there are multiple content sections with the same view type do you render only the first, only the last or do you concatenate them? Discussed here:
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/1856ea093d682c3b#

2.  Should developers have to explicitly state which views they support.. which morphed into: should we change the meaning of "default" to be clear that it should only be used to display a promo or something? (ie it shouldn't be all). Discussed here:
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/28f6e1d2638a0855

3. What does "default" mean in relation to "all"? When there is no view specified, does it come up as default or all? That was me on this one:
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/b4b7f3493426f78

Thanks.

- Cassie

[Henry Stapp]

Hi Cassie,

In answer to your questions:

1. We will concatenate all content elements that apply for a given
view, in document order.

2. Our interpretation on this is that the view attribute is optional,
and its absence is equivalent to saying view="default".

3. View="all" causes the content to display on all the views. On
MySpace, these are "home", "canvas", and "profile". View="default"
causes the content to display on a single view, which is the default
view for that container. On MySpace, the default view is "canvas".

Thanks,

Henry

On Apr 21, 3:24 am, Cassie <d...@google.com> wrote:
> Oh geeze - this teaches me to read my email out of order.
> Please ignore my comments on other threads related to this issue. We will
> indeed take this as the "master thread" for resolving the issues around
> views and height stuff like Henry mentioned.
>
> However, Henry, there are more issues to resolve which you did not mention:
>
> 1. When there are multiple content sections with the same view type do you
> render only the first, only the last or do you concatenate them? Discussed

> here:http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm...

>
> 2.  Should developers have to explicitly state which views they support..
> which morphed into: should we change the meaning of "default" to be clear
> that it should only be used to display a promo or something? (ie it

> shouldn't be all). Discussed here:http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thr...

>
> 3. What does "default" mean in relation to "all"? When there is no view

> specified, does it come up as default or all? That was me on this one:http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm...

>
> Thanks.
>
> - Cassie
>
>
>
> On Mon, Apr 21, 2008 at 9:50 AM, Kevin Brown <e...@google.com> wrote:
> > It's actually implemented in Shindig, but so far as I know nobody who's
> > Shindig-based is aware of or documenting this fact.
>

> > On Sun, Apr 20, 2008 at 11:46 AM, David Glazer <dgla...@google.com> wrote:
>
> >> One question about "comma-delimited lists of values in the view attribute"
> >> -- does anyone know whether that's currently supported by any containers,
> >> and/or used by any apps?  I think the answer is yes, but don't know for
> >> sure.  (And even if so, we could decide to deprecate it; just making sure we
> >> take the current state into consideration.)
>

> > ~Kevin- Hide quoted text -
>
> - Show quoted text -

[Paul Lindner]

On Sun, Apr 20, 2008 at 11:46:42AM -0700, David Glazer wrote:
> One question about "comma-delimited lists of values in the view attribute"

> and/or used by any apps? I think the answer is yes, but don't know for
> sure. (And even if so, we could decide to deprecate it; just making sure we
> take the current state into consideration.)

There are probably < 5 apps on hi5 using multiple comma separated
views on hi5.

--
Paul Lindner ||||| | | | | | | | | |
lin...@inuus.com

[Cassie]

Thanks for the clarification Henry. I'd like to split this proposal up into several parts to make it easier to understand where the decisions lie (without splitting this thread so that everything is together). Here is what I propose are the issues:

1. Should we introduce an "all" term that can be used in the gadget xml view attribute?
2. Should we allow comma delimited lists of views?
3. Should we introduce preferredHeight and preferredWidth as attributes on the Content element?
4. When there are multiple Content elements with the same view type what do we do?
  a) concatenate and use the last content section's attributes (ie the last content's sections preferredHeight)
  b) the gadget is invalid, we don't allow this, throw an exception
  c) the gadget is invalid, we don't allow this, just render the first one
5. What does the "default" view or no view specified mean?
  a) It is equivalent to whatever view the container chooses as the default. ie default = profile (or something)
  b) It means use the view if none of the other views fit (ie all views)


For example, here are my answers:
1. Sure, +1
2. Don't care, +0
3. Yes, +1
4. C -1
5. A +1 (although with #1 and #5a this would cause legacy gadgets to only work in the default view, i suppose that is fine?)


Okay, hopefully I made this a little easier, so it is time to chime in with your answers to 1-5.
Thanks!

- Cassie

[Cassie]

Just one last comment on this, whether a Content element should be able to refer to its contents using a url (while still being type=html) is being discussed over here: http://groups.google.com/group/opensocial-and-gadgets-spec/browse_frm/thread/237c992b35c6ce15

And this seems like it would definitely affect opinions on #2 (as Henry mentioned in the very top of this thread). For example, I'll change my answer to be the following:

2. Mostly don't care, but if we don't allow content to be included by URI reference then I think we need to support this to enable sharing between views. (because duplicate code is evil)

- Cassie

[Evan Gilbert]

May add more votes later, but
1. +1
2. 0 (we should support if there are valid use cases or if people are already using)
3. +1

[Reinoud Elhorst]

I'm not completely sure on the exact implications of 5A. Can we rephrase this as:
It will render on all views that the container specifies as default, but only if no other non-default section matches that view.

Likewise, I'm not completely sure on how the "all" section is going to be used. Will this be used for a copyright message, and some shared CSS, or is it intended for gadgets that want to display exactly the same where ever they display? In the first case, it might be wise to have it only display if the section is matched by at least one other non-all section, or containers supporting non-standard views, might end up with just displaying the shared css. Also, containers will have no way to know which views are explicitly supported (being able to deduct that from the view-sections was the main reason for not needing a separate <supportedviews> tag in the XML, IIRC)

2: Go with Cassie's second remark: Mostly don't care, but if we don't allow content to be included by URI reference then I think we need to support this to enable sharing between views. (because duplicate code is evil)
3: +1
4: a +1, c -1

1 and 5 are pending :)

[Zhen Wang]

My votes:
1. +1
2. +1
3. +1
4a. +1
4b. -1
4c. -1
5a. +1
5b. -1

[Henry Stapp]

1: +1.
2: -1.
3: +1.
4: +1 on a.
5. +1 on a.

Thanks,

Henry

> > > - Show quoted text -- Hide quoted text -

[Cassie]

Geeze, this is getting complicated.
For everyone trying to follow along here is a summary vote:

1: 4 +1s
2: no consensus
3: approved
4: A, 3 +1s
5: A, 3 +1s

So preferredHeight and preferredWidth are in. Everything else needs more opinions.
Thanks.

- Cassie

[Cassie]

Oh an Reinoud, for your statement, "It will render on all views that the container specifies as default, but only if no other non-default section matches that view." I -think- that is what we are all agreeing on. (somebody please correct me if I am wrong)

As for "all", the definition would be "It will render on all views".

Here are my guesses for how you would use "all"
- for the pro concatenation people, "all" could be a common header or footer for every view
- for the anti concatenation people, "all" could mean that the gadget thinks it supports every view in the universe, it knows it can support all views because it is pristinely agnostic to the type of view it is in (a todo list, or the time clock, for instance would be perfect examples of this - they can render anywhere and do what they are supposed to)
- for anti concatenation people this also means that a gadget would only have one content section with view="all"

I hope that helps.

- Cassie

[Reinoud Elhorst]

Thanks Cassie, you're doing a great job trying to keep it all more or less understandable :)

On Fri, Apr 25, 2008 at 2:23 PM, Cassie <do...@google.com> wrote:

Oh an Reinoud, for your statement, "It will render on all views that the container specifies as default, but only if no other non-default section matches that view." I -think- that is what we are all agreeing on. (somebody please correct me if I am wrong)

In this case 5A+1

As for "all", the definition would be "It will render on all views".

Here are my guesses for how you would use "all"
- for the pro concatenation people, "all" could be a common header or footer for every view
- for the anti concatenation people, "all" could mean that the gadget thinks it supports every view in the universe, it knows it can support all views because it is pristinely agnostic to the type of view it is in (a todo list, or the time clock, for instance would be perfect examples of this - they can render anywhere and do what they are supposed to)
- for anti concatenation people this also means that a gadget would only have one content section with view="all"

I'm not convinced on the "all", basically it has the same problem as the "default" had before. In the header/footer scenario, if some unknown view was encountered, it would just render the header/footer, and nothing in between. In the "agnostic scenario", I don't believe any gadget can claim it will render correctly on any view. I might want to create a view for non-javascript enabled, XHTML-only mobile phones (which currently is about 60% of the mobile phones out there). How can any gadget claim to support a view when they don't know what the requirements to the view are.

However, if (2,comma delimited lists of views) doesn't make it, I can see how we need an "all" section for common parts.

[Graham Spencer]

I think I'm in the anti-concatenation camp, IMO it doesn't add a lot of value. So, my votes:

1. -1
2. +1 -- although I like the proposal of referencing views by URL, I don't see any downside to also allowing comma-separated values here.
3. +1 (this one is already approved anyway)
4a. -1
4b. -1
4c. +1
5a. -1
5b. +1

--g

[Cassie]

Unfortunately, with Graham's addition this puts us at:

1: no consensus
2: no consensus
3: still approved
4: no consensus
5: no consensus

Which means that the only change that will go into 0.8 at this moment will be the preferredHeight and width stuff. It would be fantastic to resolve some of these other issues but it seems like we are going to need more time to come to an agreement. For that reason I would like to defer the discussion of all issues, except #3, to 0.9.

Thanks.

- Cassie

[Graham Spencer]

Sorry to be the lone holdout. If everybody else wants concatenation, I am happy to -1-renege (to use John's term).

--g

[jdavid.net]

in regards to real HTML width is something that many of us can work
with, height on the other hand is a pain to deal with. i would like
to KNOW that i can dynamically set the height of the app, or control
it in some way that is consistent on all containers.

some containers are doing scrollable overflow instead of supporting
gadgets.window.adjustHeight(); this is just a pain for anyone that
comes from the design world. we want to be able to control our users
experience and make sure its a great one. if you want us to be
customer centric, then you need to come together and focus on being
developer centric.

in fact it has been really hard as a developer to know which REQUIRED
features are supported at all.

I know this is a competitive space and each host has their needs, but
common guys and gals, this means that for us to deploy great apps on
multiple platforms, we need to spend a lot of time debugging/
searching/ commenting/ lurking, and much less time developing
innovative ideas.

we used to have userPrefs as part of the spec, but most of the
containers except Orkut have abandon most of gadgets namespace, even
though the v0.7 docs suggest that it is a REQUIRED feature. so for
years web developers have been making a living at websites, and if the
web is going social, then my bet is that web designers will turn into
widget designers, and that means "pixel perfect" layout will be a
requirement before brands get interested in the platform. the other
option is that brands say screw it, and do it just on one platform or
another, some of you might find success with a custom open social
implementation, but maybe that platform becomes a facebook app
instead.

right now opensocial really needs to work on developer usability, and
that means one way to control the height/ views of an app, the view,
etc..

i think i spent 8 hours yesterday just trying to figure out a file
namespace architecture that will work the same with all of the
different proxies.

if all of you do not start coming together on this, the result will be
least common denominator apps that do not do much because no one wants
to deal with figuring it out on the 70+ opensocial partners.

I really wish i could be at the summit, but since i am in the middle
of a move to the west coast, i guess i will just have to catch the
next one.

one of the reasons we started designing in flash years ago for the
social web, was that flash has better control over pixel perfect
scaling than HTML does.

lets not repeat the browser wars in the social web wars, please.