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 

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.


Reply via email to