On 02/05/2015 02:24 AM, Dimitri Glazkov wrote:

However, I would like to first understand if that is the problem that the group 
wants to solve. It is unclear from this conversation.

Yes. The marketing speech for shadow DOM has changed over time from "do everything possible, 
make things awesome" to "explain the platform"
to the current "enable easier composition".
So it is not very clear to me what even the authors of the spec always want, 
this said with all the kindness :)

Personally I think composition piece itself doesn't legitimate the complexity 
of shadow DOM.
Though, it is not clear what composition means to different people. Is the need 
for insertion points part of
composition? In my mind it might not be. It is part of the stronger 
encapsulation where
one has hidden DOM between a parent node and a child node.
Is event retargeting part of composition? It might not, if composition was to 
deal with nodes which are all in document
(and if nodes part of the composition were in document, we wouldn't have all 
the is-in-document issues).
And so on.

That said, I think we should aim for something stronger than just enabling 
easier composition.
The end goal could go as far as let pages to implement their own form controls. 
And to make that
all less error prone for the users of such components requires encapsulation.
So, start with composition but keep the requirements for the proper 
encapsulation in mind by not introducing
syntaxes or APIs which might make implementing encapsulation harder.

Are there cases where encapsulation and composition contradicts? I guess that 
depends on the definition of those both.


Reply via email to