- 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