Re: document.register and ES6

On Tue, Feb 5, 2013 at 5:31 PM, Daniel Buchner <daniel@mozilla.com> wrote:

>
> 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?
>
>
Before the code of the <script> element is run, yes.


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