Re: document.register and ES6

On Tue, Feb 5, 2013 at 5:28 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> So in particular this allows creation of "uninitialized" instances in some
> sense, yes?

Depends how much logic is put in the constructor vs @@create. For DOM
Elements I think we want to put *all* the logic in create. @@create
does not allow any parameters so for Image for example, we want to put
the src, width and height handling in the constructor. I don't think
there is any problem here.

> This won't work right given how HTMLButtonElement is currently defined in
> WebIDL.  Need to fix that at the very least.

Yes, but for document.register I think we can get away without
changing this. We might need to add no op call methods to these
functions but that seems like the right thing to do anyway. The WebIDL
interface constructors are already strange as they are and I doubt
anyone would object to making them less strange.

>
>
>> MyButton.prototype = Object.create(HTMLButtonElement.prototype, {
>>    ...
>> });
>> document.register(‘x-button’, MyButton);
>
>
> And the point is that document.register changes the [[Construct]] of
> MyButton but does nothing else with it?

Yes.

> What happens if the same function is registered for several different tag
> names, in terms of what happens with the [[Construct]]?

I vote for throwing. We could allow the tag name to be used as an
alias but I don't really understand the use case you have in mind
here.

>> * Just before entering script,
>
> Define, please.  How does one determine this, in a rendering engine
> implementation?  I certainly have no way to tell, in Gecko, when I'm
> "entering script", offhand....

I was told this is needed for mutation observers that are queued up
during parse. I'll let Dimitri or Rafael chime in with details.

--
erik

Received on Tuesday, 5 February 2013 23:02:28 UTC