[css-color-5] Make all color components in Relative Color Syntax optional

[LeaVerou]

Currently, when authors want to convert between color spaces, they need to do things like lch(from var(--color) l c h) or color-mix(in lch, var(--color) 100%, black 0%), both of which are awkward.

So, @svgeesus and I were discussing allowing for a no-arguments RCS that would allow things like lch(from var(--color)). But if we're going to have a syntax with 0 args and a syntax with N args, why not allow everything in between? This would allow authors to omit trailing components that are unchanged, allowing them to shorten things like lch(from var(--color) calc(l * 1.2) c h) to lch(from var(--color) calc(l * 1.2)).

[tabatkins]

Remind me what the reason is for an author to explicitly convert color spaces? Is it just to get a good default interpolation without having to specify an interpolation strategy (or in places where we're not adding the ability to specify one)?

If so, then the 0-arg version makes sense to me. It reads well and the meaning is obvious; it clearly communicates "I'm making no change to this color besides the colorspace inherent in the wrapping function".

The non-zero-but-not-full version makes less sense to me. You'd only be able to omit from the end, so the usefulness is entirely dependent on the ordering of a particular function; for example, HSL and LCH are exactly backwards in their arg ordering, so you could achieve some effects in one that you couldn't with the other, for no particular reason other than accidents of naming history.

The lack of one or two components is also much less visually obvious than the complete lack of components. We do allow alpha to be omitted from the syntax, whereupon it means "take from the origin color", but the presence or absence of alpha is decently signaled by the / character.

All in all, adding this just to save 2-4 characters (depending on whether you're omitting 1 or 2 components) doesn't seem like it pays for itself, imo.

[tabatkins]

As an example of the "usefulness depends on argument ordering", look at the grayscaling example in the spec - one variant is specified as lch(from var(--color) l 0 h), which one could shorten to lch(from var(--color) l 0), dropping the h, but the also-superfluous l has to remain just because it precedes the chroma argument that is actually changing. Whether a component is dropped or not thus carries no semantic meaning (or at least has its meaning tangled up in irrelevant details), unlike dropping all the components.

Also, people read non-linearly, and use visual cues both ahead and behind their current attention point to aid in scanning. In this syntax, the first thing after the from <color> is always the first component, and the last thing before the ) is always either the alpha (if / is used) or the last component. If one sees 0) at the end of an lch, one can immediately infer that it's a red. This is broken if one can omit the hue, as in this example where the 0) instead signals that it's a grayscale color, and the hue is omitted.

All these are minor issues that can easily get swept under the rug if the functionality is worthwhile, but here the only benefit is being able to skip the two characters [space]h sometimes.

[css-meeting-bot]

The CSS Working Group just discussed CSS Color 5: Relative Color Syntax optional components, and agreed to the following:

• RESOLVED: Close no change

The full IRC log of that discussion

<fantasai> Topic: CSS Color 5: Relative Color Syntax optional components
<fantasai> github: https://github.com//issues/6938
<fantasai> lea: Right now have a relative color syntax that allows you to do arbitrary math over components of a single color
<fantasai> lea: also converts the color you're working with to the color space you're using
<fantasai> lea: could just want to convert to the color space
<fantasai> lea: e.g. from-color l c h
<fantasai> lea: can also convert using color-mix() and 100% of the color you want
<fantasai> lea: Chris and I were thinking this is awkward
<chris> q+
<fantasai> lea: maybe just allow drop the components to convert spaces
<fantasai> lea: and if 3 or zero components, then maybe could even have some components
<fantasai> lea: but Tab seems a bit against that
<fantasai> lea: QUestion of why convert among spaces if not doing anything with it
<fantasai> lea: ...
<fantasai> lea: right now adding to all features that use interpolation
<fantasai> lea: if no reason, then not worht having a shortcut
<fantasai> lea: Chris, any reason to convert color spaces but not do anything with the resulting color?
<fantasai> chris: if we do make thse optional, then I would want to make all components optional
<fantasai> chris: or maybe trailing ones, is sort of annoying
<fantasai> chris: that's confusing. I'd prefer all or none
<fantasai> chris: but don't see point for using positional ordering
<fantasai> lea: what's use case for none of them?
<dino> ack dino
<fantasai> chris: the use case was color space so I can mess around with it, but now we have color-extract()
<fantasai> lea: even with relative color syntax could do color conversion and do math on the componetns
<fantasai> lea: so I'm not sure why you would need to do that, so inclined to close this as no change
<fantasai> chris: I think that would be fine
<fantasai> Rossen_: can we do that?
<fantasai> lea: yes, that's my proposal. Unless Chris can think of a use case for it
<fantasai> Rossen_: we can always re-open if a strong use case comes forward
<fantasai> RESOLVED: Close no change