Re: document.register and ES6

So we're removing the async nature of the API? How is this a good trade? I
thought this was one of the benefits? Is polyfilling still possible in a
sane way that adheres to the specified behavior?

Daniel J. Buchner
Product Manager, Developer Ecosystem
Mozilla Corporation


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

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