[csswg-drafts] [css-color][css-values] Parsing/Serialization behavior for rgb/hsl/hwb colors with calc() containing font/container/viewport relative lengths (#10730)

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

== [css-color][css-values] Parsing/Serialization behavior for rgb/hsl/hwb colors with calc() containing font/container/viewport relative lengths ==
I recently learned that any `calc()` value can contain font/container/viewport relative lengths, as they can be used from with a sign() math function. One implication of this seems to be that eager evaluation of `calc()` at parse time for legacy colors can't always complete. For a concrete example, consider:

```css
background-color: rgb(calc(90 + (90 * sign(1vw + 2em))), 0, 0);
```

I don't believe that has a value until style resolution since we don't know if the expression `1vw + 2em` will be positive or negative.

My previous understanding of the rules for sRGB color types (rgb/hsl/hwb) is that they serialize without `calc()` at all levels (specified, computed, etc), but I am not sure what to do when the calc can't be fully resolved at specified value time.

The language in https://drafts.csswg.org/css-color-4/#resolving-sRGB-values I think actually allows serializing the calc() in these cases, since it uses the phrasing: "[...] when calc() in sRGB colors resolves to a single value [...]", but I wanted to make sure that was the intention.

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


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

Received on Monday, 12 August 2024 17:36:05 UTC