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.