On Dec 7, 2013, at 1:29 PM, Domenic Denicola <[email protected]> wrote:
> From: Brendan Eich [mailto:[email protected]] > >> Requiring this kind of boilerplate out of the gave is not: >> >> this.createShadowRoot().appendChild(document.importNode(template.contents)); >> >> Wanting to avoid this kind of boilerplate is not a "stab in the dark". >> Why can't we avoid it, even with separate specs that compose well? Part of >> composing well is not requiring excessive boilerplate. > > Part of the issue is that I don't think that's the boilerplate people will be > using, uniformly. Adding a line to eliminate *that* boilerplate doesn't help > all the other cases, e.g. ones without a shadow DOM but instead a normal DOM, > or ones which don't use a template, or which don't use an imported template, > or which use multiple nodes. There are lots of ways to create a > fully-functioning custom element, and assuming that it will be done via a > single imported template element put into a shadow DOM seems like a stab in > the dark to me. In what way does that require using an imported template element specifically, as opposed to any template whatsoever? Note that importNode will DTRT whether the template comes from another document or not. Or even if I'm mistaken and it does not, you could specify that the template contents are cloned into the right document whether it was imported or not. Note also that using normal DOM instead of shadow DOM can be served by never using the optional feature (or by making a lightdom-template version if using custom elements with normal DOM becomes popular). Constructing shadow DOM programmatically can also be served by not using the optional feature, or by > The other aspect of my critique was that scenario-solving this particular use > case isn't very useful in light of the large number of other things people > will be building out of our building blocks. Why assume this scenario is more > common than, say, HTML imports + template elements? Why not add sugar for > that? There's a lot of possible combinations that could benefit from some > unifying sugar, but we just don't know which of them are actually useful yet. It's fine to allow those other things. It just seems like using all three of Custom Elements, Shadow DOM and Templates could be smoothed out without precluding those other options. It also seems like Polymer uses those three things together, so it seems unlikely that no one will do it. Using these three technologies together is very natural and pretending otherwise seems like an excessive level of agnosticism to me. BTW, I do think using HTML imports + template elements needs more sugar (there is no easy way afaik to instantiate a template defined in an imported document), but I am not sure it serves the same use cases. Regards, Maciej
