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: Mon, 27 Apr 2015 20:18:21 -0700
Cc: Olli Pettay <olli@pettay.fi>, Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>, Erik Bryn <erik@erikbryn.com>, Dimitri Glazkov <dglazkov@google.com>
Message-id: <1CABFF98-FB6D-4FF0-8916-094E12B5AE3A@apple.com>
To: Steve Orvell <sorvell@google.com>

> On Apr 27, 2015, at 7:32 PM, Steve Orvell <sorvell@google.com> wrote:
>> Perhaps we need to make childrenChanged optionally get called when attributes of child nodes are changed just like the way you can configure mutation observers to optionally monitor attribute changes.
> Wow, let me summarize if I can. Let's say we have (a) a custom elements synchronous callback `childrenChanged` that can see child adds/removes and child attribute mutations, (b) the first option in the proposed api here https://gist.github.com/rniwa/2f14588926e1a11c65d3, (c) user element code that wires everything together correctly. Then, unless I am mistaken, we have enough power to implement something like the currently spec'd declarative `select` mechanism or the proposed `slot` mechanism without any change to user's expectations about when information in the dom can be queried.

Right. The sticking point is that it's like re-introducing mutation events all over again if we don't do it carefully.

> Do the implementors think all of that is feasible?

I think something alone this line should be feasible to implement but the performance impact of firing so many events may warrant going back to micro-task timing and think of an alternative solution for the consistency.

> Possible corner case: If a <content> is added to a shadowRoot, this should probably invalidate the distribution and redo everything. To maintain a synchronous mental model, the <content> mutation in the shadowRoot subtree needs to be seen synchronously. This is not possible with the tools mentioned above, but it seems like a reasonable requirement that the shadowRoot author can be aware of this change since the author is causing it to happen.

Alternatively, an insertion point could start empty, and the author could move stuff into it after running. We can also add `removeAll` on HTMLContentElement or 'resetDistribution' on ShadowRoot to remove all distributed nodes from a given insertion point or all insertion points associated with a shadow root.

- R. Niwa
Received on Tuesday, 28 April 2015 03:18:51 UTC

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