Implement the Custom Elements :unresolved pseudoclass

Implement the Custom Elements :unresolved pseudoclass

The :unresolved pseudoclass lets Custom Element authors avoid flash of unstyled content until their Custom Element definitions load.

This is a trivial initial implementation because element upgrade is not implemented yet.

BUG=237215
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=149628

[dominicc (has gone to gerrit), 2013-05-02 07:11:00]

This relies on <https://codereview.chromium.org/14834002/> going first.

Because element upgrade currently happens at creation time or not at all, this
implementation is trivial--there is no need for style invalidation.

I'm particularly interested in the thoughts of storing Custom Element data
external to the element (ie CustomElementRegistry::m_unresolvedElements) because
I was planning to implement the upgrade candidate map this way.

[dglazkov, 2013-05-02 16:36:28]

LGTM.

https://codereview.chromium.org/14846002/diff/2001/Source/core/dom/CustomElem...
File Source/core/dom/CustomElementRegistry.h (right):

https://codereview.chromium.org/14846002/diff/2001/Source/core/dom/CustomElem...
Source/core/dom/CustomElementRegistry.h:116: ElementSet m_unresolvedElements;
So this is the candidates map?

[commit-bot: I haz the power, 2013-05-03 01:46:03]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dominicc@chromium.org/14846002/2001

[commit-bot: I haz the power, 2013-05-03 02:27:53]

Change committed as 149628

[dominicc (has gone to gerrit), 2013-05-03 03:32:07]

On 2013/05/02 16:36:28, Dimitri Glazkov wrote:
> LGTM.
> 
>
https://codereview.chromium.org/14846002/diff/2001/Source/core/dom/CustomElem...
> File Source/core/dom/CustomElementRegistry.h (right):
> 
>
https://codereview.chromium.org/14846002/diff/2001/Source/core/dom/CustomElem...
> Source/core/dom/CustomElementRegistry.h:116: ElementSet m_unresolvedElements;
> So this is the candidates map?

This is where it will go. Right now we have a set of unresolved elements. That
will be replaced with two things:

1. A map keyed on unresolved element to a struct characterizing what resolution
it is waiting for: name * type extension|custom tag.

2. The reverse map, keyed on name * type extension|custom tag (or possibly just
name) to sets of elements.

Why is #2 alone insufficient? Because having #1:

- Lets us test :unresolved in O(1)

- When an element is being deleted, lets us remove it from #2 without
dereferencing any data on the element. (Not strictly necessary but seems more
robust.)

- Gives us a place to record the initial value of the "is" attribute, to get the
semantics right--the part where subsequent changes to "is" are ignored. (#2
*sounds* like it is sufficient for this, but only for upgrade--not for removing
the element from #2 when it is being deleted!)