W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

Re: [webcomponents] Async Registration of Custom Elements

From: Dimitri Glazkov <dglazkov@google.com>
Date: Tue, 11 Feb 2014 15:42:58 -0800
Message-ID: <CADh5Ky0es3cVb65bgyXngsUk7BZVOtAcBnHH+q333Mzxg3oJqA@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: "public-webapps@w3.org WG" <public-webapps@w3.org>
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

Received on Tuesday, 11 February 2014 23:43:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:21 UTC