W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

From: Ryosuke Niwa <rniwa@apple.com>
Date: Wed, 06 May 2015 20:54:20 -0700
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, 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: <818580E0-2382-4C07-803E-E0AE7499039C@apple.com>
To: Hayato Ito <hayato@chromium.org>

> On May 6, 2015, at 6:18 PM, 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.

Event path / retargeting is definitely "event related", and it (e.g. deepPath) is definitely a part of "shadow DOM JS API".  Again, they're nothing to do with styles or CSS.

- R. Niwa
Received on Thursday, 7 May 2015 03:54:53 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC