Custom elements created with "new" are not :defined

[dominiccooney]

Compare the steps for creating a custom element is created with 'new' using the HTMLElement constructor, versus creating one with create element or upgrading one.

Both create element and upgrade set custom element state; the HTML constructor doesn't. This means custom elements created with new will not match :defined.

On the other hand, if you were to tell me that the HTMLElement constructor step 4.1 implies doing create element, I would tell you I think that implies running the author's constructor a second time. I assume step 4.1 does not mean create element specifically.

[domenic]

Tentatively I think the fix is that HTMLElement() step 4 should get a new substep that sets the element's state to "custom".

Step 4.1 definitely does not imply "create an element". It's meant to be the lower-level Web IDL-ish operation for creating an instance of a given interface. (Via magic, without ever calling its constructor.)

[domenic]

This would also mean we could remove https://dom.spec.whatwg.org/#concept-create-element step 6.1.11 since it would happen automatically in 6.1.2.

[dominiccooney]

This has the nice side effect that :defined coincides with the prototype being set; there's fewer observable states an element can be in.

[kojiishi]

The change looks reasonable to me. We need @rniwa's attention here as he wrote a test for this.matches(':defined') to be false in the custom constructor.

[rniwa]

I don't think :defined should apply to a custom element while it's still being constructed.

[domenic]

@rniwa I don't think we have a choice. Given new XTag(), the only point at which the UA gets to run code is during the super() call to HTMLElement. That's the only time we can flip the flag...

[rniwa]

Oh I see, that's a good point.

[dominiccooney]

Yay!

[dominiccooney]

Ah, I think there may be a wrinkle with this we failed to anticipate.

First, I think it's 100% right to set "custom" in the HTMLElement constructor. It's the universal, consistent point to do that.

However this has the effect that attributeChangedCallbacks and so on start happening at that point. This means that if the constructor sets an attribute, two attributeChanged callbacks will be enqueued—one by the CEReactions tickled by the attribute setting, and a second as the upgrade steps are finishing. The same goes for connectedCallback.

I think upgrade should queue those notifications before running the constructor. That way the author gets a consistent sequence of notifications.

The side effect of attribute setting in the constructor causing reactions will continue to exist though. I don't see any way out of that, given we can't hook when the author's constructor or Reflect.construct call returns without changing ES6 semantics.

[domenic]

So to make sure I understand, the proposal would be to move the attributeChanged and connected calls in steps 8 and 9 of https://html.spec.whatwg.org/multipage/scripting.html#concept-upgrade-an-element to before step 3?

That seems to work OK:

• For constructors that do nothing that triggers [CEReactions], the result will be equivalent.
• For constructors that trigger CE reactions (in any way), the callbacks will fire at that time
  • For an element with no existing attributes whose constructor appends an attribute, attributeChangedCallback will fire a single time immediately after the setAttribute call.
  • For an element with an existing attribute A whose constructor appends an attribute B, attributeChangedCallback will fire twice, in sequence A then B, immediately after the setAttribute call.

I briefly considered the idea of saving the current set of attributes before step 3, but still firing in step 8. But then you get B then A in the last example, which is bad.

I think this is the best we can do if people do things they're explicitly advised not to do (viz. adding attributes, or in general touching the DOM in a way that would trigger CEReactions, inside constructors).

[dominiccooney]

Yes, the effects you describe are correct! I think the situation for connected is similar.