Version 4 (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 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
Note:
See TracWiki
for help on using the wiki.