Re: [webcomponents] Async Registration of Custom Elements

I'll also note that none of builtin HTML elements have "resolved" state.

If the goal of custom elements is:

"Rationalize the platform. The specification ensures that all of its new features and abilities are in concert with how the relevant bits of the Web platform work today, so that these new features could be used to explain the functionality of existing Web platform features, such as HTML elements."

as currently stated in the latest WG and ED, then we should not be adding new magical state to the platform.

- R. Niwa


On Jan 30, 2014, at 3:03 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

> 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