Re: [widgets] A revised proposal on widget modes

Hi Mark,

On Thu, Feb 19, 2009 at 2:36 PM, Priestley, Mark, VF-Group
<Mark.Priestley@vodafone.com> wrote:
> Hi All,
>
> Based on some of the emails that have followed our initial proposal for
> widget modes [1] we have come up with a revised proposal for discussion. I
> have focused this solely on what would need to go into the packaging and
> configuration specification [2], ie there is no real mention of how viewmode
> transitions would be handled.
>
> Comments and suggestions welcomed!
>
> ---------------------------------------
> Proposal:
> ---------------------------------------
>
> 1. Remove height and width attributes from widget.

Agreed. I think these need to be dropped all together as they are
unnecessary. I would argue that this needs to be controlled by CSS.

> 2. Remove mode attribute.
>
> 3. Add a viewmodes element, along following lines:
>
>
> <viewmodes default="floating/fullscreen/docked">
>
>     <floating height="300" width="500"/>
>
>     <fullscreen max-height="500" max-width="600"/>
>
>     <docked min-height="50" min-width="70"/>
>
> </viewmodes>
>
> ---------------------------------------
> Explanation
> ---------------------------------------
>
> All modes would use the same start file - there would continue to be
> only one content element.

Great.

> <viewmodes> would be an optional element. If it was nor present the widget
> user agent (WUA) would use default height and width values for each of the
> viewmodes that it supports.

Like I said, these width and height attributes don't make much sense.
I think it would be better if the width and height was controlled by
CSS. The only use case for width and height that I see to set the
proportions of a widget. In Opera, they are to set the render context,
so anything that is outside the render context gets clipped. This is
bad because authors just make the width and height of widgets really
big, say 1000*1000 to avoid their widget getting clipped.

> The "default" attribute indicates the widget authors preferred viewmode for
> the widget. If the default attribute was omitted the WUA would use its
> default "default viewmode". The WUA would be entitled to ignore the
> default attribute value, for example in order to maintain a consistent user
> experience.

Right. I still think there should be only a default start mode and
then mode switches should be controlled by the WUA or by JS. When the
WUA changes the mode of a widget, the events get fired and CSS media
queries kick in.

> The <floating>, <fullscreen> and <docked> child elements of <viewmode> would
> all be optional elements. If any or all of the child elements were omitted
> the WUA would use default height and width values for those viewmodes
> that it supports.

I personally don't like these. Like Josh said, just for extensibility
it would be better to have a single <mode> element.

> The presence of <floating>, <fullscreen> or <docked> would indicate that the
> widget had been designed to run in this mode.

This could just as easily be indicated by having the appropriete media
query (i.e., you only have media queries for the formats you support,
and not for the ones you don't)

> If the (x-)height and/or
> (x-)width attributes are omitted from any of the child elements, the WUA
> would use default height and width values for those viewmodes. Note that for
> the fullscreen mode it is max-(height/width) because the expectation is that
> a widget author will design their widget to display correctly up to a
> maximum size.

I think you mean a minimum size (like in web pages, you don't usually
design for the browser window being squished to a width of 20px,
though that could be handled by a media query!). Again, I think this
should be left up to the widget user agent and handled by media
queries.

> The WUA would be expected to use the maximum space available
> up to this size. It would be down to implementation whether or not the WUA
> maintained the aspect ratio.

Like I said, this seems opposite to how most web pages work (and
indeed most applications).

>Similarly the docked mode defines a
> min-(height/width) as it is the expectation that the widget author will
> design their widget to display correctly down to a minimum size. Again it
> would be down to implementation whether or not the WUA maintained the aspect
> ratio.

Again, the concept of "size" is weird here because we are talking
about CSS pixels, not real pixels. In the case of CSS pixels, a lot of
interpolation will be taking place. What might be interesting might be
to force the rendering engine not to use CSS pixels...

> The WUA may still choose to display a widget in a viewmode that has not been
> declared.

Right.

> In summary the viewmodes element provides information to the widget user
> agent on how best to display a widget. It should be viewed as guidance to to
> the widget user agent rather than an instruction. It is expected that the
> widget would be able to adapt its content to its current viewmode, eg
> by using media queries and/or javascript + mode related events +
> widget.viewmode attribute.
>
> ---------------------------------------
> Comments
> ---------------------------------------
>
> I'm not stuck on the names of the viewmodes and their respective elements.
> For example, I am inclined to agree with one of the earlier comments that
> "maximised" might be a better name for "fullscreen".

I'm also not precious about naming.

> I did think about suggesting that the <floating>, <fullscreen> and <docked>
> should be child elements of the content element but I think it's neater to
> have it as a separate element. Happy for other suggestions of where these
> elements could go or how they could be re-structured.

Thanks for this input Mark! It's been a great way to start discussion.

It would be really helpful if people could put together a 5-10 minute
presentation of their ideas wrt window modes for the F2F.

Kind regards,
Marcos
-- 
Marcos Caceres
http://datadriven.com.au

Received on Sunday, 22 February 2009 21:47:44 UTC