- From: Domenic Denicola <domenic@domenicdenicola.com>
- Date: Sat, 7 Dec 2013 21:29:02 +0000
- To: Brendan Eich <brendan@secure.meer.net>
- CC: Ryosuke Niwa <rniwa@apple.com>, Erik Arvidsson <arv@chromium.org>, "Maciej Stachowiak" <mjs@apple.com>, Elliott Sprehn <esprehn@chromium.org>, Webapps WG <public-webapps@w3.org>
From: Brendan Eich [mailto:brendan@secure.meer.net] > 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. 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.
Received on Saturday, 7 December 2013 21:29:34 UTC