Re: document.register and ES6

On Tue, Feb 5, 2013 at 3:25 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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".  ;)
>

http://www.whatwg.org/specs/web-apps/current-work/#parsing-main-incdata

The first thing that happens upon encoutering </script> is performing a
microtask check point.

I think Arv is suggesting that running custom element constructors would be
included in this work.


> Thanks,
> Boris
>
>