- From: Dominic Cooney <dominicc@google.com>
- Date: Thu, 25 Aug 2011 23:04:19 +0900
- To: olli@pettay.fi
- Cc: Dimitri Glazkov <dglazkov@chromium.org>, public-webapps <public-webapps@w3.org>, Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>
On Thu, Aug 25, 2011 at 5:41 PM, 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!!';
>
>
> 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.
Looking at the use cases, it looks like components need to run script
anyway, at least to hook up event listeners. So would it be fair to
rephrase this as: “There should be a concise way to get HTML into a
shadow tree.” ?
> (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.)
I feel like XBL2 doesn’t get the power-to-weight ratio right—it looks
hard to use and implement, and as this
<http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations>
summarizes XBL2 doesn’t mesh well with JavaScript, and doesn’t get
confinement. So this proposal looks like it made a good tradeoff…
eliminate a lot of what’s complex to use and implement in XBL2, and
focusses instead on useful capabilities like confinement.
Dimitri et al studied XBL2 in depth in designing the component model.
It is possible when you follow through with minor fixes to XBL2 you
will end up here anyway… it might be more productive to work on
fleshing out and fixing this proposal.
>> 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 14:04:44 UTC