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

From WHATWG Wiki
Jump to navigation Jump to search

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

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

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