Version 5 (modified by 14 years ago) ( diff ) | ,
---|
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 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
Note:
See TracWiki
for help on using the wiki.