- From: Marcos Caceres <marcosc@opera.com>
- Date: Fri, 08 May 2009 16:28:40 +0200
- To: ivan.demarino@orange-ftgroup.com, Arve Bersvendsen <arveb@opera.com>
- CC: public-webapps@w3.org
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