[csswg-drafts] [css-color] Declared value serializations of absolute and relative colors (#10305)

weinig has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-color] Declared value serializations of absolute and relative colors ==
Historically (and [per-spec](https://drafts.csswg.org/css-color-4/#serializing-sRGB-values) for RGB colors - "For all other sRGB values, the declared, computed and used value is the corresponding sRGB value.") color values have serialized the same way for declared and computed values (with the exception of "CSS [named color](https://drafts.csswg.org/css-color-4/#named-color), a [system color](https://drafts.csswg.org/css-color-4/#css-system-colors), a [deprecated-color](https://drafts.csswg.org/css-color-4/#deprecated-system-colors), or [transparent](https://drafts.csswg.org/css-color-4/#valdef-color-transparent)."

One unfortunate side effect of this is that `calc()` values get lost, in a way that is distinct from pretty much all other declared values (or at least in my limited testing). For instance, `color: hsl(calc(30 + 60) 50% 50%)` serializes as `rgb(128, 191, 64)`, where as `width: calc(20px)` serializes as `calc(20px)`. While there may be a compatibility reason to continue doing this for the RGB/HSL/HWB set, what is the argument to continue that on for `lab()`/`lch()`/`oklab()`/`oklch()`/`color()`?

Relative colors kick the trend, and are spec'd to serialize their declared form as declared (presumably retaining `calc()`, though that is not explicitly stated).

What is the rationale for using the computed value serialization for all absolute color serializations?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10305 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 10 May 2024 18:29:02 UTC