[Bug 27762] [Custom]: what happens with Unresolved Elements when removed from the tree?

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

--- Comment #2 from Gabor Krizsanits <gkrizsanits@mozilla.com> ---
(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."

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 6 January 2015 13:32:40 UTC