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 ​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 completely hide implementation from consumer
• Restricted post-UA-level styling using pseudoclasses
• High performance

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 forwarding
• xml:base handling

Custom Widget System

Does:

• provide a uniform way (i.e. DOM) to declare widget APIs
• 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)
• attachment using CSS and DOM
• separation of instantiation and binding phases (or another way to allow asynchronous binding)
• attribute forwarding
• declarative templating/binding

Could use:

• dynamic attachment/detachment
• template inheritance

Doesn't care:

• mutable templates

Layout Manager

• make easier the restructuring of content to accommodate layout, both in an imperative and a declarative way
• enable development of templating/theming frameworks