== Component Model (aka XBL2) Use Cases == '''WORK IN PROGRESS''' 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 Interesting scenarios: * If an input range element is implemented using this functionality, what happens to its shadow DOM if author attempts to add shadow DOM to that element? * Implement a video/audio element. How can the binding reach into a private supporting API that is not available to the author? === 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 Interesting scenarios: * Implement a "polaroid frame" widget? This widget, when bound to any element would display its contents in a Polaroid(tm)-like frame. * Suppose the widget system has a centralized "settings" widget, with which all other widgets should communicate to add their settings. Implement this communication, provided that all widgets are opaque elements. * Implement a "tab set" widget. As you add "tabs" to it, tab titles appear in a row at the top, and tab contents appear in the main area, only visible when the corresponding tab title is selected. * '''Output ports need to be insertion points, not cointainers'''. If the output port is a container (that is, an existing element in the shadow subtree is designated as a place to add the "light" nodes), some layout scenarios aren't possible. For example, for subtree, you can not use flexbox to layout all of the paragraphs in the story: {{{ }}} === 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 *