This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Not sure if this is worth it... Consider adding named templates to a collection on the ShadowRoot. Many systems for dealing with templates now "hold on" to the references and deal with them by name to avoid re-lookups. The browser maintains numerous indexes like this already and the advantage to doing it at that layer is that it is easy to remove templates from the collection as they are removed from the DOM. Currently, that's a problem in some implementations. Adding some IDL explaining what I am saying... [Constructor(in HTMLElement host) raises (DOMException)] interface ShadowRoot : DocumentFragment { HTMLElement getElementById(in DOMString elementId); NodeList getElementsByClassName(in DOMString tagName); NodeList getElementsByTagName(in DOMString className); NodeList getElementsByTagNameNS(DOMString namespace, DOMString localName); attribute bool applyAuthorStyles; readonly attribute Element host; readonly attribute Element activeElement; readonly attribute Selection selection; attribute DOMString innerHTML; DocumentFragment getTemplate(DOMString name); } ShadowRoot implements NodeSelector; dictionary Template { DOMString name; DocumentFragment template; };
Haha, I can't edit my own issue :) Template in the IDL is merely informative for describing the idea, it's not public facing as you can see.
This is the wrong way to think about it. From the browser implementation perspective, it just needs to be fast at returning querySelectorAll('template'). Adding an additional collection just attempts to expose this need. FWIW, I would love to get rid of all of those accessors and only use find and findAll. Let's not add more. Let's get rid of them! :)