Re: Separating Transclusion Mechanisms for Inheritance and Data Binding

I just saw Dimitri's reference to my “Filling slots in shadow” blog posts from a while back, so I thought I’d follow up with the experiences I’ve had I wrote it.

First, I remain convinced that it will be very helpful for Shadow DOM to provide a feature like this that allows for parent and child classes to cooperatively contribute elements to the same component. This is a key feature that enables well-factored user interface components. I started a company earlier this year that is building a site entirely on web components, and we’ve already hit the limitations of what’s possible without this feature.

Second, my colleagues and I found the pre-existing proposal to let authors reproject content into <shadow> to be an elegant solution to this problem. During the brief window when this feature was available in Chrome Canary, we quickly made use of it. It felt like a very natural extension of the Shadow DOM tree composition concepts we had already learned. That is, in our experience, the conceptual load introduced by this feature was low. To the extent the developer experience weighs in any decision here, we were completely fine with the approach of placing <content> insertion points inside <shadow> elements.

Third, we feel a modest amount of impatience to see this feature implemented in Chrome again, and for other browsers to adopt this feature as it existed in Chrome. It was meeting our needs, and seeing it (even temporarily) removed felt like a step backwards. We’re concerned that lack of a solution here will discourage people from applying subclassing as a means to factor user interface behavior into parent/child component class relationships.

Finally, even given all the above, we view it as more important that all the mainstream browsers implement the more fundamental aspects of Shadow DOM with all due speed. Our company and its customers are entirely dependent upon web components that use Shadow DOM, and while we can rely upon the Polymer library for cross-browser compatibility, there is a considerable different in performance between native and polyfilled Shadow DOM features. We test on a variety of browsers and devices, and while we can run on Mobile Safari or IE, performance on those platforms is barely acceptable. We would rather see the basics of Shadow DOM be native now, and live without defined semantics for parent/child contributions to shadow trees, than wait indefinitely for that feature before seeing native implementations of the basics.

I feel like something of an industry outsider in discussions related to web standards, and appreciate the range of scenarios those working on standards must consider as they debate proposals for changes. I trust the smart folks at Apple, Google, and elsewhere to make the right decision here. All I can offer here is my company's own practical experience in this domain. For our part, we would be very happy to see a solution adopted in the standard that follows the general lines of allowing reprojection of content into <shadow> elements, but in the meantime are primarily concerned with seeing native Shadow DOM implementations across all browsers.

–Jan