Re: Monkeypatching document.createElement() is wrong

+others who have been involved in the design phase of the Google proposal

So there are several viable points in the design space here. I'll try to
outline them quickly:


   1. An internal lifecycle driver for element + shadow creation.
   In this strategy, an element's constructor either calls
   createShadow()/finalizeInitialization() methods directly, or calls the
   superclass constructor to ensure that they are invoked.
   2. External lifecycle driver.
   In this design, it's up to whoever new's up an Element to ensure that
   it's fully formed before injecting it into the DOM.

The current design codifies the second.

Regarding Audio() and Image(), it's possible to model them as having
internal "already called" flags on their shadow creation methods that
prevent double initialization by createElement(). But I agree that it's
messier and muddies the de-sugaring story.

Dimitri? Dominic?

On Tuesday, February 12, 2013, Anne van Kesteren wrote:

> If the goal of custom elements is to expose the guts of what happens
>
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#monkeypatch-create-element
> is the wrong solution. Currently new Image() and createElement("img")
> are equivalent and no additional magic is required. Same for new
> Audio() and createElement("audio"). What we want is that
>
> var x = document.createElement(name)
>
> maps to / is identical to
>
> var x = new name's-corresponding-object
>
> and nothing else.
>
>
> --
> http://annevankesteren.nl/
>
>