- From: Hayato Ito <hayato@chromium.org>
- Date: Thu, 07 May 2015 01:27:44 +0000
- To: Ryosuke Niwa <rniwa@apple.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, Elliott Sprehn <esprehn@chromium.org>, Domenic Denicola <d@domenic.me>, Justin Fagnani <justinfagnani@google.com>, WebApps WG <public-webapps@w3.org>, Erik Bryn <erik@erikbryn.com>, Dimitri Glazkov <dglazkov@google.com>, "Edward O'Connor" <eoconnor@apple.com>, Steve Orvell <sorvell@google.com>
- Message-ID: <CAFpjS_2LoiYtgJ-JUaAh9YZY1f_v1D=BwYfy+pwW4mh5sjO42w@mail.gmail.com>
I'm feeling that there is a misunderstanding about the relation between DOM tree and Composed Tree in this discussion. If you understand the difference, the discussion might be more productive. In short, - Composed Tree DOES NOT replace DOM tree. Most of existing APIs work for DOM tree. Composed Tree doesn't have any affect on (most of) existing APIs. - Composed Tree is used in resolving CSS inheritance. That's all, except for a few exception. On Thu, May 7, 2015 at 10:18 AM Hayato Ito <hayato@chromium.org> wrote: > On Wed, May 6, 2015 at 10:22 AM Ryosuke Niwa <rniwa@apple.com> wrote: > >> >> > On May 5, 2015, at 11:55 AM, Tab Atkins Jr. <jackalmage@gmail.com> >> wrote: >> > >> > On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa <rniwa@apple.com> wrote: >> >>> On May 4, 2015, at 10:20 PM, Anne van Kesteren <annevk@annevk.nl> >> wrote: >> >>> >> >>>> On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn <esprehn@chromium.org> >> wrote: >> >>>> We can solve this >> >>>> problem by running the distribution code in a separate scripting >> context >> >>>> with a restricted (distribution specific) API as is being discussed >> for >> >>>> other extension points in the platform. >> >>> >> >>> That seems like a lot of added complexity, but yeah, that would be an >> >>> option I suppose. Dimitri added something like this to the imperative >> >>> API proposal page a couple of days ago. >> >>> >> >>> >> >>>> One thing to consider here is that we very much consider >> distribution a >> >>>> style concept. It's about computing who you inherit style from and >> where you >> >>>> should be in the box tree. It just so happens it's also leveraged in >> event >> >>>> dispatch too (like pointer-events). It happens asynchronously from >> DOM >> >>>> mutation as needed just like style and reflow though. >> >>> >> >>> I don't really see it that way. The render tree is still computed from >> >>> the composed tree. The composed tree is still a DOM tree, just >> >>> composed from various other trees. In the "open" case you can access >> >>> it synchronously through various APIs (e.g. >>> if we keep that for >> >>> querySelector() selectors and also deepPath). >> >> >> >> I agree. I don't see any reason node distribution should be considered >> as a style concept. It's a DOM concept. There is no CSS involved here. >> > >> > Yes there is. As Elliot stated in the elided parts of his quoted >> > response above, most of the places where we update distribution are >> > for CSS or related concerns: >> > >> > # 3 event related >> > # 3 shadow dom JS api >> >> These two are nothing to do with styles or CSS. >> >> > I'd like to inform all guys in this thread that Composed Tree is for > resolving CSS inheritance by the definition. > See the "Section 2.4 Composed Trees" in the spec: > http://w3c.github.io/webcomponents/spec/shadow/#composed-trees > > Let me quote: > > If an element doesn't participate in a composed tree whose root node is > a document, the element must not appear in the formating structure [CSS21] > nor create any CSS box. This behavior must not be overridden by setting the > 'display' property. > > > In resolving CSS inheritance, an element must inherit from the parent > node in the composed tree, if applicable. > > The motivation of a composed tree is to determine the parent node in > resolving CSS inheritance. There is no other significant usages, except for > event path. > > > >> >> I have issues with the argument that we should do it lazily. On one >> hand, if node distribution is so expensive that we need to do it lazily, >> then it's unacceptable to make event dispatching so much slower. On the >> other hand, if node distribution is fast, as it should be, then there is no >> reason we need to do it lazily. >> >> >> >> The problem is really the redistributions. If we instead had explicit >> insertion points under each shadow host, then we wouldn't really need >> redistributions at all, and node distribution can happen in O(1) per child >> change. >> > >> > As repeatedly stated, redistribution appears to be a necessity for >> > composition to work in all but the most trivial cases. >> >> Where? I have not yet to see a use case for which selective >> redistribution of nodes (i.e. redistributing only a non-empty strict subset >> of nodes from an insertion point) are required. >> >> - R. Niwa >> >>
Received on Thursday, 7 May 2015 01:28:12 UTC