> On May 4, 2015, at 10:20 PM, Anne van Kesteren <ann...@annevk.nl> wrote:
>> On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn <espr...@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.

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.

- R. Niwa

Reply via email to