A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Component Model Use Cases: Difference between revisions
No edit summary |
No edit summary |
||
(18 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
These use cases represent a set of problems we are trying to solve by implementing a component model for the web. | {{obsolete|see=http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases}} | ||
These use cases represent a set of problems we are trying to solve by implementing a [[Component_Model | component model]] for the web. | |||
=Custom Controls= | =Custom Controls= | ||
Line 8: | Line 10: | ||
{| cellpadding="8" cellspacing="0" | {| cellpadding="8" cellspacing="0" | ||
|+ style="color:Gray" | Layout Manager Use Case Parameters | |+style="caption-side:top; text-align: left; color:Gray" | Layout Manager Use Case Parameters | ||
! align="right" valign="top" | Who | ! align="right" valign="top" | Who | ||
| Web Framework Engineer | | Web Framework Engineer | ||
Line 29: | Line 31: | ||
! align="right" valign="top" | Desirable Properties | ! align="right" valign="top" | Desirable Properties | ||
| | | | ||
* | * [[Component_Model#Composability | Composability]] -- a method to compose layouts with both UI primitives and DOM elements. | ||
* | * [[Component_Model#Extensibility | Extensibility]] -- a way to build on layout primitives to create new ones. | ||
* [[Component_Model#Encapsulation | Encapsulation]] -- styles, defined to hold layout in place should not be in danger of being stomped on by the author stylesheets. | |||
* [[Component_Model#Performance | Performance]] -- layouts built with layout manager should appear quickly, avoiding re-flows and [http://en.wikipedia.org/wiki/Flash_of_unstyled_content FOUC]-like symptoms. | |||
|} | |} | ||
Line 36: | Line 40: | ||
{| cellpadding="8" cellspacing="0" | {| cellpadding="8" cellspacing="0" | ||
|+ style="color:Gray" | Mix-and-matching Use Case Parameters | |+ style="caption-side:top; text-align: left; color:Gray" | Mix-and-matching Use Case Parameters | ||
! align="right" valign="top" | Who | ! align="right" valign="top" | Who | ||
| Web Application Engineer | | Web Application Engineer | ||
Line 56: | Line 60: | ||
! align="right" valign="top" | Desirable Properties | ! align="right" valign="top" | Desirable Properties | ||
| | | | ||
* | * [[Component_Model#Consistency | Consistency]] -- a compatible way to expose properties and methods across widget frameworks. | ||
* | * [[Component_Model#Composability | Composability]] -- a method to compose with cross-framework widgets. | ||
|} | |} | ||
Line 63: | Line 67: | ||
{| cellpadding="8" cellspacing="0" | {| cellpadding="8" cellspacing="0" | ||
|+ style="color:Gray" | | |+ style="caption-side:top; text-align: left; color:Gray" | SVG Form Controls Use Case Parameters | ||
! align="right" valign="top" | Who | ! align="right" valign="top" | Who | ||
| Web Application Engineer or Web Framework Engineer | | Web Application Engineer or Web Framework Engineer | ||
|- | |- | ||
! align="right" valign="top" | What | ! align="right" valign="top" | What | ||
| Create a set UI controls that act like standard HTML forms controls, but use SVG for rendering. | | Create a set of UI controls that act like standard HTML forms controls, but use SVG for rendering. | ||
|- | |- | ||
! align="right" valign="top" | Purpose | ! align="right" valign="top" | Purpose | ||
Line 81: | Line 85: | ||
! align="right" valign="top" | Desirable Properties | ! align="right" valign="top" | Desirable Properties | ||
| | | | ||
* | * [[Component_Model#Consistency | Consistency]] -- the controls should act just like any other DOM elements. | ||
* [[Component_Model#Encapsulation | Encapsulation]] -- the document shouldn't be able to accidentally mess up the rendering of the controls. | |||
* [[Component_Model#Performance | Performance]] -- load quickly, avoid [http://en.wikipedia.org/wiki/Flash_of_unstyled_content FOUC]-like symptoms when using controls. | |||
|} | |} | ||
Line 87: | Line 93: | ||
{| cellpadding="8" cellspacing="0" | {| cellpadding="8" cellspacing="0" | ||
|+ style="color:Gray" | Contacts Widget Use Case Parameters | |+ style="caption-side:top; text-align: left; color:Gray" | Contacts Widget Use Case Parameters | ||
! align="right" valign="top" | Who | ! align="right" valign="top" | Who | ||
| Web Application Engineer | | Web Application Engineer | ||
Line 96: | Line 102: | ||
! align="right" valign="top" | Purpose | ! align="right" valign="top" | Purpose | ||
| | | | ||
* Use the widget anywhere in the application without having to worry about styles affecting its appearance | * Use the widget anywhere in the application without having to worry about styles affecting its appearance. | ||
* Hide details of loading contact data and other plumbing of the widget from the consuming code with a stable API | * Hide details of loading contact data and other plumbing of the widget from the consuming code with a stable API. | ||
|- | |- | ||
! align="right" valign="top" | Examples | ! align="right" valign="top" | Examples | ||
| [http://i.imgur.com/4eDXM.png A screenshot of Google+ "in your circles" widget] | | [http://i.imgur.com/4eDXM.png A screenshot of Google+ "in your circles" widget] | ||
|- | |||
! align="right" valign="top" | Desirable Properties | |||
| | |||
* [[Component_Model#Encapsulation | Encapsulation]] -- means to ensure style of the document does not affect the widget, and widget's logic is kept to the widget. | |||
* [[Component_Model#Composability | Composability]] -- easily added anywhere in the DOM tree. | |||
|} | |||
==Like/+1 Button== | |||
{| cellpadding="8" cellspacing="0" | |||
|+ style="caption-side:top; text-align: left; color:Gray" | Like/+1 Button Use Case Parameters | |||
! align="right" valign="top" | Who | |||
| Web Application Engineer | |||
|- | |||
! align="right" valign="top" | What | |||
| Build a drop-in widget with a pre-defined appearance of a button, showing a count of likes/+1s for this instance of a button (count is stored at a central location), embeddable on any document on the Web. | |||
|- | |||
! align="right" valign="top" | Purpose | |||
| | |||
* Provide a simple vehicle for Web authors to embed the button. | |||
* Isolate widget implementation details from the document. | |||
|- | |||
! align="right" valign="top" | Examples | |||
| | |||
* [http://developers.facebook.com/docs/reference/plugins/like/ Facebook Like button embedding instructions] | |||
* [http://www.google.com/webmasters/+1/button/ Google +1 button embedding instructions] | |||
|- | |||
! align="right" valign="top" | Desirable Properties | |||
| | |||
* [[Component_Model#Encapsulation | Encapsulation]] -- means to ensure style of the document does not affect the widget, and widget's logic is kept to the widget. | |||
* [[Component_Model#Confinement | Confinement]] -- a way to completely isolate the widget implementation from the document in which it is being embedded. | |||
* [[Component_Model#Performance | Performance]] -- don't block the page load. | |||
|} | |||
==Table-based Charts== | |||
{| cellpadding="8" cellspacing="0" | |||
|+ style="caption-side:top; text-align: left; color:Gray" | Table-based Charts Use Case Parameters | |||
! align="right" valign="top" | Who | |||
| Web Framework Engineer | |||
|- | |||
! align="right" valign="top" | What | |||
| Provide a way to represent table data markup as charts or diagrams. | |||
|- | |||
! align="right" valign="top" | Purpose | |||
| Make it easy for Web authors to create charts and diagrams using table markup. | |||
|- | |||
! align="right" valign="top" | Examples | |||
| | |||
* [http://www.wait-till-i.com/2008/01/08/generating-charts-from-accessible-data-tables-using-the-google-charts-api/ Christian Heilmann's tochart script] | |||
|- | |||
! align="right" valign="top" | Desirable Properties | |||
| | |||
* [[Component_Model#Composability | Composability]] -- one should be able to make chart by creating a table, imperatively or declaratively. | |||
* [[Component_Model#Performance | Performance]] -- no FOUC or blocking load when charts are loaded. | |||
|} | |||
==Timezone selection via Image== | |||
{| cellpadding="8" cellspacing="0" | |||
|+ style="caption-side:top; text-align: left; color:Gray" | Timezone selection via Image Use Case Parameters | |||
! align="right" valign="top" | Who | |||
| Web Framework Engineer | |||
|- | |||
! align="right" valign="top" | What | |||
| Graphical representation of a timezone selector that shows a world map in addition to/instead of a drop-down list. | |||
|- | |||
! align="right" valign="top" | Purpose | |||
| Make it easy for Web authors to spruce up time zone selection (or similar). | |||
|- | |||
! align="right" valign="top" | Examples | |||
| | |||
* [http://www.timezonecheck.com Time Zone Map] | |||
|- | |||
! align="right" valign="top" | Desirable Properties | |||
| | |||
* [[Component_Model#Extensibility | Extensibility]] -- Basically extending <select>. Should fall back to a simple <select> where components are not supported. | |||
* [[Component_Model#Consistency | Consistency]] -- Extend the <select> API for item selection. | |||
|} | |||
==Entry-helper== | |||
{| cellpadding="8" cellspacing="0" | |||
|+ style="caption-side:top; text-align: left; color:Gray" | Entry-helper Use Case Parameters | |||
! align="right" valign="top" | Who | |||
| Web Framework Engineer, Web Application Engineer | |||
|- | |||
! align="right" valign="top" | What | |||
| Add an entry-helper (drop-down) list to input fields. | |||
|- | |||
! align="right" valign="top" | Purpose | |||
| | |||
Help the user fill in a form field, show suggestions and acceptable values, speed up data entry. | |||
|- | |||
! align="right" valign="top" | Examples | |||
| | |||
* Most browser's address bar or web search field | |||
|- | |||
! align="right" valign="top" | Desirable Properties | |||
| | |||
* [[Component_Model#Extensibility | Extensibility]] -- Basically extending <input>. Should fall back to a simple <input> where components are not supported. | |||
|} | |} | ||
Line 108: | Line 215: | ||
{| cellpadding="8" cellspacing="0" | {| cellpadding="8" cellspacing="0" | ||
|+ style="color:Gray" | Built-in HTML Elements Use | |+ style="caption-side:top; text-align: left; color:Gray" | Built-in HTML Elements Use Case Parameters | ||
! align="right" valign="top" | Who | ! align="right" valign="top" | Who | ||
| Browser Engineer | | Browser Engineer | ||
Line 117: | Line 224: | ||
! align="right" valign="top" | Purpose | ! align="right" valign="top" | Purpose | ||
| | | | ||
* Reduce amount of custom UI code (fewer bugs, less code rot, leading to fewer future bugs) | * Reduce amount of custom UI code (fewer bugs, less code rot, leading to fewer future bugs). | ||
* Remove magic: make it easier for authors to grok control behavior in familiar terms, allow authors to style controls using CSS. | * Remove magic: make it easier for authors to grok control behavior in familiar terms, allow authors to style controls using CSS. | ||
* ''Stretch'': specify built-in element behavior in terms of the component model specification. | * ''Stretch'': specify built-in element behavior in terms of the component model specification. | ||
|- | |||
! align="right" valign="top" | Desirable Properties | |||
| | |||
* [[Component_Model#Encapsulation | Encapsulation]] -- ensure that implementation details are not exposed to the document | |||
* [[Component_Model#Desugaring | Desugaring]] -- explain appearance and behavior of controls in terms of CSS/DOM. | |||
|} | |} | ||
Line 133: | Line 245: | ||
==Details/Summary Elements== | ==Details/Summary Elements== | ||
Implement [http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element details] and [http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-summary-element summary] elements. | Implement [http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element details] and [http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-summary-element summary] elements. According to the spec, the first <code>summary</code> element found in the flow content is used to represent a summary or legend of details. In case a <code>summary</code> element is not found, the UA is supposed to auto-generate some fallback content. The <code>details</code> element itself needs to have a marker indicating whether <code>details</code> element is open or closed - i.e., whether all contents of <details> are shown, or only the summary. | ||
Just like media controls, the implementation should not be accessible by the consumer of the elements. For example, the reordering of flow content to position <code>summary</code> element as first item in the disclosure widget should be imperceptible to DOM traversal methods. | Just like media controls, the implementation should not be accessible by the consumer of the elements. For example, the reordering of flow content to position <code>summary</code> element as first item in the disclosure widget should be imperceptible to DOM traversal methods. |
Latest revision as of 15:46, 10 November 2012
This document is obsolete.
For more information, see: http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases
These use cases represent a set of problems we are trying to solve by implementing a component model for the web.
Custom Controls
Current practice for sizable web applications is to use JavaScript libraries to provide a system to support the construction of custom controls. Implementing these controls can be made simpler and more interoperable with runtime support.
Layout Manager
Who | Web Framework Engineer |
---|---|
What | Build a layout library, consisting of a UI layout primitives, such as panel, resizeable panel, tab group, stack, accordion containers, etc. |
Purpose |
|
Examples | |
Desirable Properties |
|
Widget Mix-and-Match
Who | Web Application Engineer |
---|---|
What | Build an application using multiple existing controls from several frameworks. |
Purpose |
|
Examples | |
Desirable Properties |
|
Rendering Form Controls with SVG
Who | Web Application Engineer or Web Framework Engineer |
---|---|
What | Create a set of UI controls that act like standard HTML forms controls, but use SVG for rendering. |
Purpose |
|
Examples |
SproutCore's ImageButtonView, Sencha's Number -- examples of extensive themed form control hierarchy. |
Desirable Properties |
|
Contacts Widget
Who | Web Application Engineer |
---|---|
What | Build a drop-in Contacts widget, which has a pre-defined appearance and shows a list of your contacts, with a way to change the widget to compact or full view and to tell the widget to refresh its state. |
Purpose |
|
Examples | A screenshot of Google+ "in your circles" widget |
Desirable Properties |
|
Like/+1 Button
Who | Web Application Engineer |
---|---|
What | Build a drop-in widget with a pre-defined appearance of a button, showing a count of likes/+1s for this instance of a button (count is stored at a central location), embeddable on any document on the Web. |
Purpose |
|
Examples | |
Desirable Properties |
|
Table-based Charts
Who | Web Framework Engineer |
---|---|
What | Provide a way to represent table data markup as charts or diagrams. |
Purpose | Make it easy for Web authors to create charts and diagrams using table markup. |
Examples | |
Desirable Properties |
|
Timezone selection via Image
Who | Web Framework Engineer |
---|---|
What | Graphical representation of a timezone selector that shows a world map in addition to/instead of a drop-down list. |
Purpose | Make it easy for Web authors to spruce up time zone selection (or similar). |
Examples | |
Desirable Properties |
|
Entry-helper
Who | Web Framework Engineer, Web Application Engineer |
---|---|
What | Add an entry-helper (drop-down) list to input fields. |
Purpose |
Help the user fill in a form field, show suggestions and acceptable values, speed up data entry. |
Examples |
|
Desirable Properties |
|
Built-in HTML Elements
Many non-trivial (i.e. with additional behavior and styling beyond the standard box model) elements that exist in HTML today could be implemented using HTML/CSS/JS. It makes sense to provide a standardized way to accomplish this, with the short-term goals of reducing the size of browsers C++ code and making new element implementation easier, and the long-term goal of converging built-in HTML element implementations across browsers.
Who | Browser Engineer |
---|---|
What | Implement a built-in HTML element by composing or extending existing HTML elements |
Purpose |
|
Desirable Properties |
|
Media Controls For The Video Element
Using DOM elements, build a media controls panel for the video element. The media controls include:
- timeline slider
- stop/start, replay, closed-captioning, forward, rewind and volume buttons, and
- a volume control, which is revealed when hovering over the volume button.
The implementation details of the media controls should not be accessible or perceptible from outside of the video element. Document styles should not interfere with the styles of the media controls panel. However, we must provide a way for an author to explicitly style all parts of the media controls panel.
Details/Summary Elements
Implement details and summary elements. According to the spec, the first summary
element found in the flow content is used to represent a summary or legend of details. In case a summary
element is not found, the UA is supposed to auto-generate some fallback content. The details
element itself needs to have a marker indicating whether details
element is open or closed - i.e., whether all contents of <details> are shown, or only the summary.
Just like media controls, the implementation should not be accessible by the consumer of the elements. For example, the reordering of flow content to position summary
element as first item in the disclosure widget should be imperceptible to DOM traversal methods.