CSS Parser: Implement parseRule

CSS Parser: Implement parseRule

This patch adds parseRule and consumeQualifiedRule to the css-syntax
parser. For now this code is only called into via the CSSOM.

As usual, this is all happening behind a disabled runtime flag. There
are some more test breakages due to unimplemented features (e.g. using
insertRule with at-rules).

http://dev.w3.org/csswg/css-syntax/#parse-rule
http://dev.w3.org/csswg/css-syntax/#consume-a-qualified-rule

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

[Timothy Loh, 2014-12-15 23:56:13]

timloh@chromium.org changed reviewers:
+ alancutter@chromium.org

[Timothy Loh, 2014-12-16 00:01:20]

https://codereview.chromium.org/799003003/diff/50001/Source/core/css/parser/C...
File Source/core/css/parser/CSSParserImpl.cpp (right):

https://codereview.chromium.org/799003003/diff/50001/Source/core/css/parser/C...
Source/core/css/parser/CSSParserImpl.cpp:135: m_parsedProperties.clear();
This doesn't make a difference right now, but when we can parse rule lists we'll
need this. I might eventually make this not a member.

https://codereview.chromium.org/799003003/diff/50001/Source/core/css/parser/C...
File Source/core/css/parser/CSSParserImpl.h (right):

https://codereview.chromium.org/799003003/diff/50001/Source/core/css/parser/C...
Source/core/css/parser/CSSParserImpl.h:35: PassRefPtrWillBeRawPtr<StyleRuleBase>
consumeAtRule(CSSParserTokenRange&);
Eventually these two will take an enum along the lines of

enum AllowedRules {
 RegularRuleCharsetAllowed, // charset, import, namespace allowed
 RegularRuleImportAllowed, // import, namespace allowed
 RegularRuleNamespaceAllowed,
 RegularRule,
 KeyframesRule,
}

The top-level flag only needs to be considered by the not-yet-implemented
consumeRuleList, and @page rules are actually declaration lists instead of rule
lists.

https://codereview.chromium.org/799003003/diff/50001/Source/core/css/parser/C...
File Source/core/css/parser/CSSParserTokenRange.h (right):

https://codereview.chromium.org/799003003/diff/50001/Source/core/css/parser/C...
Source/core/css/parser/CSSParserTokenRange.h:62: CSSParserTokenRange
consumeBlock();
This is almost the same as consumeComponentValue, except that it's awkward to
find a block's content range using consumeComponentValue (after advancing past a
component value, if the next token is an EOF token we can't tell if the block
ended early)

[alancutter (OOO until 2018), 2014-12-29 05:10:22]

lgtm with nits.

https://codereview.chromium.org/799003003/diff/110001/Source/core/css/parser/...
File Source/core/css/parser/CSSParserImpl.cpp (right):

https://codereview.chromium.org/799003003/diff/110001/Source/core/css/parser/...
Source/core/css/parser/CSSParserImpl.cpp:98: return nullptr; // Parser error,
empty rule
s/Parser error/Parse error/g

https://codereview.chromium.org/799003003/diff/110001/Source/core/css/parser/...
File Source/core/css/parser/CSSParserTokenRange.cpp (right):

https://codereview.chromium.org/799003003/diff/110001/Source/core/css/parser/...
Source/core/css/parser/CSSParserTokenRange.cpp:40: } while (nestingLevel &&
m_first < m_last);
Would it be worse to have consumeComponentValue() return trailingNestingLevel?

[Timothy Loh, 2015-01-05 05:56:18]

https://codereview.chromium.org/799003003/diff/110001/Source/core/css/parser/...
File Source/core/css/parser/CSSParserImpl.cpp (right):

https://codereview.chromium.org/799003003/diff/110001/Source/core/css/parser/...
Source/core/css/parser/CSSParserImpl.cpp:98: return nullptr; // Parser error,
empty rule
On 2014/12/29 05:10:21, alancutter wrote:
> s/Parser error/Parse error/g

Done. There's a bunch of other places I wrote "Parser error" previously which
I'll fix up in a separate patch.

https://codereview.chromium.org/799003003/diff/110001/Source/core/css/parser/...
File Source/core/css/parser/CSSParserTokenRange.cpp (right):

https://codereview.chromium.org/799003003/diff/110001/Source/core/css/parser/...
Source/core/css/parser/CSSParserTokenRange.cpp:40: } while (nestingLevel &&
m_first < m_last);
On 2014/12/29 05:10:22, alancutter wrote:
> Would it be worse to have consumeComponentValue() return trailingNestingLevel?

I don't think it's any worse, but we're going to rewrite these before shipping
anyway and these will be super short then so I'm not too concerned about how
this looks right now.

[Timothy Loh, 2015-01-05 05:56:23]

The CQ bit was checked by timloh@chromium.org

[commit-bot: I haz the power, 2015-01-05 05:56:39]

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

[commit-bot: I haz the power, 2015-01-05 07:06:23]

Committed patchset #8 (id:130001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=187849