[webcomponents] Async Registration of Custom Elements

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