Re: document.register and ES6

So does this...

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

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

...imply that the user agent will ensure all known components/definitions
are strapped, and that elements are upgraded in a sync-ish fashion before
user code is run?

On Tue, Feb 5, 2013 at 5:22 PM, Rafael Weinstein <rafaelw@google.com> wrote:

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