Changes between Version 4 and Version 5 of XBL2UseCases

Timestamp:

Dec 2, 2010, 8:51:03 AM (14 years ago)

Author:

Dimitri Glazkov

Comment:

--

XBL2UseCases

@@ -12 +12 @@
  * shadow DOM
  * UA-level attachment
- * Ability to completely hide implementation from consumer
- * Restricted post-UA-level styling using pseudoclasses
- * High performance
+ * 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:
@@ -25 +27 @@
  * attachment using CSS or DOM
  * content element (output ports), since they can't have children (this may change)
- * attribute forwarding
+ * attribute/pseudo forwarding
  * xml:base handling
 
@@ -32 +34 @@
 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
@@ -40 +45 @@
  * shadow DOM
  * content element (output ports)
+ * style/event propagation control at the borders of the shadow DOM
  * attachment using CSS and DOM
- * separation of instantiation and binding phases (or another way to allow asynchronous binding)
- * attribute forwarding
+ * separate instantiation and binding phases (or another way to allow asynchronous binding)
+ * attribute/pseudo forwarding
  * declarative templating/binding
 
@@ -51 +57 @@
 Doesn't care:
  * mutable templates
+ * xml:base handling
 
 === 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
+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
+ *