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
 
(69 intermediate revisions by 7 users not shown)
Line 1: Line 1:
A canonical set of uses cases that represents the set of problems we are trying to solve by implementing a component model. For implementation details, see [http://dev.w3.org/2006/xbl2/Overview.html XBL2 Spec].
{{obsolete|see=http://www.w3.org/2008/webapps/wiki/Component_Model_Use_Cases}}


This document is broken out into two sections: '''general use cases''' provide insight into how the component model could be used; '''specific use cases''' are interesting scenarios within the general use cases that should be treated as constraints/requirements, imposed on the specification/implementation of the component model.
These use cases represent a set of problems we are trying to solve by implementing a [[Component_Model | component model]] for the web.  


=General Use Cases=
=Custom Controls=


==Built-in HTML Elements==
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.
 
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. [https://wiki.mozilla.org/Gecko:Home_Page Gecko] already takes this approach pretty far. 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.
 
== Custom Widget System ==
 
As it is today (Jan 1, 2011), pretty much every Javascript framework has a widget system (see http://jqueryui.com/, http://sproutcore.com/, http://o.dojotoolkit.org/projects/dijit, http://cappuccino.org/, http://code.google.com/webtoolkit/, http://code.google.com/closure/library/, http://www.sencha.com/ as just a few examples).  All of these these widget systems are framework-specific and mostly incompatible with each other.
Because the Web platform doesn't provide a well-functioning way to extend HTML elements, all of these tend to build a parallel widget space, where widget objects act as proxies to DOM objects, and the extensibility exists only within that parallel widget space. A DOM-based component model should aim to eliminate the need for this parallel space and allow widget systems to just use DOM with the goals of:
* reducing the amount of widget-space-related code written in each framework
* providing better, leak-free abstraction for widgets
* providing interoperable API to allow widgets from different frameworks to coexist and integrate.
 
Requirements:
* provide a uniform way (i.e. DOM) to declare widget APIs
* encapsulate widget implementation details
* enable control over how styles and events outside of a widget affect it
* enable widget styling primitives
* asynchronously instantiate and initialize widgets (for instance, display a widget without starting up a script context, then progressively enhance with script).
* allow seamless reuse a widget written using various libraries or frameworks
* allow using widgets declaratively, with minimal knowledge of the underlying implementation
* provide a way to create new widgets by extending existing widgets
 
Needs:
* content element (output ports)
* attachment using CSS and DOM
* separate instantiation and binding phases (or another way to allow asynchronous binding)
* attribute/pseudo forwarding
* declarative templating/binding
 
Could use:
* dynamic attachment/detachment
* template inheritance
* supporting form-control like behavior like "disable" HTML attribute, "form" JS property, etc.
 
Doesn't care:
* mutable templates
* xml:base handling
 
Interesting scenarios:
* Implement a "polaroid frame" widget? This widget, when bound to any element would display its contents in a Polaroid(tm)-like frame.
* Suppose the widget system has a centralized "settings" widget, with which all other widgets should communicate to add their settings. Implement this communication, provided that all widgets are opaque elements.
* Implement a "tab set" widget. As you add "tabs" to it, tab titles appear in a row at the top, and tab contents appear in the main area, only visible when the corresponding tab title is selected.


==Layout Manager==
==Layout Manager==


Does:
{| cellpadding="8" cellspacing="0"
* provide a framework for client-side restructuring of content to accommodate layout
|+style="caption-side:top; text-align: left; color:Gray" | Layout Manager Use Case Parameters
* support both imperative a declarative layout models
! align="right" valign="top" | Who
* provide templating/theming capabilities
| Web Framework Engineer
 
|-
Needs:
! align="right" valign="top" | What
* content element (output ports)
| Build a layout library, consisting of a UI layout primitives, such as ''panel'', ''resizeable panel'', ''tab group'', ''stack'', ''accordion containers'', etc.
* attachment using CSS and DOM
|-
* separate instantiation and binding phases (or another way to allow asynchronous binding)
! align="right" valign="top" | Purpose
 
|
Could use:
* 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.
Doesn't care:
|-
* mutable templates
! align="right" valign="top" | Examples
* xml:base handling
|
 
* [http://dojotoolkit.org/reference-guide/dijit/layout.html#dijit-layout Dijit Layout]
==Specialized Markup Languages==
* [http://code.google.com/webtoolkit/doc/latest/DevGuideUiPanels.html GWT Panels]
 
* [http://dev.sencha.com/deploy/ext-4.0.2a/docs/#/api/Ext.panel.AbstractPanel Sencha Panels]
It's possible to imagine the component model to be used for lightweight implementations of specialized markup languages, such as MathML.
* [http://guides.sproutcore.com/views.html SproutCore Views]
'''This section needs work.'''
|-
 
! align="right" valign="top" | Desirable Properties
=Specific Use Cases=
|
 
* [[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.
==Shadow DOM==
* [[Component_Model#Encapsulation | Encapsulation]] -- styles, defined to hold layout in place should not be in danger of being stomped on by the author stylesheets.
A component model should allow a component to hide its implementation details from the consumer. For instance, consider this bit of code:
* [[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.
<pre>
|}
<input type="range">
</pre>
The least thing the user of this element would expect is being able to walk down the DOM subtree of the <code>input</code> element and find the thumb element inside:
<pre>
<input type="range">
    <div></div>
</input>
</pre>
 
Similarly, that's not what the code managing the range slider would want to happen. Thus, the '''shadow DOM''' is ''a way to implement a DOM subtree that is rendered as part of the document, but is not accessible by traversing the document tree''. Shadow DOM provides the necessary level of isolation between component and non-component parts of the DOM tree and is the fundamental part of the component model.
 
==Dynamic Binding Mechanism==
Being able to apply and unapply a shadow DOM tree, its style information and the code that manages them as one atomic action seems important. For instance, changing the <code>type</code> attribute of the input element immediately triggers the change of how the element looks and behaves. One can view this described in CSS as:
 
<pre>
input[type='text'] {
    binding: url(http://example.com/input/text/);
}
 
input[type='range'] {
    binding: url(http://example.com/input/range/);
}
</pre>
 
In the code snippet above, it is implied that the shadow subtree, styles, and code are applied/unapplied atomically and dynamically as the <code>type</code> attribute value changes.
 
TODO: We need to be very careful about executing JavaScript at the behest of CSS. Browsers vendors that have tried that in the past have later come to regret that decision.
 
==Multiple Shadow DOM Subtrees On Element==
A new component might want to build upon an existing component to provide new functionality. For example, I might want to turn the <code>input type="range"</code> into a dial, rather than a slider. The dial code is implemented as a shadow DOM subtree and is bound to the element like so:
 
<pre>
/* CSS */
input[type='range'].dial {
    binding: url(http://example.com/dial/);
}
</pre>
 
To use my dial, I have this bit of code:
 
<pre>
function setDialMode(id, dial)
{
    var input = document.getElementById(id);
    if (dial)
      input.classList.add('dial');
    else
      input.classList.remove('dial');
}
</pre>


The user's expectations is that the <code>input</code> element turns into a dial once the <code>dial</code> class is set and reverts back to the slider once it's removed. Given that slider itself is implemented as a shadow DOM subtree,  this indicates that either:
==Widget Mix-and-Match==
# '''Mltiple shadow subtrees could exist on an element at the same time with only one subtree rendered'''. This implies some sort of "selector memory" ability, which is completely foreign to how things work in the browser today.
# '''A shadow subtree is destroyed and rebuilt every time selector applies/unapplies'''. This is also bad, because destroying discards any modifications to the subtree that may have occurred during its lifetime. In addition, this approach seems very prone to performance troubles.


==User Agent-Level Attachment==
{| cellpadding="8" cellspacing="0"
Since the component model is used to implement built-in HTML elements, there has to be a way apply subtree/style/code at the UA level. The attachment at this level has to satisfy these criteria:
|+ style="caption-side:top; text-align: left; color:Gray" | Mix-and-matching Use Case Parameters
# It should happen before any other component attachment (like UA-level stylesheets).
! align="right" valign="top" | Who
# It should allow the component code to access API methods that are accessible only to the UA-level attachment. For instance, a <code>video</code> element implementation may need to operate on the native video frame. Direct access to the video frame should not be allowed outside of the UA-level components.
| Web Application Engineer
# It should allow the component implementation details to be completely hidden. There should be no way to detect whether an HTML element is built using the component model.
|-
! align="right" valign="top" | What
| Build an application using multiple existing controls from several frameworks.
|-
! align="right" valign="top" | Purpose
|
* Write application faster by reusing code.
* Avoid having to exclusively go with one framework.
|-
! align="right" valign="top" | Examples
|
* [http://stackoverflow.com/questions/4534274/how-do-you-access-dijit-elements-in-jquery How do you access Dijit elements in JQuery]
* [http://yehudakatz.com/2011/06/11/using-sproutcore-2-0-with-jquery-ui/ Using SproutCore 2.0 with jQuery UI]
* [http://stackoverflow.com/questions/394601/which-javascript-framework-jquery-vs-dojo-vs Which JavaScript framework (jQuery vs Dojo vs … )?]
|-
! 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.
|}


==Styling Using Pseudo Elements==
==Rendering Form Controls with SVG==
To replicate existing functionality, there should be a way to apply styles to the elements in shadow DOM subtree using pseudo elements. For example:
<pre>
input[type='range']::-webkit-slider-thumb
{
    background-color: Cyan;
}
</pre>
Currently, this matches the thumb in the slider, allowing you to style it. This capability should be available in the new component model to support these existing use cases. This implies that there must be a way to associate an arbitrary string with an element in a shadow subtree, which is matched as a pseudo-element value on the host element of the shadow subtree.
==Events and Shadow Subtrees==
Events, originated in shadow subtrees, should, in most cases, escape into the main document. For example, if I click on the thumb of the slider in the <code>input[type=range]</code>, I expect to hear all of the respective mouse events at the input. One important notion is that the target of the event and the event object itself should be changed to not to reveal the shadow subtree. In the example above, the value of <code>event.target</code> in the document should be the input, not the thumb.


==Near-native Performance==
{| cellpadding="8" cellspacing="0"
HTML elements, built using the component system should perform as well as if they were implemented natively and have similar memory consumption characteristics.
|+ style="caption-side:top; text-align: left; color:Gray" | SVG Form Controls Use Case Parameters
! align="right" valign="top" | Who
| Web Application Engineer or Web Framework Engineer
|-
! align="right" valign="top" | What
| Create a set of UI controls that act like standard HTML forms controls, but use SVG for rendering.
|-
! align="right" valign="top" | 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.
|-
! align="right" valign="top" | Examples
|
[http://docs.sproutcore.com/#doc=SC.ImageButtonView&src=false SproutCore's ImageButtonView], [http://dev.sencha.com/deploy/touch/docs/?class=Ext.form.Number Sencha's Number] -- examples of extensive themed form control hierarchy.
|-
! 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.
|}


==Conceptual Similarity to Ordinary Markup==
==Contacts Widget==
There are two ways to build a DOM tree, using HTML (a declarative API) and using DOM methods (an imperative API). It seems like a ''good thing'' to allow developers having the same options for building a shadow DOM subtree. Both options should feel as similar as possible to creating an ordinary DOM tree.


==Template/Stencil Mental Model of a Declarative API==
{| cellpadding="8" cellspacing="0"
Since both widgets and built-in HTML elements are meant to have multiple instances, created and destroyed at will, it appears logical to adapt the template/stencil mental model of how a shadow DOM subtree is instantiated:
|+ style="caption-side:top; text-align: left; color:Gray" | Contacts Widget Use Case Parameters
* the subtree is built from some template of a widget/element;
! align="right" valign="top" | Who
* the subtree is used to manage behavior or widget/element;
| Web Application Engineer
* the subtree is destroyed with the widget/element.
|-
! align="right" valign="top" | 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.
|-
! align="right" valign="top" | 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.
|-
! align="right" valign="top" | Examples
| [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.
|}


==Reacting to bound element state change==
==Like/+1 Button==
A widget may want to know if its state (focused/selected/activated) has changed. This can be accomplished by attaching an event listener to its ''light'' node:
<pre>
<html>
<head>
    <binding element="div">
        <template>
            <span>I am asleep</span>
        </template>
        <implementation>
            ({
                xblEnteredDocument: function()
                {
                    var tree = this.shadowTree;
                    this.boundElement.addEventListener("DOMActivate",
                        function()
                        {
                            tree.firstChild.textContent = "I AM AWAKE";
                        }, false);
                }
            })
        </implementation>
    </binding>
</head>
<body>
    <div></div>
</body>
</html>
</pre>


==Reacting to bound element attribute changes==
{| cellpadding="8" cellspacing="0"
A widget may want to know when its attributes are changed. Similarly to the state change, this can be accomplished by attaching a DOM mutation event listener to its ''light'' node (see example for the state change and imagine a DOM mutation event listener being registered instead).
|+ 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.
|}


==Mindless Forwarding of the Attribute Changes==
==Table-based Charts==
In cases where the meaning of the attribute needs to be reflected by an element in the shadow DOM subtree, forwarding attribute changes mindlessly (without registering listeners and generally executing script) is useful:
<pre>
<html>
<head>
    <binding element="myinput">
        <template>
            <h2>O HAI! MY INPUT IZ TEH AWSUM</h2>
            <input type="text" attributes="value disabled readonly">
        </template>
    </binding>
</head>
<body>
    <myinput></myinput>
</body>
</html>
</pre>


==Using Shadow DOM Boundary for Isolation==
{| cellpadding="8" cellspacing="0"
The boundary between shadow and light DOM presents an interesting opportunity to use this boundary for script and DOM subtree isolation. For example, binding trusted code to an element in an untrusted tree could be used for clearer separation between control and data channel in the document.
|+ 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.
|}


There are three cases worth considering:
==Timezone selection via Image==


# The parent document trusts its components but the components do not trust the parent document.
{| cellpadding="8" cellspacing="0"
# The parent document does not trust its components but the components does trust the parent document.
|+ style="caption-side:top; text-align: left; color:Gray" | Timezone selection via Image Use Case Parameters
# Neither the parent document nor the components trust the other.
! 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 &lt;select&gt;. Should fall back to a simple &lt;select&gt; where components are not supported.
* [[Component_Model#Consistency | Consistency]] -- Extend the &lt;select&gt; API for item selection.
|}


===Parent trusts component but not vice versa===
==Entry-helper==


Because the components are embedded into the parent document, the parent document will be able to control how the component appears to the user.  However, the component could hope to hide its internal state from the parent document. More specifically, imagine that the component contains a secret value, such as a capability for accessing a web service. The component should be able to keep this value confidential from the parent document.
{| 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 &lt;input&gt;. Should fall back to a simple &lt;input&gt; where components are not supported.
|}


===Component trusts parent but not vice versa===
=Built-in HTML Elements=


Much like embedding an iframe, a parent document should be able to include an untrusted component without abandoning its security. For example, imagine a video hosting web site provides a video player component that can be embedded in other documents. Those documents should be able to embed the video player component without allowing the video player to inject arbitrary content into the parent page.
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.


===Mutual distrust===
{| cellpadding="8" cellspacing="0"
|+ style="caption-side:top; text-align: left; color:Gray" | Built-in HTML Elements Use Case Parameters
! align="right" valign="top" | Who
| Browser Engineer
|-
! align="right" valign="top" | What
| Implement a built-in HTML element by composing or extending existing HTML elements
|-
! align="right" valign="top" | 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.
|-
! 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.
|}


If the component system achieves the above two use cases in a sufficiently generic manner, the component model should also allow the parent document and the component to be mutually distrusting.  For example, the video player described above could contain a capability for accessing a web service as above.
==Media Controls For The Video Element==


==Faster-than-imperative Parsing of Shadow DOM Markup==
Using DOM elements, build a media controls panel for the [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-video-element video element]. The media controls include:
It should be possible for browsers to use declarative shadow DOM APIs to achieve performance than the imperative APIs, because the subtree template can be pre-parsed and optimized for cloning + wire-up instead of building from scratch for every instance.
* 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.  


==Tens of Thousands of Widgets==
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 should be able to efficiently handle a very large number of instances from the same template (see [http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0979.html discussion]).
<pre>
<html>
<head>
    <binding element="div">
        <style scoped>
            div.pretty {
                background-color: Pretty;
            }
        </style>
        <template>
            <div class="pretty">Pretty is, pretty does.</div>
        </template>
    </binding>
</head>
<body>
    <script>
        for(var i = 0; i < 20 * 1000; ++i)
            document.body.appendChild(document.createElement('div'));
    </script>
</body>
</html>
</pre>


==Insertion Points, Not Containers==
==Details/Summary Elements==
Output ports need to be insertion points, not cointainers. If the output port is a container (that is, an existing element in the shadow subtree is designated as a place to add the "light" nodes), some layout scenarios aren't possible. In this example, you can not use flexbox to layout all of the paragraphs in the story:
<pre>
<template>
    <p>Once upon a time,
    <content includes="p">
    <p>And they lived happily ever after
</template>
</pre>
It is useful to think of the output port as a [https://developer.mozilla.org/en/DOM:range.collapsed collapsed range].


==Shadow Subtree Mutation==
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.
Because content element is an insertion point, what happens when the elements around it change? What happens when the insertion point moves?
* '''Modifying includes attribute'''. What happens when you modify the <code>includes</code> element on the output port?
* '''Nested shadow subtrees'''. Suppose you have two bindings, one applied inside another:
<pre>
<html>
<head>
    <binding element="div#foo">
        <template>
            <span>
                <content></content>
            </span>
        </template>
    </binding>
    <binding element="div#bar">
        <template>
            <div>
                <div id="foo">
                    <span>Blah</span>
                    <content></content>
                </div>
        </template>
    </binding>
</head>
<body>
    <div id="foo">
        <p>Monkeys
    </div>
</body>
</html>
</pre>
Sequence of actions:
# Add a <code>div</code> element to <code>div#bar</code>.
# Move <code>content</code> element in <code>div#bar</code> template as the first child of <code>div</code>
What happens?


==Dynamicity of Rules==
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.
As XBL2 spec'd today, the [http://dev.w3.org/2006/xbl2/Overview.html#includes includes] attribute is fully dynamic. That is, changing this attribute results in node redistribution. Being able to control node distribution from outside of the shadow subtree seems like a useful feature. Consider this example:
<pre>
<html>
<head>
    <binding element="ul.news">
        <template>
            <h2>Breaking News</h2>
            <ul id="breaking">
                <content includes="li.breaking"></content>
            </ul>
            <h2>Other News</h2>
            <ul id="other">
                <content></content>
            </ul>
        </template>
    </binding>
</head>
<body>
    <ul class="news">
        <li class="breaking">Santa seen crossing Atlantic</li>
        <li>Pies pose serious health risk, scientists say</li>
    </ul>
</body>
</html>
</pre>
Here, the importance of the news item is controlled outside of the shadow subtree. By setting/removing class <code>breaking</code> on a news item, the consumer of the binding can move it in and out of the breaking news section. Implementing this without dynamic rules seems cumbersome and non-trivial.

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

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.
  • Encapsulation -- styles, defined to hold layout in place should not be in danger of being stomped on by the author stylesheets.
  • Performance -- layouts built with layout manager should appear quickly, avoiding re-flows and FOUC-like symptoms.

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
  • Consistency -- the controls should act just like any other DOM elements.
  • Encapsulation -- the document shouldn't be able to accidentally mess up the rendering of the controls.
  • Performance -- load quickly, avoid FOUC-like symptoms when using 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.
  • Composability -- easily added anywhere in the DOM tree.

Like/+1 Button

Like/+1 Button Use Case Parameters
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
  • Provide a simple vehicle for Web authors to embed the button.
  • Isolate widget implementation details from the document.
Examples
Desirable Properties
  • Encapsulation -- means to ensure style of the document does not affect the widget, and widget's logic is kept to the widget.
  • Confinement -- a way to completely isolate the widget implementation from the document in which it is being embedded.
  • Performance -- don't block the page load.

Table-based Charts

Table-based Charts Use Case Parameters
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
  • Composability -- one should be able to make chart by creating a table, imperatively or declaratively.
  • Performance -- no FOUC or blocking load when charts are loaded.

Timezone selection via Image

Timezone selection via Image Use Case Parameters
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
  • Extensibility -- Basically extending <select>. Should fall back to a simple <select> where components are not supported.
  • Consistency -- Extend the <select> API for item selection.

Entry-helper

Entry-helper Use Case Parameters
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
  • Most browser's address bar or web search field
Desirable Properties
  • Extensibility -- Basically extending <input>. Should fall back to a simple <input> where components are not supported.

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.

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.

Retrieved from "https://wiki.whatwg.org/index.php?title=Component_Model_Use_Cases&oldid=8747"