Re: [webcomponents] Async Registration of Custom Elements

On Feb 11, 2014, at 3:42 PM, Dimitri Glazkov <dglazkov@google.com> wrote:
> On Thu, Jan 30, 2014 at 3:03 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> 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

Sorry, I guess my explanation wasn’t clear here.

The “replacement” behavior we’re talking about here isn’t about element or its prototype objects in JS.  We’re talking about elements’  transition from “unresolved” state to “resolved” / “instantiated” state.

Since the right behavior (e.g. reserve blank space, not showing them at all, etc…) is different for each use case, let’s not bake one into the browser engines.  If authors wanted to define customs elements asynchronously, they could do so and explicitly replace “unresolved” elements as they wish with a few lines of scripts.

- R. Niwa