W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: Component Model Update

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Wed, 24 Aug 2011 10:09:01 -0700
Message-ID: <CADh5Ky1wrLttbqUzyck=F9CoXf7YH2jdaswydnkYAZdoHxTKUA@mail.gmail.com>
To: olli@pettay.fi
Cc: public-webapps <public-webapps@w3.org>, Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>
Hi Olli!

On Wed, Aug 24, 2011 at 3:13 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> 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
> :)

I am glad you like it!

> 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?

The event propagation is already mostly spec'd out here:

Propagation through <content> element and handling evenets for the
confinement primitives isn't yet done.


> -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 17:12:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC