Re: [w3c/webcomponents] Polymer encouraged incorrect document.createElement() usage (#544)

Yeah, so the way we're doing this is the string argument won't create customized built in elements (the new thing in the HTML living standard); to do that, authors will have to use the dictionary. [Here's the code.](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Document.cpp?l=725)

The upside of this is no other browser should have to handle the second string argument. At worst it might mean not throwing a TypeError but instead ignoring the argument.

The downside of this is that it makes it harder for authors to move code from `document.registerElement` to `customElements.define` because you need to migrate element creation code before/at the same time as definition code, which is a bit painful, and that could slow adoption of customized built-in elements. This cost is all borne by Chrome, which may end up having to support `document.registerElement` longer. Other browsers already decided not to implement `document.registerElement` so there's nothing new there.

(The way we have it now authors would have to change definition and creation code at the same time, IIRC. But I think this is overly onerous and we should allow the dictionary to create legacy custom elements so that authors can fix all their createElement/NS calls and then go back and port registerElement to define. But foolip had some questions about that and we've punted that decision for now.)

This is the best we could come up with but I'm open to feedback if there's a way to do it better.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/544#issuecomment-280273610