Re: Shadow DOM: state of the distribution API

The 3 proposal is what the houdini effort is already researching for custom
style/layout/paint. I don't think it's acceptable to make all usage of
Shadow DOM break when used with libraries that read layout information
today, ie. offsetTop must work. I also don't think it's acceptable to
introduce new synchronous hooks and promote n^2 churn in the distribution.

Distribution is an async batched operation that can happen in a separate
scripting context. There's no issue with re-entrancy there, and it allows
us to define a nice functional style API that lets you rebuild what we have
today (and more).

shadowRoot.registerCustomDistributor("src.js");

src.js:

distributenodes = function(Array<Candidate> candidates,
Array<InsertionPoint> insertionPoints) {
  // For each candidate add it to the insertionPoint you want.
};

Candidates are objects of:

{
  tagName: string,
  attributes: Map<string, string>
}

InsertionPoints are objects of:

{
  attributes: Map<string, string>
  add: function(candidate) { ... }
}

That allows you to rebuild <content select>, implement pseudo classes in
content select like :first-child and :nth-child which were originally in
the spec but were removed, and also allows you to implement new features
like <content order={n}> so you can order the distribution process instead
of it being in tree order. This also means the browser can distribute on
another thread. :)

On Wed, May 6, 2015 at 1:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, May 6, 2015 at 11:07 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> > On Wed, May 6, 2015 at 7:57 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >> Has at-end-of-microtask been debated rather than 1/2? Synchronous
> >> always has the downside that the developer has to deal with
> >> reentrancy.
> >
> > 1/2 are triggered by the component author.
>
> So component author code isn't triggered when a webpage does
> element.appendChild() if 'element' is a custom element?
>
> FWIW, I am by no means trying to diminish the task that adding async
> layout APIs would be. Though it might not be that different in size
> compared to the '3' proposal.
>
> / Jonas
>
>