26208 2014-06-26 20:45:17 +0000 For parsing CSS <color> values, this should explicitly ref the CSS Syntax spec, and use the "parse a component value" algorithm defined there. 2014-09-22 16:26:32 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#dependencies P3 normal Unsorted 1 contributor ian ian jackalmage mike contributor oldest_to_newest 108393 0 contributor 2014-06-26 20:45:17 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html Multipage: http://www.whatwg.org/C#dependencies Complete: http://www.whatwg.org/c#dependencies Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html Comment: For parsing CSS <color> values, this should explicitly ref the CSS Syntax spec, and use the "parse a component value" algorithm defined there. Posted from: 2620:0:1000:1b01:a2b3:ccff:fefb:42ac User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.32 Safari/537.36 108395 1 jackalmage 2014-06-26 20:46:35 +0000 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. 108531 2 ian 2014-06-30 23:44:29 +0000 Why does this have to be two steps instead of one? I'm not sure I follow. I'll look into it more closely. 108540 3 jackalmage 2014-07-01 02:08:52 +0000 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. 110945 4 ian 2014-09-03 22:49:02 +0000 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. 110971 5 jackalmage 2014-09-04 02:26:00 +0000 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. 111025 6 ian 2014-09-04 18:38:15 +0000 Cool. I'll update HTML to use that wording and link to the relevant part of CSS Syntax. Thanks! 111108 7 jackalmage 2014-09-05 21:57:11 +0000 Here you go: http://dev.w3.org/csswg/css-syntax/#parse-grammar 111829 8 ian 2014-09-19 19:21:20 +0000 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! 111830 9 contributor 2014-09-19 19:21:32 +0000 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 111850 10 jackalmage 2014-09-19 21:28:50 +0000 (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.