This was prompted by this Chrome bug report: https://issues.chromium.org/issues/41483822

The author was trying to do things like:

background-color: hsl(from blue calc(h + 30deg) calc(s + 25%) calc(l + 5%));

background-color: lch(from blue calc(l + 5) calc(c + .1) calc(h + 20deg)); 

background-color: oklch(from blue calc(l + 0.5) calc(c + 0.1) calc(h + 20deg)); 

and found they were not working in Chrome (whereas their <number> counterparts don't work in Safari, that implements an older version.

As I wrote in the issue…

This is actually a Safari bug, Chrome is correct here.

For background, we had to decide what type these keywords would return, since even though components accept multiple types, they had to return a specific type when used like this, they couldn't return e.g. an angle sometimes and a number other times. For simplicity, the rule we converged on was "return a number if the component accepts one". And then we made all colors accept numbers to make it even simpler: just return numbers, always 😀

However, it does present a clear ergonomics issue. Also, going from numbers to percentages in certain color formats is not just a matter of removing the unit, or even dividing by 100, but can be a lot more complex (e.g. in device independent colors, percentages provide a reference range that roughly corresponds to a cylinder encompassing the P3 gamut).

I think we used to have a <number-percentage> type at some point and we removed it (@tabatkins do you remember why?). I wonder if we could reinstate it? This seems like the perfect use case. We'd also need a <number-angle> for hues, but that is needed far less.