Hi,
Could someone clarify why we want to allow out-of-order registration of custom
elements? Can we also have (a pointer to) concrete use cases for this feature?
The thing is if an author wants to replace or customize a placeholder element
using a script that loads later, that’s pretty easy to achieve in the script
itself:
// Placeholder elements already exist in the document.
document.registerElement(…); // This line of code is present no matter what.
// Four more lines of code finish the job.
var placeholders = document.querySelectorAll(…);
for (var placeholder of placeholders)
placeholder.parentNode.replaceChild(…);
techcrunch.com does this for all of its <like> buttons, for example — although
they do the replacement on hover, and not on load.
There’s very little upside to building replacement behavior into the browser
engine when it’s so easy to achieve in script — and the script had to run
anyway in order to document.registerElement(). In fact, it may be actively
harmful in preventing developers from implementing potentially desirable
patterns (e.g. Techcrunch’s on demand replacement, which may be advantageous if
the components are expensive).
Furthermore, synchronous loading of all scripts that define custom elements is
not required to unblock the browser's main thread from keep parsing and
processing the other page contents.
What is required is that scripts that want to load asynchronously and define
custom elements that replace placeholder elements in the document must also
define the replacement behavior — Should I make a new element and remove the
placeholder element? Should I make a new element that’s a child of the
placeholder element? Should I move some of the contents of the placeholder
element into the new element? Should the placeholder element remain in the DOM
somewhere? What happens to event listeners and custom properties added to the
placeholder element? Styles? etc...
Building a one-size-fits-all solution to these questions into the browser
appears to be the root cause of many complexities in the current specification
like nodes that automatically become other nodes and JavaScript wrappers that
get “nulled out” — whatever that means. It’s fundamentally weird to replace
one node with another node and yet try to pretend that no invariants of the
first node have been violated. It seems much saner to require the author to
actually replace the old node with a new node, or perform some other well-known
DOM manipulation instead.
(Credit: Geoffrey Garen & Gavin Barraclough).
- R. Niwa
