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
(Moving stuff around)
Line 1: Line 1:
=Component Model (aka XBL2) Use Cases=
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].


'''WORK IN PROGRESS'''
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 and edge cases that should be treated as constraints/requirements, imposed on the specification/implementation of the component model.


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].
=General Use Cases=


==Built-in HTML Elements and Their Behaviors==
==Built-in HTML Elements and Their Behaviors==
Line 69: Line 69:
* 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.
* 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.
* 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.
===Tens of Thousands of Widgets===
 
==Layout Manager==
 
Does:
* provide a framework for client-side restructuring of content to accommodate layout
* support both imperative a declarative layout models
* provide templating/theming capabilities
 
Needs:
* shadow DOM
* content element (output ports)
* attachment using CSS and DOM
* separate instantiation and binding phases (or another way to allow asynchronous binding)
 
Could use:
 
Doesn't care:
* mutable templates
* xml:base handling
 
=Specific Use Cases=
 
 
==Tens of Thousands of Widgets==
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]).
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>
<pre>
Line 94: Line 117:
</pre>
</pre>


===Insertion Points, Not Containers===
==Insertion Points, Not Containers==
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:
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>
<pre>
Line 105: Line 128:
It is useful to think of the output port as a [https://developer.mozilla.org/en/DOM:range.collapsed collapsed range].
It is useful to think of the output port as a [https://developer.mozilla.org/en/DOM:range.collapsed collapsed range].


===Shadow Subtree Mutation===
==Shadow Subtree Mutation==
Because content element is an insertion point, what happens when the elements around it change? What happens when the insertion point moves?
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?  
* '''Modifying includes attribute'''. What happens when you modify the <code>includes</code> element on the output port?  
Line 141: Line 164:
What happens?
What happens?


===Dynamicity of Rules===
==Dynamicity of Rules==
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:
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>
<pre>
Line 168: Line 191:
</pre>
</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.
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.
==Layout Manager==
Does:
* provide a framework for client-side restructuring of content to accommodate layout
* support both imperative a declarative layout models
* provide templating/theming capabilities
Needs:
* shadow DOM
* content element (output ports)
* attachment using CSS and DOM
* separate instantiation and binding phases (or another way to allow asynchronous binding)
Could use:
Doesn't care:
* mutable templates
* xml:base handling

Revision as of 17:19, 1 January 2011

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 XBL2 Spec.

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 and edge cases that should be treated as constraints/requirements, imposed on the specification/implementation of the component model.

General Use Cases

Built-in HTML Elements and Their Behaviors

Does:

  • provide a uniform way to browsers to implement complex HTML elements, such as video/audio, sliders, progress elements, etc. possibly using scripting.
  • provide light-weight implementations of specialized markup languages

Needs:

  • shadow DOM
  • UA-level attachment
  • ability to designate and use DOM SPIs only within the shadow scope
  • ability to completely hide implementation details from author and user
  • restricted post-UA-level styling using pseudoclasses
  • style/event propagation control at the borders of the shadow DOM
  • high performance, especially compared to native implementation

Could use:

  • declarative templating/binding

Doesn't care:

  • mutable templates
  • dynamic attachment/detachment
  • template inheritance
  • attachment using CSS or DOM
  • content element (output ports), since they can't have children (this may change)
  • attribute/pseudo forwarding
  • xml:base handling

Interesting scenarios:

  • If an input range element is implemented using this functionality, what happens to its shadow DOM if author attempts to add shadow DOM to that element?
  • Implement a video/audio element. How can the binding reach into a private supporting API that is not available to the author?

Custom Widget System

Does:

  • 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:

  • shadow DOM
  • content element (output ports)
  • style/event propagation control at the borders of the shadow DOM
  • 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

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

Does:

  • provide a framework for client-side restructuring of content to accommodate layout
  • support both imperative a declarative layout models
  • provide templating/theming capabilities

Needs:

  • shadow DOM
  • content element (output ports)
  • attachment using CSS and DOM
  • separate instantiation and binding phases (or another way to allow asynchronous binding)

Could use:

Doesn't care:

  • mutable templates
  • xml:base handling

Specific Use Cases

Tens of Thousands of Widgets

The implementation should be able to efficiently handle a very large number of instances from the same template (see discussion). 

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

Insertion Points, Not Containers

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: 

<template>
    <p>Once upon a time,
    <content includes="p">
    <p>And they lived happily ever after
</template>

It is useful to think of the output port as a collapsed range.

Shadow Subtree Mutation

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 includes element on the output port?
  • Nested shadow subtrees. Suppose you have two bindings, one applied inside another:
<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>

Sequence of actions:

  1. Add a div element to div#bar.
  2. Move content element in div#bar template as the first child of div

What happens?

Dynamicity of Rules

As XBL2 spec'd today, the 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: 

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

Here, the importance of the news item is controlled outside of the shadow subtree. By setting/removing class breaking 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.

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