Most pseudo-classes I'm familiar with depend on a bit on the element itself. It seems in this case the bit is set once an element is a custom element, and is unset just before (or after?) the created callback is supposed to be invoked. Defining it a bit more clearly as custom elements having an "unresolved flag" might make this clearer.

(In reply to Anne from comment #1)
> Most pseudo-classes I'm familiar with depend on a bit on the element itself.
> It seems in this case the bit is set once an element is a custom element,
> and is unset just before (or after?) the created callback is supposed to be
> invoked. Defining it a bit more clearly as custom elements having an
> "unresolved flag" might make this clearer.

Yes, I like the flag approach.

The timing should also be more specific indeed. Does it make sense to set/unset the flag whenever we add/remove element from the upgrade candidates map? (before or after should not matter there) And then just decide how to handle removal from the tree before the created callback was called.

I would argue to just remove the element from the upgrade candidate map when a custom element is detached from the tree. But do we want to re-add it when the element is re-attached? Because if we do we should also specify what to do if we remove an element, change the |is| attribute on it and re-append. I don't think it would worth it based on the static nature it already has: "After a custom element is instantiated, changing the value of the is attribute must not affect this element's custom element type."

(In reply to Gabor Krizsanits from comment #2)
> The timing should also be more specific indeed. Does it make sense to
> set/unset the flag whenever we add/remove element from the upgrade
> candidates map?

Not clear whether http://w3c.github.io/webcomponents/spec/custom/#dfn-element-upgrade-algorithm removes entries from the map. I guess it should?


> I would argue to just remove the element from the upgrade candidate map when
> a custom element is detached from the tree.

Why? I don't see why removal from a tree is significant.


> "After a custom element is instantiated, changing the value of the is
> attribute must not affect this element's custom element type."

It would probably make more sense to store the original value of the is attribute in the map along with a pointer to the element that needs upgrading, no?

(In reply to Anne from comment #3)
> Not clear whether
> http://w3c.github.io/webcomponents/spec/custom/#dfn-element-upgrade-
> algorithm removes entries from the map. I guess it should?

I see no reason not to...

> It would probably make more sense to store the original value of the is
> attribute in the map along with a pointer to the element that needs
> upgrading, no?

That sounds good to me.

Specifying this explicitly as a flag SGTM.

Honing wording in the element upgrade algorithm to better highlight the fact that the element queue is indeed cleared (see step 4) SGTM too.

Also need to make the adding to the upgrade candidates map an explicit step during instantiation. This would help with explaining how the unresolved type extensions end up in the upgrade candidates map (so that we don't have to store the value of the "is" attribute).

(In reply to Dimitri Glazkov (AFK until Jan 5) from comment #5)
> Specifying this explicitly as a flag SGTM.

This is this bug.

> 
> Honing wording in the element upgrade algorithm to better highlight the fact
> that the element queue is indeed cleared (see step 4) SGTM too.

This is bug 27770.

> 
> Also need to make the adding to the upgrade candidates map an explicit step
> during instantiation. This would help with explaining how the unresolved
> type extensions end up in the upgrade candidates map (so that we don't have
> to store the value of the "is" attribute).

This is bug 27768.

(In reply to Anne from comment #1)
> and is unset just before (or after?) the created callback is supposed to be
> invoked.

Can we agree on the before/after part real quickly? (Both for the from-the-map-removal and for the flag unsetting)

(In reply to Gabor Krizsanits from comment #7)
> Can we agree on the before/after part real quickly? (Both for the
> from-the-map-removal and for the flag unsetting)

I would go with before:

* Unset the unresolved flag.
* Change the prototype.
* Remove from the map.
* Call the callback.

(In reply to Anne from comment #8)
> (In reply to Gabor Krizsanits from comment #7)
> > Can we agree on the before/after part real quickly? (Both for the
> > from-the-map-removal and for the flag unsetting)
> 
> I would go with before:
> 
> * Unset the unresolved flag.
> * Change the prototype.
> * Remove from the map.
> * Call the callback.

Sounds about right, except map removal happens earler. Here's the detailed view of how I am planning to amend the spec:

NEW: When creating a custom tag or type extension:
* Set the flag

EXISTING: When upgrading as part of registration (http://w3c.github.io/webcomponents/spec/custom/#dfn-element-registration-algorithm, step 7):
* Enqueue "createdCallback"
* Remove from the map (step 4 in http://w3c.github.io/webcomponents/spec/custom/#dfn-element-upgrade-algorithm)

NEW: Just before "createdCallback" is invoked, in http://w3c.github.io/webcomponents/spec/custom/#dfn-element-registration-algorithm:
* Unset the flag as first step.

Moved to https://github.com/w3c/webcomponents/issues/160