- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Thu, 25 Aug 2011 11:41:17 +0300
- To: Dimitri Glazkov <dglazkov@chromium.org>
- CC: public-webapps <public-webapps@w3.org>, Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>
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<
>
>
Received on Thursday, 25 August 2011 08:42:07 UTC