| 1 | | == Component Model (aka XBL2) Use Cases == |
| 2 | | |
| 3 | | '''WORK IN PROGRESS''' |
| 4 | | |
| 5 | | 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]. |
| 6 | | |
| 7 | | === Built-in HTML Elements and Their Behaviors === |
| 8 | | |
| 9 | | Does: |
| 10 | | * provide a uniform way to browsers to implement complex HTML elements, such as video/audio, sliders, progress elements, etc. possibly using scripting. |
| 11 | | * provide light-weight implementations of specialized markup languages |
| 12 | | |
| 13 | | Needs: |
| 14 | | * shadow DOM |
| 15 | | * UA-level attachment |
| 16 | | * ability to designate and use DOM SPIs only within the shadow scope |
| 17 | | * ability to completely hide implementation details from author and user |
| 18 | | * restricted post-UA-level styling using pseudoclasses |
| 19 | | * style/event propagation control at the borders of the shadow DOM |
| 20 | | * high performance, especially compared to native implementation |
| 21 | | |
| 22 | | Could use: |
| 23 | | * declarative templating/binding |
| 24 | | |
| 25 | | Doesn't care: |
| 26 | | * mutable templates |
| 27 | | * dynamic attachment/detachment |
| 28 | | * template inheritance |
| 29 | | * attachment using CSS or DOM |
| 30 | | * content element (output ports), since they can't have children (this may change) |
| 31 | | * attribute/pseudo forwarding |
| 32 | | * xml:base handling |
| 33 | | |
| 34 | | Interesting scenarios: |
| 35 | | * 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? |
| 36 | | * Implement a video/audio element. How can the binding reach into a private supporting API that is not available to the author? |
| 37 | | |
| 38 | | === Custom Widget System === |
| 39 | | |
| 40 | | Does: |
| 41 | | * provide a uniform way (i.e. DOM) to declare widget APIs |
| 42 | | * encapsulate widget implementation details |
| 43 | | * enable control over how styles and events outside of a widget affect it |
| 44 | | * enable widget styling primitives |
| 45 | | * asynchronously instantiate and initialize widgets (for instance, display a widget without starting up a script context, then progressively enhance with script). |
| 46 | | * allow seamless reuse a widget written using various libraries or frameworks |
| 47 | | * allow using widgets declaratively, with minimal knowledge of the underlying implementation |
| 48 | | * provide a way to create new widgets by extending existing widgets |
| 49 | | |
| 50 | | Needs: |
| 51 | | * shadow DOM |
| 52 | | * content element (output ports) |
| 53 | | * style/event propagation control at the borders of the shadow DOM |
| 54 | | * attachment using CSS and DOM |
| 55 | | * separate instantiation and binding phases (or another way to allow asynchronous binding) |
| 56 | | * attribute/pseudo forwarding |
| 57 | | * declarative templating/binding |
| 58 | | |
| 59 | | Could use: |
| 60 | | * dynamic attachment/detachment |
| 61 | | * template inheritance |
| 62 | | |
| 63 | | Doesn't care: |
| 64 | | * mutable templates |
| 65 | | * xml:base handling |
| 66 | | |
| 67 | | Interesting scenarios: |
| 68 | | * Implement a "polaroid frame" widget? This widget, when bound to any element would display its contents in a Polaroid(tm)-like frame. |
| 69 | | * 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. |
| 70 | | * 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. |
| 71 | | * '''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: |
| 72 | | {{{ |
| 73 | | <template> |
| 74 | | <p>Once upon a time, |
| 75 | | <content includes="p"> |
| 76 | | <p>And they lived happily ever after |
| 77 | | </template> |
| 78 | | }}} |
| 79 | | |
| 80 | | |
| 81 | | === Layout Manager === |
| 82 | | |
| 83 | | Does: |
| 84 | | * provide a framework for client-side restructuring of content to accommodate layout |
| 85 | | * support both imperative a declarative layout models |
| 86 | | * provide templating/theming capabilities |
| 87 | | |
| 88 | | Needs: |
| 89 | | * shadow DOM |
| 90 | | * content element (output ports) |
| 91 | | * attachment using CSS and DOM |
| 92 | | * separate instantiation and binding phases (or another way to allow asynchronous binding) |
| 93 | | |
| 94 | | Could use: |
| 95 | | |
| 96 | | Doesn't care: |
| 97 | | * mutable templates |
| 98 | | * xml:base handling |
| 99 | | * |
| | 1 | Moved to http://wiki.whatwg.org/wiki/XBL2UsesCases |
