On Thu, Apr 30, 2015 at 6:22 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Thu, Apr 30, 2015 at 3:05 PM, Hayato Ito <hayato@chromium.org> wrote:
> > That's the exactly intended behavior in the current spec.
> > The timing of distribution is not observable.
>
> Right, but you can synchronously observe whether something is
> distributed. The combination of those two things coupled with us not
> wanting to introduce new synchronous mutation observers is what
> creates problems for an imperative API.
> So if we want an imperative API we need to make a tradeoff. Do we care
> about offsetTop et al or do we care about microtask-based mutation
> observers? I'm inclined to think we care more about the latter, but
> the gist I put forward takes a position on neither and leaves it up to
> web developers when they want to distribute (if at all).
>
We don't need to pick from either of those choices. 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.
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.
We don't want synchronous reflow inside appendChild because it means
authors would have to be very careful when mutating the DOM to avoid extra
churn. Distribution is the same way, we want it async so the browser can
batch the work and only distribute when the result is actually needed.
In our code if you look at the very few places we update distribution
explicitly:
3 event related
3 shadow dom JS api
9 style (one of these is flushing style)
1 query selector (for ::content and :host-context)
And all other places where distribution wants to be updated are because we
flush style (or layout) because what that caller really wanted to know was
something about the rendering.
- E