- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Wed, 24 Aug 2011 13:13:33 +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!!';
This is getting a bit better, more XBL2-like, but just with different
syntax :)
Adam already sent comments about most of the things I had in mind
and I'm especially interested to know about
"This section <http://wiki.whatwg.org/wiki/Component_Model#Consistency>
seems to imply that components can override the traversal and
manipulation APIs defined by DOM Core." since that could have major
effects to browser engine architecture. If all the APIs could be
overridden, and browser engine is expected to call the JS implemented
versions, the problems we have now with mutation events would be there
with all the DOM methods.
The wiki page doesn't mention at all how events are propagated.
I assume mousemove events should be fired in the real dom, but also in
shadow dom? mouseover/out should in some cases fire only in shadow dom,
but in some cases both in shadow and real...etc.
Is the idea to clone events like in XBL2, or propagate but
re-target like in XBL1 or what?
-Olli
>
> 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 Wednesday, 24 August 2011 10:14:08 UTC