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

[weinig]

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:

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.

[weinig]

A more complete test case would look like this:

<div>Here is a test: </div>
<div id=test>TEST</div>
<pre id=log></pre>
<script>
    let element = document.getElementById("test");
    element.style["background-color"] = "rgb(calc(90 + (90 * sign(1vw + 2em))), 0, 0)";
    element.style["width"] = "calc(100px + (100px * sign(100vw - 2em)))";
    
    let log = document.getElementById("log");
    
    let specifiedStyle = element.style;
    log.appendChild(document.createTextNode("background-color (specified): " + specifiedStyle["background-color"] + "\n"));
    log.appendChild(document.createTextNode("width (specified): " + specifiedStyle["width"] + "\n\n"));

    let computedStyle = window.getComputedStyle(element);
    log.appendChild(document.createTextNode("background-color (computed): " + computedStyle["background-color"] + "\n"));
    log.appendChild(document.createTextNode("width (computed): " + computedStyle["width"] + "\n\n"));
</script>

[nt1m]

Makes sense to serialize as given (minus any possible simplifications we usually do for calc()), for the specified value at least.

[cdoublev]

Following what was resolved for mixed color functions (relative and color-mix()) would be consistent:

• rgba() → rgb()
• hsla() → hsl()
• whitespace separated arguments

Fwiw, as I already commented in the linked issue, I think that not omitting unitary <alpha-value> here would also be againt the shortest serialization principle, and I think resolving <hue> and <percentage> to <number> might also be more consistent.

[cdoublev]

Also, from an implementation point of a view, it seems easier to serialize resolved math function values without calc() even when there are other channel values specified with unresolved math functions.

For example, rgb(calc(1), calc(1px / 1em), 0) would serialize with rgb(1 calc(1px / 1em) 0).

And there are also new numeric substitution functions that cannot be resolved at parse time, like rgb(sibling-index() 0 0) or rgb(media-progress(width from 0px to 500px) 0 0), which I think are similar cases like relative length containing math functions, ie. they are unresolved numeric substitution functions.