[csswg-drafts] [css-color-5] Relative color syntax, @color-profile named channels, and the 'e' constant (#6416)

tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-color-5] Relative color syntax, @color-profile named channels, and the 'e' constant ==
[Relative color syntax](https://drafts.csswg.org/css-color-5/#relative-colors) lets you use channel keywords inside of math functions that are used inside of color functions, like `rgb(from cornflowerblue, calc(r + .1) g b)`, to do math on those channel values.

@color-profile has a ['components' descriptor](https://drafts.csswg.org/css-color-4/#descdef-color-profile-components), letting you give names to the channels of the color profile, specifically to make them usable in relative color syntax.

V&U defines a set of [numeric constants](https://drafts.csswg.org/css-values/#calc-constants), which are special keywords only usable in math functions, which provide certain useful numeric constants like `e` or `pi`.

Putting all these together gives us a problem! Theoretically, you could define `@color-profile mathy { components: e pi infinity nan;}`, but then what does `color(from cornflowerblue, mathy, calc(e + .1))` mean? Is that the value of the "e" (first) channel when `cornflowerblue` is converted to the "mathy" profile? Or is it ~2.718?

There's no great solution here, I fear, but I see two reasonable options:

1. Simply ban the numeric constants from being valid 'components' values. I suspect we will add new numeric constants very rarely, if ever, and when we do, they'll generally be multi-letter ("e" is the only common numeric constant that's a single Latin letter), so the potential for conflict is very low. I do see this causing annoyance if a colorspace happens to normally call one of its channels "e", however; the author would have to choose a different name, and might very reasonably be confused why it's not working.

2. In RCS we only allow the *absolutely necessary* numeric constants (`infinity`, `-infinity`, and `NaN`, all needed for serialization purposes), and ban the others. `e` and `pi` are only provided for convenience, after all. Then we'd only need to restrict those three keywords from 'components', which should have no practical effect at all. I don't *think* the lack of those constants will be a problem here; while pi is useful for converting between rectangular and cylindrical spaces, RCS does that conversion for you already, so it seems rare to actually need to refer to pi, and in the rare cases you do need to, you can still just write `3.14`. However, if you are used to using `e` or `pi` in math functions and want to use them here, again there's a very reasonable chance of confusion when they suddenly don't work. 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6416 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 30 June 2021 17:14:12 UTC