Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(168)

Issue 14846002: Implement the Custom Elements :unresolved pseudoclass (Closed)

Created:
7 years, 7 months ago by dominicc (has gone to gerrit)
Modified:
7 years, 7 months ago
Reviewers:
dglazkov
CC:
blink-reviews, apavlov+blink_chromium.org, darktears
Visibility:
Public.

Description

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

Patch Set 1 #

Patch Set 2 : Adds a test and fixes style sharing. #

Total comments: 1
Unified diffs Side-by-side diffs Delta from patch set Stats (+126 lines, -6 lines) Patch
A LayoutTests/fast/dom/custom/unresolved-pseudoclass.html View 1 1 chunk +48 lines, -0 lines 0 comments Download
A LayoutTests/fast/dom/custom/unresolved-pseudoclass-expected.txt View 1 1 chunk +15 lines, -0 lines 0 comments Download
M Source/core/css/CSSSelector.h View 1 chunk +2 lines, -1 line 0 comments Download
M Source/core/css/CSSSelector.cpp View 6 chunks +7 lines, -1 line 0 comments Download
M Source/core/css/SelectorChecker.cpp View 1 2 chunks +6 lines, -0 lines 0 comments Download
M Source/core/css/StyleResolver.cpp View 1 1 chunk +3 lines, -0 lines 0 comments Download
M Source/core/dom/CustomElementRegistry.h View 4 chunks +5 lines, -0 lines 1 comment Download
M Source/core/dom/CustomElementRegistry.cpp View 4 chunks +29 lines, -4 lines 0 comments Download
M Source/core/dom/Element.h View 1 1 chunk +2 lines, -0 lines 0 comments Download
M Source/core/dom/Element.cpp View 1 2 chunks +9 lines, -0 lines 0 comments Download

Messages

Total messages: 5 (0 generated)
dominicc (has gone to gerrit)
This relies on <https://codereview.chromium.org/14834002/> going first. Because element upgrade currently happens at creation time or ...
7 years, 7 months ago (2013-05-02 07:11:00 UTC) #1
dglazkov
LGTM. https://codereview.chromium.org/14846002/diff/2001/Source/core/dom/CustomElementRegistry.h File Source/core/dom/CustomElementRegistry.h (right): https://codereview.chromium.org/14846002/diff/2001/Source/core/dom/CustomElementRegistry.h#newcode116 Source/core/dom/CustomElementRegistry.h:116: ElementSet m_unresolvedElements; So this is the candidates map?
7 years, 7 months ago (2013-05-02 16:36:28 UTC) #2
commit-bot: I haz the power
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/dominicc@chromium.org/14846002/2001
7 years, 7 months ago (2013-05-03 01:46:03 UTC) #3
commit-bot: I haz the power
Change committed as 149628
7 years, 7 months ago (2013-05-03 02:27:53 UTC) #4
dominicc (has gone to gerrit)
7 years, 7 months ago (2013-05-03 03:32:07 UTC) #5
Message was sent while issue was closed.
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!)

Powered by Google App Engine
This is Rietveld 408576698