W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

RE: If not Multiple-Contents, how do we have Widgets with multiple modes?

From: Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com>
Date: Thu, 19 Feb 2009 13:20:25 +0100
Message-ID: <0BE18111593D8A419BE79891F6C46909028E7844@EITO-MBX01.internal.vodafone.com>
To: "Marcos Caceres" <marcosscaceres@gmail.com>, "ivan.demarino" <ivan.demarino@orange-ftgroup.com>
Cc: "public-webapps" <public-webapps@w3.org>
Hi Ivan, Marcos, All,

Some specific comments inline, marked [mp]. I will send out a separate
email outlining a proposal that we believe meets the requirement around

A more general comment - from Ivan's email, a requirement I would add to
the list I communicated in [1] is:

"A widget MUST be able to adapt its layout in response to the mode in
which it was initialised."


[1] http://www.mail-archive.com/public-webapps@w3.org/msg02038.html

>-----Original Message-----
>From: public-webapps-request@w3.org 
>[mailto:public-webapps-request@w3.org] On Behalf Of Marcos Caceres
>Sent: 13 February 2009 13:27
>To: ivan.demarino
>Cc: public-webapps
>Subject: Re: If not Multiple-Contents, how do we have Widgets 
>with multiple modes?
>Hi Ivan,
>2009/2/9 ivan.demarino <ivan.demarino@orange-ftgroup.com>:
>> Hello.
>> I'm following the specs evolving for Window Modes 
>> Given the fact that the "content tag" has an occurrence of 
>"0 or 1", and the fact that the "mode" is one, my question is:
>> - Would it be possible to have widgets that have "multiple views"?

[mp] IMO yes, in a number of different ways. I will send a separate
email explaining how.

>> I dug into the "widgets-api", and what it looks like is the 
>fact that the only place where the widget should handle "mode 
>change" is the call-back named "onmodechange()".
>> That's fine.
>> But we are assuming that there is an "initial mode" chosen 
>by the Developer and that the widget "change it's shape" based 
>on the event "onmodechange".
>> - What if the Developer can't know in which mode the Widget 
>will start?

[mp] This is obviously a requirement that needs to be addressed. Note
that it could be done using media queries or by querying the
widget.viewmode attribute in javascript.

>We could make it explicit that the widget user agent should 
>attempt to start the widget in the mode the author declared 
>(or in floating, as is the default).

>> - What if the "User-Agent" running the Widget does not pass 
>a "onmodechange", because NO MODE WAS CHANGED: it was simply 
>initialized with a mode different from the one chosen in the 
>We could specify that a user agent must fire a mode change 
>event if it initializes the widget in a mode other than the 
>default or the mode that the author specified.

[mp] IMO it would be better just to fire an event or media query
whenever the widget was initialised, whether or not it was opened in the
preferred mode.

>> It's a bit "tricky" to explain, but I can give more details 
>if needed.
>If the above would not help, then more details would be 
>helpful to build a use case.
>> One of the great thing of having "widgets with multiple 
>modes", is the fact that the same widget can run in different 
>scenarios, based on the hosting platform screen resolution AND 
>other requirements. The widget has to adapt itself at "load time".
>> A widget that, for example, run in "window mode" and just 
>after load has to change to "docked", because that's the mode 
>supported by the current User-Agent, will look "clunky" and 
>"not seamlessly integrated".
>> What do you think?
>This may be true. Can you go into more details about how we 
>might overcome this? is this an author's problem or a user 
>agent problem?
>what more can we do on the user agent side to overcome this issue?

[mp] I would suggest that if the user agent only supported docked mode,
it would open the widget in that mode (not window mode) and the widget
would adapt its content accordingly.

>Kind regards,
>Marcos Caceres
Received on Thursday, 19 February 2009 12:21:26 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:14 UTC