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 |
|||
| Line 82: | Line 82: | ||
|} | |} | ||
== | ==Contacts Widget== | ||
{| cellpadding="8" cellspacing="0" | {| cellpadding="8" cellspacing="0" | ||
| Line 100: | Line 100: | ||
| [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] | ||
|} | |} | ||
=Built-in HTML Elements= | =Built-in HTML Elements= | ||
Revision as of 18:24, 28 July 2011
These use cases represent the 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.
The lifecycle of these components may differ, with some being bootstrapped from in-page markup, whereas many use programmatic instantiation, but the former can be easily considered a superset of the latter.
Custom controls should be able to be declared the same way HTML elements are, using markup for demarking their location in the generated DOM, attributes for configuration and property setting, and lightweight type conversion based on attribute type. The lifecycle of markup-declared controls must be able, therefore, to host non-custom controls as children (optionally), and must participate in the DOM and layout hierarchies naturally. Existing JS-based component systems generally preserve these properties to varying degrees.
The actions components support are:
- construction of the component
- configuration, often through arguments to the constructor
- view generation and configuration
- addition of the component to the visible DOM of the document
- enumeration/configuration post-insertion
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 |
Widget Mix-and-Match
| Who | Web Application Engineer |
|---|---|
| What | Build an application using multiple existing controls from several frameworks. |
| Purpose |
|
| Examples |
Rendering Form Controls with SVG
| Who | Web Application Engineer or Web Framework Engineer |
|---|---|
| What | Create a set 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. |
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 |
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 |
|
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. Per spec, first summary element found in the flow content is used to represent a summary or legend of details, or some fallback content if a summary element is not found. The summary element itself needs to have a marker indicating whether summary element is open or closed.
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.
IN PROGRESS: Desirable Properties
The above use-cases are derived from explicit real-world goals which are being met, when they can be, through large piles of custom, non-interoperable JavaScript code. Further, we can see in these use-cases the desire to be "first class" when extending HTML/DOM. We see the following properties as desirable, motivated by the above use-cases:
- No special forms. The ability of custom element types to exist along side existing element types should not come with the burden to use special forms to declare or construct these element types. They must not be "hacked in" to the API, rather, the existing APIs should change or be extended to accommodate custom variants.
- Just DOM. The "no special forms" goal leads us directly to suggest that any solution should simply be a first-class extension to HTML DOM, not a bolt-on or addition of a separate document type.
- De-sugaring. To the extent possible, providing support for the above use-cases should happen in a way that leans on as few primitives as possible, with both custom components and built-ins being described with the same pseudo-code and lifecycle, even if the implementations differ wildly
- Runtime support. Interoperability of components should be provided through common plumbing to support the goals of construction, discovery, lifecycle management, etc.
- High-level, but layered. Runtime support should provide both the high-level ability to use and declare components in markup but also provide pluggability and desugaring so as to allow sophisticated authors to over-ride any described part of the component lifecycle with their own implementations.