On Thu, Jan 30, 2014 at 3:03 PM, Ryosuke Niwa <rn...@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<