[Custom]: Make unresolved state an explicit flag. (bugzilla: 27762)

[hayatoito]

Title: [Custom]: Make unresolved state an explicit flag. (bugzilla: 27762)

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

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27762#c0
Gabor Krizsanits wrote on 2015-01-06 11:29:49 +0000.

This behaviour is undefined currently for the pseudoclass. Also not clear what should happen with them when re-appended to the tree.

---

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27762#c1
Anne wrote on 2015-01-06 12:19:25 +0000.

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.

---

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27762#c2
Gabor Krizsanits wrote on 2015-01-06 13:32:35 +0000.

(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."

---

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27762#c3
Anne wrote on 2015-01-06 14:06:36 +0000.

(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?

---

comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27762#c4
Gabor Krizsanits wrote on 2015-01-06 14:53:16 +0000.

(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.

---

comment: 5
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27762#c5
Dimitri Glazkov wrote on 2015-01-06 17:04:42 +0000.

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).

---

comment: 6
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27762#c6
Dimitri Glazkov wrote on 2015-01-06 17:24:43 +0000.

(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.

---

comment: 7
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27762#c7
Gabor Krizsanits wrote on 2015-01-08 10:44:46 +0000.

(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)

---

comment: 8
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27762#c8
Anne wrote on 2015-01-08 10:47:02 +0000.

(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.

---

comment: 9
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27762#c9
Dimitri Glazkov wrote on 2015-01-08 17:12:04 +0000.

(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.

[domenic]

Oh hey, I guess we already had an issue for this, it just wasn't tagged v1. #425 is a dupe of this and was fixed by 2432819.