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. -Olli
