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

From WHATWG Wiki
Jump to navigation Jump to search
No edit summary
(Fixing some minor nits.)
Line 8: Line 8:


{| 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 36: Line 36:


{| 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 63: Line 63:


{| cellpadding="8" cellspacing="0"
{| cellpadding="8" cellspacing="0"
|+ style="color:Gray" | Theming Form Controls Use Case Parameters
|+ 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 87: Line 87:


{| 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 96:
! 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
Line 112: Line 112:


{| cellpadding="8" cellspacing="0"
{| cellpadding="8" cellspacing="0"
|+ style="color:Gray" | Built-in HTML Elements Use Cases Parameters
|+ 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 121: Line 121:
! 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.
Line 138: Line 138:
* a volume control, which is revealed when hovering over the volume button.  
* 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.
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. In addition, we might want to allow authors to add or remove buttons.


==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. Per spec, first <code>summary</code> element found in the flow content is used to represent a summary or legend of details, or some fallback content if a <code>summary</code> element is not found. The <code>summary</code> element itself needs to have a marker indicating whether <code>summary</code> element is open or closed.
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 or <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.

Revision as of 07:06, 2 August 2011

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

Layout Manager Use Case Parameters
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
  • Allow web application developers to easily build constrained layout and populate it with arbitrary HTML content.
  • Provide a way for developers to build their own layout primitives by extending the provided ones.
Examples
Desirable Properties
  • composability -- a method to compose layouts with both UI primitives and DOM elements.
  • extensibility -- a way to build on layout primitives to create new ones.

Widget Mix-and-Match

Mix-and-matching Use Case Parameters
Who Web Application Engineer
What Build an application using multiple existing controls from several frameworks.
Purpose
  • Write application faster by reusing code.
  • Avoid having to exclusively go with one framework.
Examples
Desirable Properties
  • consistency -- a compatible way to expose properties and methods across widget frameworks.
  • composability -- a method to compose with cross-framework widgets.

Rendering Form Controls with SVG

SVG Form Controls Use Case Parameters
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
  • Provide custom appearance of form controls, consistent with overall the Web application theme.
  • Make the form controls scale beautifully for various resolutions and form factors.
Examples

SproutCore's ImageButtonView, Sencha's Number -- examples of extensive themed form control hierarchy.

Desirable Properties
  • extensibility -- a way to override appearance of native form controls.

Contacts Widget

Contacts Widget Use Case Parameters
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
  • 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.
Examples A screenshot of Google+ "in your circles" widget
Desirable Properties
  • encapsulation -- means to ensure style of the document does not affect the widget, and widget's logic is kept to the widget.

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.

Built-in HTML Elements Use Case Parameters
Who Browser Engineer
What Implement a built-in HTML element by composing or extending existing HTML elements
Purpose
  • 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.
  • Stretch: specify built-in element behavior in terms of the component model specification.
Desirable Properties
  • encapsulation -- ensure that implementation details are not exposed to the document
  • desugaring -- explain appearance and behavior of controls in terms of CSS/DOM.

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. In addition, we might want to allow authors to add or remove buttons.

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 or <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.