On 08/23/2011 11:40 PM, Dimitri Glazkov wrote:
All,
Over the last few weeks, a few folks and myself have been working on
fleshing out the vision for the Component Model. Here's what we've
done so far:
* Created a general overview document for behavior attachment problem
on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
* Wrote down the a set of guidelines on how we intend to tackle the
problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
* Updated the list of use cases and desired properties for each case
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
* Captured the overall component model design and how it satisfies
each desired property (http://wiki.whatwg.org/wiki/Component_Model),
including a handy comparison with existing relevant specs and
implementations
(http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations).
After of this iteration, the proposed shadow DOM API no longer
includes the .shadow accessor (see details here
http://dglazkov.github.com/component-model/dom.html). Instead, the
shadow DOM subtree association happens in ShadowRoot constructor:
var element = document.createElement("div");
var shadow = new ShadowRoot(element); // {element} now has shadow DOM
subtree, and {shadow} is its root.
shadow.appendChild(document.createElement("p")).textContent = "weee!!';
One thing missing is some kind of declarative way to define
shadow trees, similar to XBL1's <content>.
It would be rather strange if one needs to explicitly construct
shadow tree after the element is created.
(Component Model is getting closer and closer to XBL, and it is not
quite clear to me why XBL2 couldn't be used. It needs some
minor fixes, but should work otherwise.)
Keeping the accessor out allows for proper encapsulation and
confinement (better explanation of these new bits of terminology here:
https://plus.google.com/103035368214666982008/posts/AnGBpHZzQu6), and
also simplifies the API surface.
Please review. Feedback is welcome!
:DG<
