[css-color-5] Relative color syntax, @color-profile named channels, and the 'e' constant

[tabatkins]

Relative color syntax 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, 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, 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.

[svgeesus]

I guess ε and π are out of the question as are const(e) and const(pi)?

I agree that e and pi would rarely be used in color calculation, given that we provide the polar color spaces already.

I think an explanation like:

Note: in the case of clashes between the declared component names and CSS numeric constants, the latter will take precedence

So yeah

[tabatkins]

ε isn't even the right name - that's epsilon! The constant's name is indeed "e", the latin letter. (But also, ε is a valid component name too, so it wouldn't help.)

A function would be possible, it would just make using the constants quite a chore.

I think an explanation like: [snip]

That wouldn't be a Note, it needs to be actual spec text. But it sounds like you're arguing for, uh, I guess Option 1.1: all numeric constants are fine; components with the same name are allowed, but are implicitly not usable in RCS math functions because they're shadowed by the constants. (But presumably would work on their own, not wrapped in a math function.)

[karip]

Require <dashed-ident> for the component names, just like the @color-profile name requires it?

Example: @color-profile --mathy { components: --e --pi --infinity --nan;} and color(from cornflowerblue, --mathy, calc(--e + .1))

[LeaVerou]

I suspect we will add new numeric constants very rarely, if ever, and when we do, they'll generally be multi-letter

Please note that there is no restriction to color components being single letter. alpha is already multi-letter, and the components descriptor can be used to name components with any ident.

I think it's more author-friendly to ban the constants from being valid component names, though it does introduce potential backwards compat issues, as you point out.

A third idea would be to have special syntax for the constants instead of just bare idents which are likely to produce more conflicts in the future. E.g. const(pi) or const-pi.

[svgeesus]

Circling back to this, because the user can call the components whatever they want, I think it is fine to simply say that if they choose to call a component e or pi or any other constant we add in the future then okay, but inside calc() those are going to be shadowed by the named constants so don't choose those names or you may get a surprise.

[LeaVerou]

I'm fine with that. Should we disallow none at least though?

[tabatkins]

Sounds good to me, that keyword is specific to color syntaxes (rather than being reserved as part of calc() syntax).

And yeah, I'm fine with that conclusion.