Re: [w3c/manifest] Color processing steps are incorrect (#760)

Assuming the input is Unicode (with bytes you’d first [decode](https://drafts.csswg.org/css-syntax/#input-byte-stream) to Unicode), parsing should go something like:

* [Preprocessing the input stream](https://drafts.csswg.org/css-syntax/#input-preprocessing),
* Then [Tokenization](https://drafts.csswg.org/css-syntax/#consume-token),
* Then [Parse according to the grammar](https://drafts.csswg.org/css-syntax/#parse-grammar) of [`<color>`](https://drafts.csswg.org/css-color/#typedef-color), or some subset of it:
  - I think `currentColor` only makes sense in CSS properties?
  - If you need RGBA eventually, you might want to not parse `device-cmyk(…)`
* Then convert the matched components according to the corresponding section (for example [Converting HSL colors to sRGB colors](https://drafts.csswg.org/css-color/#hsl-to-rgb)) to the form needed, such as four numbers in the 0 to 1 range for R, G, B, and A channels.

Perhaps css-syntax should have better “glue” algorithms for putting these three steps together. https://drafts.csswg.org/css-syntax/#parse-grammar says it can take a string as input, but when following steps we then get to “[from the list of tokens produced by the tokenizer](https://drafts.csswg.org/css-syntax/#current-input-token)” without further links or info about how to make a tokenizer.

CC @tabatkins

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/760#issuecomment-484412840