27016 2014-10-10 13:06:36 +0000 [Custom]: Custom element constructor behavior makes no sense 2015-07-06 08:08:23 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED MOVED P2 normal --- 14968 1 bzbarsky dglazkov annevk gkrizsanits mike public-webapps public-webapps-bugzilla oldest_to_newest 112945 0 bzbarsky 2014-10-10 13:06:36 +0000 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. 112959 1 dglazkov 2014-10-10 16:23:48 +0000 (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. 112961 2 bzbarsky 2014-10-10 16:42:39 +0000 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]]. 112962 3 dglazkov 2014-10-10 17:07:36 +0000 (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. 112963 4 bzbarsky 2014-10-10 17:30:42 +0000 > 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... 121623 5 hayato 2015-07-06 08:02:51 +0000 Moved to https://github.com/w3c/webcomponents/issues/189 121673 6 hayato 2015-07-06 08:08:23 +0000 Moved to https://github.com/w3c/webcomponents/issues/189