Changes between Version 8 and Version 9 of XBL2UseCases


Ignore:
Timestamp:
Dec 16, 2010 1:36:20 PM (9 years ago)
Author:
Dimitri Glazkov
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • XBL2UseCases

    v8 v9  
    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  *
     1Moved to http://wiki.whatwg.org/wiki/XBL2UsesCases