[Custom]: Custom element constructor behavior makes no sense (bugzilla: 27016)

[hayatoito]

Title: [Custom]: Custom element constructor behavior makes no sense (bugzilla: 27016)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27016

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27016#c0
Boris Zbarsky wrote on 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.

---

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27016#c1
Dimitri Glazkov wrote on 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.

---

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27016#c2
Boris Zbarsky wrote on 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:

1. 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-(this-is-inserted-to-avoid-notification-in-migration)/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]].

---

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27016#c3
Dimitri Glazkov wrote on 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:

1. 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-(this-is-inserted-to-avoid-notification-in-migration)/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.

---

comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27016#c4
Boris Zbarsky wrote on 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...

[rniwa]

I think this constructor behavior is no longer relevant since we're using author defined constructor. See the issue #403 for new construction algorithm.