Re: [webcomponents] Async Registration of Custom Elements

On Thu, 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).
>
>
But... there is no replacement behavior? The spec was carefully design to
explicitly avoid that. In itself, the "upgrade" is a process of setting
prototype: http://w3c.github.io/webcomponents/spec/custom/#dfn-set-prototype

:DG<