Re: document.register and ES6

On 2/5/13 11:01 PM, Erik Arvidsson wrote:
> 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.

OK, I can live with that as long as the only arguments are things like 
for Image.  We'll have to be pretty careful about how we define our 
Element subclass constructors in the future, though...

And there are knock-on effects on all other objects in WebIDL.  See below.

>> 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.

No, you can't.  You really need to get WebIDL fixed here.

> We might need to add no op call methods to these
> functions

They already have [[Call]].  What they don't have is a custom 
[[Construct]].  Which means that they end up invoking the [[Construct]] 
defined in ES5 section 13.2.2, which in step 8 calls the [[Call]] and if 
that returns an object (which the WebIDL [[Call]] does) throws away the 
object that [[construct]] just created and returns the object [[Call]] 
returned.

And you can't no-op the [[Call]] because web pages, afaik, use things like:

   var myImage = Image();

and

   var xhr = XMLHttpRequest();

just like they use Date() and Object() and Array().  The above is 
supported for DOM constructors in at least Gecko and Presto, though 
apparently not Chrome or Safari; I don't have IE to test right now.  But 
the point is that right now those constructors are not particularly 
weird in Gecko and Presto, and I'm not entirely happy making them _more_ 
weird.

Maybe the fact that Chrome and Safari don't support this means that we 
can in fact redefine the [[Construct]] to create the right sort of 
object and then invoke [[Call]] which will actually initialize the 
object.  But that brings us back to being able to create 
partially-initialized objects for all IDL interfaces, not just elements....

Perhaps we need to define an IDL annotation for interfaces that opt in 
to this split between [[Call]] and [[Construct]] and then have elements 
opt in to it?

> but that seems like the right thing to do anyway. The WebIDL
> interface constructors are already strange as they are

Not in Gecko and Presto as far as I can tell...  Certainly not any 
stranger than Date or Array.

> and I doubt anyone would object to making them less strange.

I have no problem with less strange, but you're proposing more strange. 
  Again, as far as I can tell.

>> 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.

I don't have a use case.  What I have is an edge case that I can see 
implementations doing random non-interoperable crap for if we don't 
define it.

Throwing sounds fine to me.

>> 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.

Ah, OK.  Defining this stuff to happen at end of microtask or whatever 
it is that normally triggers mutation observers makes a lot more sense 
than "before entering script".  ;)

Thanks,
Boris

Received on Tuesday, 5 February 2013 23:26:16 UTC