- From: Guillaume via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jun 2024 13:44:47 +0000
- To: public-css-archive@w3.org
> The serialization of a the declared value of a color used as the origin color inside of another color function (color-mix, RCS, color-contrast) is: [...] I suggest *The serialization of a color function nested inside another color function, as components of a declared value, is: [...]*. But is it actually needed to serialize this way in other color functions than relative colors? (and possibly `color-mix()`, #10414) That is, is it needed to preserved unclamped channel values and unresolved color functions in `contrast-color()` and `light-dark()`? --- [Parsing a `<color>` Value*](https://drafts.csswg.org/css-color-4/#parse-a-css-color-value) might need to be updated because it currently requires resolving `<color>` at parse time (ie. before serialization), which means `<percentage>` and `<angle>` are resolved to `<number>`, etc. --- > [...] followed by the canonical colorspace ("xyz-d65" for "xyz") [...] I am not sure it is necessary: CSS Colors 4 says `xyz` is an alias of `xyz-d65` and [CSS Cascade 5](https://drafts.csswg.org/css-cascade-5/#value-aliasing) says that *legacy* value aliases are converted *at parse time*... --- Why not apply the shortest serialization principle and omit unitary alpha? -- GitHub Notification of comment by cdoublev Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10328#issuecomment-2165721474 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 June 2024 13:44:48 UTC