- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Sat, 16 Jan 2021 14:32:51 +0000
- To: public-css-archive@w3.org
Ok, good catch! We already have [4.7.3. Serializing Lab and LCH values](https://drafts.csswg.org/css-color-4/#serializing-lab-lch) but that spec text is specific to `lab()` and `lch()`. And we have [4.7.4. Serializing values of the color() function](https://drafts.csswg.org/css-color-4/#serializing-color-function-values) which applies to all of the `color()` function. In general, the color serialization tries to preserve a color as specified. Now, it it was just `color(lab l a b)` I could argue it either way, but we also have (partly from prompting by @smfr and partly from other feedback that we need to expose CIE XYZ) the form `color(xyz x y z) and this is _only_ available on `color()`. So I would suggest that `color(lab l a b)` serializes as itself, rather than being converted to `lab(l a b)` form. Same argument for `color(srgb r g b)` - if someone goes to the trouble of using that new form, then that is what they should get back on serialization. Remember that there are multiple differences between this and the legacy `rgb(%, %, %)` and `rgb(n, n, n)` forms - removal of commas, use of `/` as alpha separator, addition of real rather than integer values in the non-percent form (but still 0..255 rather than 0..1) for backwards compat. So if an author wants to express sRGB in a 0..1 rather than 0% .. 100% or 0 .. 255 form, `color(srgb n n n)` is the only way to do that and they should get back what they specified. Apologies for not noticing this issue, first week back after a long seasonal break. -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5825#issuecomment-761573065 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 16 January 2021 14:32:53 UTC