[widgets] window modes in P&C, was Re: Small question about latest version of "P&C specs" (11th Mar 2009)

On 3/12/09 12:25 PM, ivan.demarino@orange-ftgroup.com wrote:
> Mmmm.
> And how we define more than one viewmode?
> I mean, apart from the "default one" for the content, was not decided to give to the developer the possibility of declaring what modes the widget supports and how (in terms of size)?
>
> Am I missing something?
>

Right. Finally got around to this!

Here is my attempt at a redefinition:

viewmodes
Optional. A (space separated) keyword list attribute that denotes the 
view modes supported the widget. The value SHOULD be one or more of the 
following valid window modes as defined in [Widgets-WM]: application, 
floating, fullscreen, mini, or all. The default value, which is used 
when the attribute is omitted or has a value other than one of the valid 
window modes, is 'floating'. The first item in the list represents the 
author's preferred view mode, followed by the next most preferred view 
mode, and so forth.

Usage example
<widget xmlns="http://www.w3.org/ns/widgets"
         id="http://example.org/exampleWidget"
         version="2.0 Beta"
         height="200"
         width="200"
         viewmodes="floating application">
   <description>
    An example of the possibilities.
   </description>
</widget>

Some thoughts:

The width and height attributes only act as sizing hints for the view 
port in floating and application mode. They are irrelevant for 
fullscreen, and possibly mini mode. In mini mode, the widget is shoved 
into a cramped space of an undefined size that is likely smaller then 
all of the other modes. In application mode, the user agent MAY ignore 
the width and height attribute (and in some cases, I imagine, 
application mode will behave like fullscreen, in which case the width 
and height will again be ignored by the UA).

For context where the author wants to resize, they should use 
window.resizeBy() and window.resizeTo(). _HOWEVER_ those methods are not 
standardized in HTML5 (even though every browser supports them). We need 
to formally request they be standardized in HTML5 by presenting the 
appropriate use cases.

Kind regards,
Marcos

Received on Friday, 8 May 2009 14:29:36 UTC