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

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

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

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