[css-color-4] Specified value for color when calc() is used

[weinig]

With the addition of more specificity for the specified value of colors that just went in (thanks @svgeesus!), one thing that I would like to be explicitly specified is whether calc() should be preserved through specified value serialization.

For example, take:

    let test = document.createElement("div")
    test.style.color = "rgb(calc(100), 255, 255)"

    console.log(test.style.color)

In Safari and Firefox (I have not tested anything else), this logs rgb(100, 255, 255), seemingly resolving the calc(). (See https://bug-250325-attachments.webkit.org/attachment.cgi?id=464424 for a live test case). This is inconsistent with other properties (like say, width), and the way calc() is specified (see #8290 (comment)).

My proposal would be to have colors match other properties and perverse the minimal calc(). So, for the example above, I would expect the right serialization to be rgb(calc(100), 255, 255).

I can see some argument that legacy colors have had this behavior long enough and the required conversions from hsl() to rgb() would make the rules inconsistent in some places, so, as an alternative to always requiring preservation, I think requiring it for all non-legacy colors would be a good option as well.

[svgeesus]

The basic answer is "simplify as much as you can at each stage (specified, computed, used) and then serialize what you've got", with the caveat that if the tree simplifies down to a plain numeric value it's serialized with a calc() around it if it's a specified value (to maintain clamping behavior).

That seems fairly clear (and implies that Safari and Firefox are wrong here and should change). I can add some examples of serializing specified and computed values using calc to CSS Color 4 and 5, but the normative reference would be CSS Values.

The part about maintaining clamping behavior is less clear. If I have

rgb(127 255 0 / calc(75% + 75%))

does the specified value serialize as rgb(127 255 0 / calc(100%)) or rgb(127 255 0 / calc(150%))? I would have assumed early clamping of the over-range alpha value.

[svgeesus]

In Safari and Firefox (I have not tested anything else)

Chrome does the same (test)

[Loirooriol]

https://drafts.csswg.org/css-values/#calc-range

Clamping is performed on computed values to the extent possible, and also on used values if computation was unable to sufficiently simplify the expression to allow range-checking. (Clamping is not performed on specified values.)

[svgeesus]

Right but see:

• [css-color] Clamping component values at computed-value time vs parsing time #7677

[svgeesus]

OK I will add an example showing a calc() with an unclamped single value. But any normative clarification belongs in CSS Values 4.

[tabatkins]

Untagging from Values 4, since everything should be well-defined there.

If we end up needing to do something special for calcs in legacy color functions, we will need a Values edit, so tag it back in that case.

[cdoublev]

the required conversions from hsl() to rgb() would make the rules inconsistent in some places

Do you (all) mean that math functions should not be preserved when converting HSL to RGB? An alternative would be to serialize the HSL color when it contains math functions.

[svgeesus]

Leaving this open because of the open question regarding serializing a specified hsl() value that contains a calc().

[cdoublev]

Minor precision: the question is also about serializing a specified hwb() (which is not legacy) that contains a calc(), ie. it is about all sRGB functions because they must be converted to rgb().