21149 2013-02-28 00:25:33 +0000 [Shadow]: Shadow DOM-based components could benefit from a way to detect when light DOM contents change 2015-05-27 03:23:35 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified All All RESOLVED MOVED P2 normal --- 28552 1 jan dglazkov dominicc ericbidelman hayato sjmiles sorvell travil public-webapps-bugzilla oldest_to_newest 83815 0 jan 2013-02-28 00:25:33 +0000 Currently, a Shadow DOM-based component has no easy way to know when its own light DOM contents change. This hampers the ability to handle a number of common UI component scenarios. Background: in evaluating Shadow DOM and custom element support in the QuickUI framework (http://quickui.org), it was discovered that Shadow DOM-based components don't have an easy way to receive notification when their light DOM contents change. Using the large existing QuickUI component library as a reference point, the ability to detect content changes appears to be a common need. See http://blog.quickui.org/2012/04/27/how-quickui-controls-use-code-to-specialize-the-handling-of-their-content-in-ways-that-might-not-be-supported-by-web-components/ for a summary of these scenarios. In QuickUI's case, approximately 25% of the UI components require some notification when their contents change, suggesting that many other components will have this requirement as well. While a component can work around this by wiring up a Mutation Observer to its own host element, that is fairly cumbersome. Moreover, such an observer would catch more changes than may be strictly be interesting to the component. E.g., if a component is grabbing a specific subset of the light DOM nodes, then it only needs to know when those specific nodes change. (Here, "change" could be: the set of nodes change, or the contents of those nodes change.) It would be beneficial if Shadow DOM-based components could more easily ask for notification when their contents change. I'm not sure what the best form for this would be. I'm also not sure whether this is best handled as a general Shadow DOM feature, or as a helper only available to custom elements. Custom elements already have an attributeChanged lifecycle method; perhaps there could also be a contentChanged lifecycle method. I've discussed this idea with Dimitri Glazkov in email, who asked me to file a spec bug to track it. 83840 1 dominicc 2013-02-28 21:36:42 +0000 I was thinking about this problem recently. I think Mutation Observers would work well for this, something like: var host = ...; // Create ShadowRoot var shadow = host.createShadowRoot(); // Populate ShadowRoot var template = ...; shadow.appendChild(template.content); // Observe light DOM changes var observer = new MutationObserver(function (mutations) { // Distribution may have changed; do imperative updates [].forEach.call(shadow.querySelectorAll('content'), function (content) { // Use content.getDistributedNodes() }); }); observer.observe(host, { subtree: true, attributes: true, childList: true }); (This over-observes to make this code succinct, but it is possible to use two observers to observe precisely what changes can affect distribution.) 90853 2 jan 2013-07-17 17:39:21 +0000 I'm working around this problem using an observer, but still feel like this is a general need. I've just posted a bit about this at https://groups.google.com/forum/#!topic/polymer-dev/Pq00wMmuPIw. 118103 3 travil 2015-02-24 00:54:00 +0000 I also agree that this is a general need. The current use-cases are all dealing with the problem from externally to the component, or from a POV where the host environment has full control/access to the shadowroot. In a possible world of more controlled isolation, especially where a component may only have limited access to its host, some form of change notifications would be handy. I don't have an idea of what these might look like, but the custom element's lifecycle methods could be a starting point... 119845 4 annevk 2015-04-23 19:13:08 +0000 *** Bug 24861 has been marked as a duplicate of this bug. *** 120528 5 hayato 2015-05-27 03:23:35 +0000 Moved to https://github.com/w3c/webcomponents/issues/62