Component Model Use Cases

Component Model (aka XBL2) Use Cases

WORK IN PROGRESS

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.

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

Notes on output ports:

• 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 an element x-bar, instantiated from this template:

<template>
    <div>
        <x-foo>
            <span>Blah</span>
            <content includes="*">
       </x-foo>
    </div>

And x-foo is instantiated from this template:

<template>
    <span>
        <content includes="*">
    </span>
</template>

Sequence of actions:

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

What happens?

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