[css-color-5] RCS channel keywords interaction with calc() is underspecified

[weinig]

The behavior of the RCS channel keywords and calc() is underspecified in a few ways.

1. It is unclear when the keyword should resolve to their numeric values.

CSS Values 4 requires specifications, like CSS Color 5, that define additional keywords for calc, to include the following:

Each specifications defining such keywords must define for each keyword:

• its value
• its type (<number>, <length>, etc)
• when it resolves (parse time, computed-value time, or used-value time)

(https://drafts.csswg.org/css-values-4/#calc-variables)

CSS Color 5 does do the first two.

The answer here will depend on if the origin is currentcolor, as in that case, the specified value serialization could not be the numeric value, but in the general case, it's still unclear. Should the specified value serialization of color(from blue srgb calc(r) calc(g) calc(b)) be color(from blue srgb calc(r) calc(g) calc(b)) or color(from blue srgb 0 0 1)?

2. It is unclear what to do about missing components in the origin color.

For example, take: color(from color(srgb none none none) srgb r calc(g) calc(b * 2)).

How should this be interpreted?

Should the none be carried forward for the bare identifier but not calc?: color(srgb none 0 0)
Should the none be carried forward for the bare identifier and calc? If so, what is none * 2 evaluate to?

An additional edge case to consider and clarify is for when the alpha value of the origin color is used as the default: color(from color(srgb none none none / none) srgb 0 0 0)

Should that resolve to color(srgb 0 0 0 / none)?

[romainmenke]

see #10211

[css-meeting-bot]

The CSS Working Group just discussed [css-color-5] RCS channel keywords interaction with calc() is underspecified.

The full IRC log of that discussion

<fantasai> ChrisL: About preserving numeric values of keywords
<fantasai> ChrisL: is it parse-time, computed-time, or used-time resolution?
<fantasai> ChrisL: Color 5 doesn't specify
<fantasai> ChrisL: if you do calc(none * 2) what do you get?
<fantasai> ChrisL: does it evaluate to none or nan or what?
<fantasai> ChrisL: no discussion
<fantasai> fserb: is it different from what we just discussed?
<fantasai> ChrisL: seems related
<fantasai> ChrisL: but about whether you preserve calc() explicitly as calc()
<emilio> https://github.com//issues/10211 is part of it, whether `none` should be infectious like `nan` or not
<fantasai> dbaron: I think we have general principle for calc() that we resolve at multiple value stages
<fantasai> dbaron: if you can resolve at earlier stages, you do; if not then preserve to later stages
<fantasai> dbaron: I think that's what happens for <length> calc(), e.g. calc(1in + 5pt) gets resolved immediately
<fantasai> dbaron: but calc(1in + 1em) needs font-size, so resolve it later
<fantasai> dbaron: maybe that applies to some degree here?
<emilio> q+
<lea> q+
<fantasai> emilio: also issue of what does multiplying by none even mean?
<fantasai> emilio: Another issue linked which discussed it a bit
<fantasai> emilio: what I proposed was to make none infectious like nan
<fantasai> emilio: but lea wasn't happy about that
<fantasai> emilio: so designing what to do with none changes when you can resolve some of these calcuations
<fserb> q+
<emilio> s/designing/deciding
<fantasai> lea: Reason is, when you have none
<dbaron> (Yeah, I have no idea what it means to do math on none....but I'm also not following this spec that closely.)
<fantasai> lea: can have e.g. clamp(0.5, none, 0.6)
<fantasai> lea: that means give me value from other color, and clamp it
<fantasai> lea: if it's infectious, that could mean lightness is unrestricted which could make text unreadable
<fantasai> lea: not sure what 'none * 2' means.
<fantasai> lea: if you interpolate with another color, then none becomes value of the other component and then is multiplied
<fantasai> lea: so color-mix() in oklch
<lea> color-mix(in oklch, oklch(calc(none * 2) .1 180), oklch(.5 .1 180)) =
<fantasai> lea: that would produce...
<lea> oklch(1 .1 180)
<fantasai> lea: it's like a late ariable
<fantasai> s/aria/varia/
<fantasai> miriam: for a specific use case, none + 180 in a hue is a common use case
<fantasai> dbaron: just to throw out an example that's awful
<fantasai> dbaron: if you have calc() on none in both colors in a color-mix, need to say what happens
<fantasai> dbaron: presumably none in the result?
<fantasai> lea: I think this was well-defined
<fantasai> lea: if both none-containing expressions, then you use calc-mix() to interpolate until you can resolve the nones
<fantasai> dbaron: but only meaningful if then mixed with something else?
<fantasai> lea: yes, either mix with something not none, or become zero
<fantasai> dbaron: ok
<fantasai> fserb: I think everything inside calc() is context-dependent
<fantasai> fserb: calc(none + 180) going to do something on the other side
<fantasai> fserb: calc has to be resolved before you do relative color syntax
<fantasai> fserb: You cannot leave the relative color syntax without resolving the number
<fantasai> fserb: the number resolves ...
<fantasai> fserb: the number that calc() returns, it depends on that context
<fantasai> fserb: if you converting from anything with a hue, calc(180) you can't keep calc and [missed]
<fantasai> lea: this is confusing
<fantasai> fserb: if you keep calc() means you won't look inside until later on
<fantasai> fserb: to move forward on relative color syntax, it needs to become a number
<dbaron> maybe I'm not ok with that answer... still confused about what color-mix(in oklch, oklch(.5 .1 calc(none + 180)), calc(.3 .1 calc(none + 180)) means...
<fantasai> fserb: it's only meaningful as a number, not as an unresolved calc()
<fantasai> lea: what is the proposal?
<fantasai> fserb: calc() cannot be carried out of relative color syntax