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

Re: [widgets] A proposal on widget modes

From: Arve Bersvendsen <arveb@opera.com>
Date: Thu, 22 Jan 2009 14:56:51 +0100
To: "Priestley, Mark, VF-Group" <Mark.Priestley@vodafone.com>, public-webapps <public-webapps@w3.org>
Message-ID: <op.un5vo1h8byn2jm@galactica>

On Thu, 22 Jan 2009 14:25:02 +0100, Priestley, Mark, VF-Group <Mark.Priestley@vodafone.com> wrote:

> Hi Arve,
>
> Thanks for your feedback - I'm glad our thinking is along similar lines.
> Some responses to your comments below.

Some responses below. Note that I have cut parts to which I have no direct answer yet.

>> Application mode is required outside of a mobile context, to
>> differentiate between chromeless (e.g. Opera
>> Widgets/Dashboard/etc) and widgets with OS Chrome (e.g. the
>> Adobe AIR view state model)
>>
>
> [MP] We are of course fine with an application mode being defined, we
> just
> don't have an opinion on what it should be... From your description we
> assume it will be as per the floating mode but with chrome?

There are some expected differences in behavior.

1. Floating widgets are expected to be draggable from any area of the widget, except where defined by [CSS] to not be draggable. 'Application' Widgets are not expected to exhibit this behavior.
2. Application widgets are expected to be user-resizable, and so authors cannot rely on the widget having any particular viewport size.

This makes them behave much more like 'fullscreen' in a mobile context, or like a regular web page in a browser.

>>> a.)onModeChange - an event triggered when the widget
>> transitions to a
>>> new mode;
>>
>> It needs to be specified _when_ this event is triggered. Is it
>> prior to the mode switch taking place?  Is it a DOM event, or
>> a callback.  Is it cancellable?
>
> [MP] We think that this should be a DOM event that takes place after the
> switch of modes. Not cancellable.

The downside to letting this happen after the mode switch, is that the widget might in this callback want to 

>>> a.) Only one floating mode widget can have focus. The widget with
>>> focus must have the highest z-index;
>>
>> This is in direct conflict with Window behavior on Unix/Linux
>> system, where a window can have a lower z-index than other
>> windows, and still be focused. It is also in conflict with
>> Opera's current desktop widget implementation, where it is
>> possible to push widgets to stick to the desktop and as such
>> be overlaid by other windows.
>>
> [MP] Good points - so we could instead say something like the last
> widget that the user interacted with
> has focus? Would that work?

I'm not really sure there is a need to say anything really - because we'd be well into the domain of specifying interaction requirements and behavior of operating systems.

-- 
Arve Bersvendsen

Developer, Opera Software ASA, http://www.opera.com/
Received on Thursday, 22 January 2009 13:57:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:29 GMT