This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24861 - [Shadow]: Add a way to detect when the list of nodes distributed to an insertion point mutates
Summary: [Shadow]: Add a way to detect when the list of nodes distributed to an insert...
Status: RESOLVED DUPLICATE of bug 21149
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 22715
  Show dependency tree / graph
 
Reported: 2014-02-28 15:52 UTC by Steve Orvell
Modified: 2015-04-23 19:13 UTC (History)
8 users (show)

See Also:

Attachments

Description Steve Orvell 2014-02-28 15:52:54 UTC 
This is a common need. I believe it's the use case motivating this bug and it's only stated here a bit more generally:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21149


It has been suggested that MutationObservers provide the tools for doing this. One could listen for a childList mutation on the shadowRoot.host (host A) and then examine if any of the added/removed nodes are now in a particular <content A> element's getDistributedNodes() list. However, this does not work with reprojection. In this case, the host's child is <content B>. If the list of nodes distributed to content B changes, the list of nodes distributed to content A changes without causing a childList mutation on host A.

<host B>
  <div></div>
  SR B
    <host A>
      <content B></content>
      SR A
        <content A></content>
    </host>
</host>

In this case, to use MutationObservers to detect changes in content A's list of distributed nodes, the developer would be forced to discover that changes to host B's childList are relevant and also attach a MutationObserver to it. This would be cumbersome in practice.

Here's an example that highlights this use case:

https://groups.google.com/forum/#!msg/polymer-dev/GMYzuuqlQ7k/U0tYEa-bYz0J


There are a variety of possible ways to address this. Some possibilities include:

 - <content> element could fire an event when the nodes distributed to it changes
 - a 'distributionList' mutation type could be added to MutationObservers, which would function when a <content> is observed
 - <content> could provide a method to register a distribution changed callback.
Comment 1 Elliott Sprehn 2014-02-28 18:01:59 UTC 
We also need to be able to detect when an element gets a ShadowRoot since that's conceptually like an "appendChild" like operation.

In general I think we need to expand MutationObserver to support Shadow DOM concepts.
Comment 2 Olli Pettay 2014-02-28 23:59:57 UTC 
(In reply to Elliott Sprehn from comment #1)
> We also need to be able to detect when an element gets a ShadowRoot since
> that's conceptually like an "appendChild" like operation.
Why would we need that. That is yet another way to expose more
internals of shadow dom management to the outer world, and we should
make encapsulation better, by default, not worse.
Comment 3 Daniel Buchner 2014-05-02 16:33:30 UTC 
(In reply to Olli Pettay from comment #2)
> (In reply to Elliott Sprehn from comment #1)
> > We also need to be able to detect when an element gets a ShadowRoot since
> > that's conceptually like an "appendChild" like operation.
> Why would we need that. That is yet another way to expose more
> internals of shadow dom management to the outer world, and we should
> make encapsulation better, by default, not worse.

There are many, many cases where this functionality is essential - I'll illustrate one I have faced:

A while back, I worked on a component that wrapped up drag and drop into a simple, declarative tag, <x-dragbox>. The component subscribed to all the drag/drop events, and allowed children of certain kinds to be draggable within it. The catch is that in order to "turn on" the DOM's drag/drop functionality for an element, you must first add the boolean attribute, draggable="".

For obvious reasons, this sucks. Instead of a simple, async event that keyed off the select="" filter for my allowed, draggable node types, it required me to setup a significant chunk of boilerplate using Mutation Observers and a redundant node filter. All this just so I could intercept added nodes and append the draggable="" attribute.

There are many more examples where this feature would dramatically reduce code complexity and boilerplate. (also note: MO's are on the 'advanced' side in terms of web API experience/difficulty, so it's not simple boilerplate for a huge percentage of web devs)
Comment 4 Elliott Sprehn 2014-06-26 21:44:05 UTC 
We should add a Mutation(In reply to Daniel Buchner from comment #3)
> (In reply to Olli Pettay from comment #2)
> > (In reply to Elliott Sprehn from comment #1)
> > > We also need to be able to detect when an element gets a ShadowRoot since
> > > that's conceptually like an "appendChild" like operation.
> > Why would we need that. That is yet another way to expose more
> > internals of shadow dom management to the outer world, and we should
> > make encapsulation better, by default, not worse.
> 
> There are many, many cases where this functionality is essential - I'll
> illustrate one I have faced:
> 
> A while back, I worked on a component that wrapped up drag and drop into a
> simple, declarative tag, <x-dragbox>. The component subscribed to all the
> drag/drop events, and allowed children of certain kinds to be draggable
> within it. The catch is that in order to "turn on" the DOM's drag/drop
> functionality for an element, you must first add the boolean attribute,
> draggable="".
> 
> For obvious reasons, this sucks. Instead of a simple, async event that keyed
> off the select="" filter for my allowed, draggable node types, it required
> me to setup a significant chunk of boilerplate using Mutation Observers and
> a redundant node filter. All this just so I could intercept added nodes and
> append the draggable="" attribute.
> 
> There are many more examples where this feature would dramatically reduce
> code complexity and boilerplate. (also note: MO's are on the 'advanced' side
> in terms of web API experience/difficulty, so it's not simple boilerplate
> for a huge percentage of web devs)

This has come up again for us too. It's critical for global page observing libraries and extensions like yours.

For example recently we removed beforeload events in Chrome and asked developers to use MutationObservers to watch for DOM mutations, but since they can't watch for ShadowRoots they end up not working in all the new web component based content. Similarly there's polyfill and behavior libraries that want to watch for global attributes on elements and previously could use MutationObserver, but can't because the content is inside a ShadowRoot.

Lets add a shadowRoots MutationObserverInit option.
Comment 5 Anne 2015-04-23 19:13:07 UTC 

*** This bug has been marked as a duplicate of bug 21149 ***