Don't resolve extended color keywords during parsing

Don't resolve extended color keywords during parsing

Previously we were keeping the "basic" named colors (color keywords)
unresolved (as identifiers), while resolving the "extended" named
colors.
This CL makes us keep the "extended" colors as well, and resolve them
during style resolving instead (of during parsing.)
Because we now no longer expect to resolve named colors in the
fast-path, we can drop that part of CSSParserFastPaths::parseColor.

The new behavior matches Gecko and IE.

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

[fs, 2015-07-16 17:06:02]

fs@opera.com changed reviewers:
+ pdr@chromium.org, timloh@chromium.org

[fs, 2015-07-16 17:06:03]

PTAL

pdr for platform/ and web/

https://codereview.chromium.org/1232593004/diff/60001/Source/core/dom/TextLin...
File Source/core/dom/TextLinkColors.cpp (right):

https://codereview.chromium.org/1232593004/diff/60001/Source/core/dom/TextLin...
Source/core/dom/TextLinkColors.cpp:63: if (const NamedColor* namedColor =
findColor(valueName, strlen(valueName)))
This is likely a bit slower than the previous code. If it matters though it
should be fairly easy to optimize using some sort of table (Vector) to map
id->Color.

[pdr., 2015-07-20 03:03:08]

LGTM for web and platform

@timloh, does this LGTY in terms of perf?

[Timothy Loh, 2015-07-20 08:39:50]

lgtm, but yeah the style application here is a bit dodgy. We should probably fix
it up at some point to not stringify/reparse :/

[pdr., 2015-07-21 04:46:34]

The CQ bit was checked by pdr@chromium.org

[commit-bot: I haz the power, 2015-07-21 04:46:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1232593004/60001

[commit-bot: I haz the power, 2015-07-21 07:55:42]

Committed patchset #4 (id:60001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=199209