See, for example, https://github.com/whatwg/meta-brand-color#finding-the-brand-color:

> For each element in candidate elements:
>   1. Parse a component value from element's content attribute value. [[css-syntax]]
>   2. Attempt to parse the result as a CSS color. If it succeeds, return the parsed color.

Why does this have to be two steps instead of one? I'm not sure I follow. I'll look into it more closely.

You could combine them, but it's still essentially two steps - one to turn codepoints into some structure of CSS tokens, then another to run a grammar against those tokens.

This matters, for example, due to whitespace - if you just check if an attribute's value parses as a CSS color, it'll fail due to whitespace if there's any at the beginning/end.  If you first get a component value, that discards whitespace at the beginning/end.  Right now you explicitly discard the whitespace, but that's not necessary if you ref Syntax properly.

Well I just mean that in most other cases, the tokenisation and parsing stages are wrapped into a single call site. For example, if you want to parse HTML, you just run the HTML parser, you don't have to manage the handoff of tokens from the tokeniser to the tree builder.

Presumably, the output of "parse a component value", and thus the input of "parse the result as a CSS color", is not a string, but a sequence of tokens or some such. In which case, "parse the element's content attribute value as a CSS color" should be meaningless (a type mismatch error).

So what I would suggest, is that we define "parse [a string] as [some CSS value]" as doing the tokenisation and any other processing that it needs, so that I can then say "parse [a string] as a CSS <color> value" and it does the right thing. Seems like that would make other specs integrating with CSS less verbose and more maintainable in the face of changes on the CSS side. The fact that there's a separate tokenisation step seems like an implementation detail of the CSS syntax specifications.

Anyway, if you disagree, just let me know, happy to do it however you want.

Yeah, I'm fine with adding a hook like "parse as [[css grammar thing]]", which, like the other parsing functions, accepts either a list of codepoints, a list of tokens, or a list of component values.  It would do a "parse a list of component values" first, then attempt to match it against the specified grammar.

Cool. I'll update HTML to use that wording and link to the relevant part of CSS Syntax. Thanks!

Here you go: http://dev.w3.org/csswg/css-syntax/#parse-grammar

Please take a look at the HTML prose and see if it's ok. In particular, note the problem with the 'font' property, not sure how to handle that, and check the example that starts "For example, user agents are required to close all open constructs..." and make sure that that matches reality on your end. Thanks!

Checked in as WHATWG revision r8793.
Check-in comment: Better reference CSS for parsing according to CSS.
https://html5.org/tools/web-apps-tracker?from=8792&to=8793

(In reply to contributor from comment #9)
> Checked in as WHATWG revision r8793.
> Check-in comment: Better reference CSS for parsing according to CSS.
> https://html5.org/tools/web-apps-tracker?from=8792&to=8793

Per IRC discussion, the <'font'> nonterminal is what you want. It means "the grammar of the 'font' property", and excludes the global keywords.