Re: [widgets] Strawman requirements for widget (view/display/window) modes
I've now integrated the requirements below into the Requirements spec [1]. In acknowledgment of the work that Mark has done on both the Dig Sig/Security requirements and Window modes, I've added him as co-editor (now he can also get the blame!:) ). Please also note that I have switched to CSS counters for the requirement numbers, meaning that they are dynamically inserted into the document... not all browsers support CSS counters, so apologies if you can't see the generated content. Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-reqs/ On Tue, Feb 24, 2009 at 2:29 PM, Marcos Caceres marc...@opera.com wrote: Hi All, The following draft requirements for display modes were formulated during the F2F based on Mark's strawman proposal (also below). Please feel free to comment. === General Requirements === RXX. Display Modes A conforming specification MUST specify a set of display modes for widgets that stipulate how widgets SHOULD be rendered at runtime when in a specific mode. A conforming specification SHOULD also define particular allowed, or disallowed, user-interaction behaviors for each display mode; such as the ability for a widget to be dragged or re-sized. For each display mode, the way in which the widget is displayed MUST be specified so that the rendering of the Widget is as consistent as possible across widget user agents. The display modes SHOULD also be specified to interoperate with device independence best practices and/or specifications. Proprietary display modes MAY be supported by the Widget User Agent. Rationale: To provide authors with a variety of commonly widget display modes and to help ensure that their widgets are renders as consistently as possible across different Widget User Agents. In addition, allowing proprietary display modes provides a means to support innovative user experiences. ==CONFIGURATION DOCUMENT REQUIREMENT== R.XX Preferred display modes A conforming specification MUST provide a means for author to indicate at least one preferred display mode for a widget. In the absence of a preferred mode, a conforming specification SHOULD provide a consistent default display mode across all user agents. A conforming specification SHOULD make it possible for an author to indicate to the widget user agent which display modes the widget has been designed to run in. The Widget User Agent MAY ignore the indications of display mode supported, but SHOULD NOT ignore the preferred display mode. Rationale: To provide authors a means to indicate a preference over how their widget is initially rendered, though this would not be not guaranteed by the widget user agent. A means of declaring the preferred display mode also provides authors some reassurance, as some widgets may be better suited to being displayed in one display mode over the others. As already stated, widget user Agents may choose to ignore the author's display mode preference, for example, if they do not support the indicated display mode. I don't agree with: A conforming specification SHOULD make it possible for an author to indicate to the widget user agent which display modes the widget has been designed to run in. This should be handled via CSS media queries and handled by the author. ==API AND EVENTS REQUIREMENT=== Rxx Display mode API and Events A conforming specification MUST provide an API to allow authors to programmatically switch between display modes. A conforming user agent MUST be allowed to ignore requests by the author to switch to an unsupported display mode, but MUST throw an exception or error if it will not perform the mode change. A conforming specification MUST also provide a guaranteed means for authors to detect a change in display mode. A conforming specification MUST provide a means for an author to check the current display mode of a widget. ==USER AGENT REQUIREMENT== Rxx. Display Mode Switching A conforming specification MUST allow a widget user agent to dynamically change display mode of a widget. Switching from one mode to another, however, MUST not cause the re-instantiation of the Widget. Furthermore, it MUST be possible for a Widget to seamlessly move between modes, maintaining runtime state and any processes that are in progress. Rationale: To allow a widget user agent to have a degree of control over how widgets are displayed for the purpose of mediating the user experience. For example, the widget user agent my attempt to switch all widgets into floating mode and then display them in a 3D carousel. 2009/2/3 Priestley, Mark, VF-Group mark.priest...@vodafone.com: Hi All, Closing the action 291 (http://www.w3.org/2008/webapps/track/actions/291) please find below a strawman for a set of requirements relating to widget (view/display/window) modes. I have tried to define the requirements without basing them on any of the technical solutions that have been discussed to date. I am in no doubt
Re: [widgets] Strawman requirements for widget (view/display/window) modes
Hi All, The following draft requirements for display modes were formulated during the F2F based on Mark's strawman proposal (also below). Please feel free to comment. === General Requirements === RXX. Display Modes A conforming specification MUST specify a set of display modes for widgets that stipulate how widgets SHOULD be rendered at runtime when in a specific mode. A conforming specification SHOULD also define particular allowed, or disallowed, user-interaction behaviors for each display mode; such as the ability for a widget to be dragged or re-sized. For each display mode, the way in which the widget is displayed MUST be specified so that the rendering of the Widget is as consistent as possible across widget user agents. The display modes SHOULD also be specified to interoperate with device independence best practices and/or specifications. Proprietary display modes MAY be supported by the Widget User Agent. Rationale: To provide authors with a variety of commonly widget display modes and to help ensure that their widgets are renders as consistently as possible across different Widget User Agents. In addition, allowing proprietary display modes provides a means to support innovative user experiences. ==CONFIGURATION DOCUMENT REQUIREMENT== R.XX Preferred display modes A conforming specification MUST provide a means for author to indicate at least one preferred display mode for a widget. In the absence of a preferred mode, a conforming specification SHOULD provide a consistent default display mode across all user agents. A conforming specification SHOULD make it possible for an author to indicate to the widget user agent which display modes the widget has been designed to run in. The Widget User Agent MAY ignore the indications of display mode supported, but SHOULD NOT ignore the preferred display mode. Rationale: To provide authors a means to indicate a preference over how their widget is initially rendered, though this would not be not guaranteed by the widget user agent. A means of declaring the preferred display mode also provides authors some reassurance, as some widgets may be better suited to being displayed in one display mode over the others. As already stated, widget user Agents may choose to ignore the author's display mode preference, for example, if they do not support the indicated display mode. I don't agree with: A conforming specification SHOULD make it possible for an author to indicate to the widget user agent which display modes the widget has been designed to run in. This should be handled via CSS media queries and handled by the author. ==API AND EVENTS REQUIREMENT=== Rxx Display mode API and Events A conforming specification MUST provide an API to allow authors to programmatically switch between display modes. A conforming user agent MUST be allowed to ignore requests by the author to switch to an unsupported display mode, but MUST throw an exception or error if it will not perform the mode change. A conforming specification MUST also provide a guaranteed means for authors to detect a change in display mode. A conforming specification MUST provide a means for an author to check the current display mode of a widget. ==USER AGENT REQUIREMENT== Rxx. Display Mode Switching A conforming specification MUST allow a widget user agent to dynamically change display mode of a widget. Switching from one mode to another, however, MUST not cause the re-instantiation of the Widget. Furthermore, it MUST be possible for a Widget to seamlessly move between modes, maintaining runtime state and any processes that are in progress. Rationale: To allow a widget user agent to have a degree of control over how widgets are displayed for the purpose of mediating the user experience. For example, the widget user agent my attempt to switch all widgets into floating mode and then display them in a 3D carousel. 2009/2/3 Priestley, Mark, VF-Group mark.priest...@vodafone.com: Hi All, Closing the action 291 (http://www.w3.org/2008/webapps/track/actions/291) please find below a strawman for a set of requirements relating to widget (view/display/window) modes. I have tried to define the requirements without basing them on any of the technical solutions that have been discussed to date. I am in no doubt that the proposed requirements need discussion and refinement - essentially, they are meant only as a starting point. It's over to the group now to agree how best to progress them - I welcome any suggestions on how they could be improved. Thanks, Mark - Strawman Requirement for widget modes - 1. There MUST be a defined set of display modes for a Widget. For each defined display mode, the way in which the Widget is displayed MUST be specified so that the rendering of the Widget is consistent across Widget User Agents. The display modes
