This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It starts with: 1. Let ELEMENT be the context object But there is no context object here. This is the constructor; it needs to create the element. The element doesn't exist yet at this point.
(In reply to Boris Zbarsky from comment #0) > It starts with: > > 1. Let ELEMENT be the context object > > But there is no context object here. This is the constructor; it needs to > create the element. The element doesn't exist yet at this point. If you look at http://es5.github.io/#x13.2.2, you can clearly see that the constructor is actually called on an object after it is created.
You're not defining the [[Construct]]. You're defining part of the [[Call]] of the Web IDL constructor, which doesn't have a useful context object as Web IDL is specified right now. In particular, the "this" value when the [[Call]] is invoked in this case is some random JS object (the one the default [[Construct]] allocated), not an Element instance. In particular, the relevant part of Web IDL is step 5 of the [[Call]] internal method of interface objects, which does: 5. Let R be the result of performing the actions listed in the description of constructor with values as the argument values. and what you're doing is providing said list of actions. Which means its result needs to be R (in this case the Element). Once ES6 gets its @@create/whatever story in order and Web IDL is updated accordingly we'll see what custom elements needs to say here to sync up with that. But for now what it says is nonsensical, sorry. It needs to be actually creating the element it wants to return from [[Call]].
(In reply to Boris Zbarsky from comment #2) > You're not defining the [[Construct]]. No, I am defining F in that algo. I could make that more clear. The verbiage just before that ("Let CONSTRUCTOR be the interface object whose interface prototype object is PROTOTYPE and when called as a constructor, executes these steps") tries to do the thing you're describing below. > > You're defining part of the [[Call]] of the Web IDL constructor, which > doesn't have a useful context object as Web IDL is specified right now. In > particular, the "this" value when the [[Call]] is invoked in this case is > some random JS object (the one the default [[Construct]] allocated), not an > Element instance. > > In particular, the relevant part of Web IDL is step 5 of the [[Call]] > internal method of interface objects, which does: > > 5. Let R be the result of performing the actions listed in the description > of > constructor with values as the argument values. > > and what you're doing is providing said list of actions. Which means its > result needs to be R (in this case the Element). > > Once ES6 gets its @@create/whatever story in order and Web IDL is updated > accordingly we'll see what custom elements needs to say here to sync up with > that. But for now what it says is nonsensical, sorry. It needs to be > actually creating the element it wants to return from [[Call]]. Right. In a way, I am trying to straddle the magical Web IDL land and the barren ES5 land until ES6 comes along. Would love any specific diffs/patches on how that could be made better.
> No, I am defining F in that algo. Ah. So you're defining the steps that http://people.mozilla.org/~jorendorff/es6-draft.html#sec-built-in-function-objects-call-thisargument-argumentslist executes in step 9? But then this thing is not an "interface object" in the Web IDL sense, as you claim, because those in fact define different such steps. We need to harmonize this somehow. In any case, if these are steps for step 9 of [[Call]] they still have the problem I described. > tries to do the thing you're describing below I don't believe it succeeds, sorry. > Would love any specific diffs/patches on how that could be made better. My suggestion for how to do that is in comment 2: you say that this is a Web IDL constructor and then define the "actions listed in the description" to create and return an element with the right bits set. It's pretty much what you have, except instead of setting the (immutable) localName and namespace and so forth of the element you want to do something similar to what createElementNS does. On a side note, step 3 of http://w3c.github.io/webcomponents/spec/custom/#dfn-custom-element-constructor-generation seems to be dead? "REGISTRY" is never used...
Moved to https://github.com/w3c/webcomponents/issues/189