W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2020

Re: [csswg-drafts] [css-color-5] Findings on SCSS function usage to inform direction of Color 5 (#5782)

From: Lea Verou via GitHub <sysbot+gh@w3.org>
Date: Thu, 17 Dec 2020 00:39:30 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-747127912-1608165569-sysbot+gh@w3.org>
> > Do we agree to ditch both color-adjust() and the relative function syntax, and instead add functions for component extraction?
> 
> I still like color-adjust because it enables more room to grow in the future.

If you feel strongly about keeping it, we can keep both that and the relative syntax and have all three, but ultimately, we'll need to settle on one for FPWD.
But if you want to keep it primarily because it may be useful in the future, note that we can always add it in the future. 

> I've felt that we should implement these with existing popular web color spaces today if the input colors are within those color spaces. I.e. if the input is RGB or HSL, we should still be able to make adjustments. This would make implementation in a timely manner much more likely, and also can still work with planning for future color spaces (the optional attribute to set which color space the mixing occurs in, or if any of the input arguments are in that color space).
> 
> Allowing for transformations in HSL or RGB color spaces would mean that developers could use these today (something they are clearly asking for, as evidenced above), and browsers could implement them without the additional performance hit (and pre-requisite) of supporting a more advanced color format.

On the contrary, if color manipulation motivates browsers to implement colors beyond sRGB, that's a Good Thing™, because **it's about damn time**. Most authors are fine to use sRGB for manipulation because that's all they've known from preprocessors, because *there was no alternative*. It's our job to give them good defaults that work well and manipulations in gamma-corrected sRGB are suboptimal. It's not good for the Web in the long run to favor speedy implementation for a subpar feature that we'll be stuck with for decades.

> Also, would we be able to adjust multiple components at a time?

Of course. The functions are independent. E.g. 

```css
lch(lightness(var(--primary) lch) calc(chroma(var(--primary) lch) * 1.1) calc(hue(var(--primary) lch) + 10))
```
to manipulate both chroma and hue.
Or, with shorter names like `lch-h()`:
```css
lch(lch-l(var(--primary)) calc(lch-c(var(--primary)) * 1.1) calc(lch-h(var(--primary)) + 10))
```

Yes, it's very verbose, but also it can do anything (including combine channels from multiple different colors).
For the common manipulations like darkening, lightening, alpha, and mixing, we'd have shortcuts. Based on the SCSS data, it appears that other types of manipulations are *significantly* more rare, so I'm fine with them needing the verbose-but-does-everything syntax.
If in the future other common manipulations emerge, we can add more shortcuts.

> > How many functions do we add for component extraction? It looks like the no brainers are alpha(), hue(), lightness(), chroma(), saturation(). Perhaps also whiteness() and blackness()?
> 
> Same question above -- I want to avoid creating new custom properties for each transformation if we wanted to adjust both saturation and lightness of a single theme variable. (This would be a common example of translating a theme color for dark themes)

I'm not sure why you'd think you need to define new custom properties? Is it for readability? Given your earlier question about whether manipulating multiple channels is possible, I think you may have misunderstood and thought I was proposing these functions as the way to manipulate individual components, e.g. `hue(var(--mycolor) +20%)` or something. That would indeed be very limiting, and is absolutely not what I was suggesting.

> > Do we also add red(), green(), blue()? They are used in SCSS (about 1% of pages each). If we do add them, can they extract components from RGB color spaces defined via color(), e.g. display-p3?
> 
> Regardless of usage, they would enable a more complete system, so I do think we should add them. RGB channels are often tweaked in SVG filters to create unique effects.

I believe in SVG filters, the color manipulation also happens in the SVG filter, e.g. via `feColorMatrix`. Are there any use cases in CSS?

> > Do we need functions for Lab? If so, what to name them? I'd rather avoid single letter functions, but lab-a() is inconsistent with say hue().
> 
> If we go down this route, yes.

We tend to add things if there are use cases, not for completeness. If there are no or very niche use cases for these, we could start without them and add them once/if use cases emerge.

> > What to do with color() components?
> 
> I think we'll still need `color()` for serialization, but I don't think it conflicts with this.

I'm not sure I follow, how does serialization relate?


-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5782#issuecomment-747127912 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 17 December 2020 00:39:33 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:24 UTC