== 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: * 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) === Custom User Interface 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 Needs: * content element (output ports) * attachment using CSS and DOM 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