wiki:XBL2UseCases

Version 5 (modified by Dimitri Glazkov, 10 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 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

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

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