[css-color-5] Clarification on how `channel keywords` with multiple specified types work

[weinig]

In the relative color syntax section of CSS Color 5, some of the channel keywords specify more than one type. For instance, the channel color l for the lab() relative color syntax states:

• l is a <percentage> or <number> that corresponds to the origin color’s CIE Lightness

(http://w3c.github.io/csswg-drafts/css-color-5/##valdef-lab-l)

I am unclear on what this means with respect to using l in a calc() expression. For instance, in the following contrived case:

lab(from purple calc(l + 2) a b / 100%)

should I be interpreting l as a <percentage> or a <number>? (or am I missing something fundamental about calc that makes this not an issue?)

Edit: linked to stable drafts, and corrected to CSS Color 5, not 4

[svgeesus]

I think this is a case of the editors not appreciating the impact of other changes. At the time it was introduced to CSS, CIE L was a <number> in [0..100]. Then it became a mandatory <percentage> for a long time, and relatively recently became <percentage> | <number>. You are right that this means RCS no longer defines what you actually calculate with for calc() inside RCS.

Following the advice that @LeaVerou gives in her CSS Variables talks:

converting a number to a value with units is easy, calc(var(--foo) * 100%)
converting a value with units to a number requires things like calc(var(--foo) / 1%) which don't exist yet
so make your custom properties be pure data with no units

Then I suggest resolving this such that <percentage> gets resolved to <number> because that will be the most convenient thing to manipulate in calc()

So

--base: oklab(50% 0.2 -12%);
--darker: oklab(from var(--base) calc(l * 0.8) a b);

Using the percent reference ranges for oklab the value of --base becomes oklab(0.5 0.2 -0.048) and the value of --darker becomes oklab(0.4 0.2 -0.048)'

Converting the <percentage> values to <number> is also consistent with how those values are serialized

[LeaVerou]

I think this is a case of the editors not appreciating the impact of other changes. At the time it was introduced to CSS, CIE L was a <number> in [0..100]. Then it became a mandatory <percentage> for a long time, and relatively recently became <percentage> | <number>. You are right that this means RCS no longer defines what you actually calculate with for calc() inside RCS.

Yeah, this appears to have been some sort of mass change.

Following the advice that @LeaVerou gives in her CSS Variables talks:

converting a number to a value with units is easy, calc(var(--foo) * 100%)
converting a value with units to a number requires things like calc(var(--foo) / 1%) which don't exist yet
so make your custom properties be pure data with no units

Then I suggest resolving this such that <percentage> gets resolved to <number> because that will be the most convenient thing to manipulate in calc()

As a general principle, we should not be designing the language long-term based on short-term UA limitations.
However, I don't see anything wrong with erring on <number> whenever possible, to limit the number of conversions needed. That could be a general principle for RCS.

[svgeesus]

Another point is that forcing users to convert from percentage form themselves requires them to memorize or look up the percentage reference ranges for each component. 100% maps to 100 for CIE L, 1.0 for Oklab L, 125 for CIE a, 0.4 for Oklab a. Having the implementation do this will reduce errors.

[LeaVerou]

Another point is that forcing users to convert from percentage form themselves requires them to memorize or look up the percentage reference ranges for each component. 100% maps to 100 for CIE L, 1.0 for Oklab L, 125 for CIE a, 0.4 for Oklab a. Having the implementation do this will reduce errors.

Correct, though it may make operations easier, e.g. calc(l + 20%) becomes more meaningful across color spaces.

[svgeesus]

calc(l * 1.2) seems easy enough

[LeaVerou]

Yes, but they do different things. Both are useful.

[LeaVerou]

Perhaps we can make it <number-percentage> so that math with percentages still works? @tabatkins is that a thing? Can it be?

[svgeesus]

There is no more <number-percentage>, it was removed.

[tabatkins]

Yeah, number-percentage doesn't exist (and can't - it breaks the typing system). We do need to decide on one or the other.

I'm fine with making it number.

[svgeesus]

So:

• @tabatkins is fine with <number>,
• @LeaVerou wanted <number-percentage> which isn't possible, but earlier said <number> was fine, and
• I argued for <number> because if the implementation resolves percentages, that is less error prone than the user doing it.

No-one has argued for <percentage> only, and it is agreed that the channel keywords need to resolve to a single type.

In the interest of having concrete text to discuss on the call today, I am going to do the edits to make all channel keywords resolve to <number>.