> On May 5, 2015, at 11:55 AM, Tab Atkins Jr. <jackalm...@gmail.com> wrote:
> On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa <rn...@apple.com> wrote:
>>> 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.
> 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 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

Reply via email to