[css-color-5] Is color-adjust() needed, now that we have relative color syntax?

[tabatkins]

Originally, color-adjust() was the only way to modify a starting color in carefully specified ways. However, we've since added the relative color syntax, doing something very similar.

In fact, as far as I can tell, relative color syntax completely subsumes color-adjust(). At least in the current grammar, color-adjust() can only adjust a single channel (tho there's a good chance we'll change that; see Lea's comment), and it can only do so as a % adjustment. Relative color syntax, on the other hand, can adjust all the channels at once, and can do arbitrarily complicated mathematical adjustments to them, including but definitely not limited to % adjustment.

It also just seems a little easier to read, in my opinion: compare color-adjust(lch, red h 20%) vs lch(from red l c calc(h * .2)).

I think at this point, addressing the issues with color-adjust() (allowing multiple channels, allowing more complex mathematical adjustment) would just be bringing it into alignment with relative color-syntax, not giving any additional features.

[LeaVerou]

Indeed, originally (check out the June 2019 F2F minutes) they were meant as alternatives of which we'd only keep one, but the editors have been so far unsuccessful in converging to one of the two.

Note that your two examples are not equivalent: the adjusters in color-adjust() are relative, so 20% I believe increases lightness by 20%, just like -20% reduces it. Though that lack of clarity may be another argument against it…

Note that both of these are mid-level (color-adjust() being slightly more high level than RCS), and we do eventually need a lower level syntax that will enable use cases like combining channels from different colors etc. Based on the research on Sass usage that I've done for the Almanac (see #5782), it seems that what authors are using in preprocessors are functions to get individual color components (e.g. lightness($color)), which seems a good path forwards, though we'd need to prefix them by color space (except alpha()).

[tabatkins]

Note that your two examples are not equivalent: the adjusters in color-adjust() are relative, so 20% I believe increases lightness by 20%, just like -20% reduces it. Though that lack of clarity may be another argument against it…

Yeah I noticed that afterward. I think that behavior might be fine in a vacuum, but in conjunction with relative color syntax, it's def confusing.

[discussion about extracting channels]

Yup, that's definitely a separate thing to talk about (and I agree, a good idea).

[svgeesus]

Originally, color-adjust() was the only way to modify a starting color in carefully specified ways. However, we've since added the relative color syntax, doing something very similar.

Note that these were both added at the same time, per CSSWG resolution. The spec also explicitly notes that we intend to merge, modify, or drop so that we end up with one final way, rather than two ways.

[svgeesus]

I think at this point, addressing the issues with color-adjust() (allowing multiple channels, allowing more complex mathematical adjustment) would just be bringing it into alignment with relative color-syntax, not giving any additional features.

I agree. The main missing function in RCS is a relative version of color(). Although, since we simplified color() by dropping the fallback list, that task looks simpler.

[LeaVerou]

I think at this point, addressing the issues with color-adjust() (allowing multiple channels, allowing more complex mathematical adjustment) would just be bringing it into alignment with relative color-syntax, not giving any additional features.

I agree. The main missing function in RCS is a relative version of color(). Although, since we simplified color() by dropping the fallback list, that task looks simpler.

Note that in another issue I proposed @color-profile should have a descriptor to specify component names. This would allow us to have RCS for custom color spaces (and we can just predefine for the predefined spaces).

[svgeesus]

@LeaVerou wrote:

Note that in another issue I proposed @color-profile should have a descriptor to specify component names.

This descriptor has been added

This would allow us to have RCS for custom color spaces (and we can just predefine for the predefined spaces).

Relative color syntax for the color() function has also now been added, which references the components descriptor in the case of dashed-ident as color space.

@tabatkins wrote:

Relative color syntax, on the other hand, can adjust all the channels at once, and can do arbitrarily complicated mathematical adjustments to them, including but definitely not limited to % adjustment.

Yes. It is (with the latest additions) strictly more powerful, arguably easier to read too.

I think the draft should be published with the current state of both color-adjust() and RCS; but we are now close to being able to decide the ultimate single way forward.

[svgeesus]

Color 5 was published 1 June with both color-adjust() and the full RCS; since that publication the ED has gained a section on Serialization for RCS, color-contrast() and color-mix() (see #6206 ).

Before I put effort into serialization of color-adjust(), or work on related issues #6180 #6181 #6141 let's have some more discussion and, ideally, resolution of this present issue.

[css-meeting-bot]

The CSS Working Group just discussed Is color-adjust() needed, now that we have relative color syntax?, and agreed to the following:

• RESOLVED: Drop color-adjust(), stick with relative color syntax for color manipulation for now

The full IRC log of that discussion

<Rossen_> topic: Is color-adjust() needed, now that we have relative color syntax?
<Rossen_> github: https://github.com//issues/6179
<TabAtkins> chris: a few years ago we resolved to add two conflicting proposals for how to adjust colors
<leaverou_> q+
<TabAtkins> chrishtr: We've continued to publish with both, and refine them
<TabAtkins> chris: At this point the relative color syntax seems like it's easier and strictly more powerful
<TabAtkins> chris: it would be simpler if we could just decide to go with that one
<Rossen_> q?
<bkardell_> ScribeNick: bkardell_
<Rossen_> ack TabAtkins
<TabAtkins> s/chrishtr/chris/
<TabAtkins> leaverou_: I see color-adjust() as beign slighitly higher level than RCS
<TabAtkins> leaverou_: But for that, you don't actually get much more clarity
<TabAtkins> leaverou_: like color-adjust(..., lightness(20%)) - does that mean set it to 20%? Increase it to 20%?
<TabAtkins> leaverou_: But RCS is very clear, the math is laid out
<TabAtkins> leaverou_: So I support the RCS
<bkardell_> ScibeNick: TabAtkins
<TabAtkins> leaverou_: That said, we've done research on how color is used in Sass since they ahve manipulation for years
<TabAtkins> leaverou_: The Sass equivalent of color-adjust is barely used at all
<TabAtkins> leaverou_: Instead they usually extract color components and do math on that, or use even higher-level fucntions like lighten() and darken()
<TabAtkins> leaverou_: So I think we should prioritize a method that does math on the components (RCS) and also pursue higher-level easy manipulations like lighten()
<TabAtkins> leaverou_: We might also want to in the future allow channel-extraction functions that would let you combine things from multiple colors; that's not possible at all right now.
<argyle> q+
<TabAtkins> leaverou_: I thought we might have wanted to just go with that, but since WK implemented RCS and people seem to like it, i'm fine with just going with that
<Rossen_> ack leaverou_
<Rossen_> ack argyle
<TabAtkins> argyle: I'm very pro the RCS
<TabAtkins> argyle: I recall some initial concerns about it confusing, but I'm happy to hear those are resolved.
<TabAtkins> argyle: Agree there's no way to extract individual channels yet - good to work on in the future.
<chris> I was also concerned that RCS was too complex, but I no longer feel that.
<TabAtkins> argyle: So I support Lea's push here, to move forward with RCS and pursue channel manipulation later.
<TabAtkins> argyle: And also doing higher-level simple manipulations like lighten()
<chris> +1 to high-level color-lighten and color-darken
<TabAtkins> argyle: So yeah, think removing color-adjust() will simplify and let us perhaps do a better version in the future
<TabAtkins> +1 as well
<bkardell_> +1
<miriam> +1
<TabAtkins> Rossen_: Any other opinions? SEe a bunch of +1s on the channel
<leaverou_> basically what I was trying to say is that between RCS and color-adjust() I'd support RCS, you get a lot more flexibility for only slightly more complexity. But we do need higher level functions and potentially something even more lower level that will allow combining components of multiple different colors (we even have internal CSS WG use cases for those)
<TabAtkins> Rossen_: Any objections?
<smfr> i want to see groove and ridge borders specified in terms of RCS
<TabAtkins> chris: So resolution would be to drop color-adjust(), keep relative color syntax.
<TabAtkins> smfr, I'm pretty sure it's doable without much difficulty, but would have to play with it.
<argyle> thanks for not scribing Ollie and his tattling on his bro lol
<TabAtkins> RESOLVED: Drop color-adjust(), stick with relative color syntax for color manipulation for now
<leaverou_> smfr: if it's not doable with RCS, it certainly isn't doable with color-adjust(). RCS's power is a strict superset.
<TabAtkins> Rossen_: Do you need to republish Color 5, Chris? This would be a pretty big change.
<TabAtkins> chris: Yes, once we've done this we should repub
<TabAtkins> Rossen_: So let's resolve to repub once changes made