Component Model 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 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 within the general use cases that should be treated as constraints/requirements, imposed on the specification/implementation of the component model.

General Use Cases

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

Requirements:

• provide a uniform way to browsers to implement complex HTML elements, such as video/audio, sliders, progress elements, etc. possibly using scripting.

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

Specialized Markup Languages

It's possible to imagine the component model to be used for lightweight implementations of specialized markup languages, such as MathML. This section needs work.

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.