[css-color-4] Better name for gray()?

[LeaVerou]

5 years ago, I opened this mailing list issue:

The gray() functional notation [1] is a great idea for specifying desaturated colors with varying degrees of transparency in a concise and readable way. However, I’m not sure about the naming. Right now, the named color gray corresponds to gray(50%). gray(0%) is black and gray(100%) is white.

After using this function myself for a while (through emulating it in Sass), I’m starting to think its naming is quite unintuitive. The usual assumption with functions that take a 0-100% parameter is that 100% gives the full “effect” of the function name, in this case, gray. Ask any random person what color they think gray(100%) represents, I doubt they’d guess white. [...]
For example, think of CSS filter functions: sepia(100%) colorizes the image as sepia, values < 100% are a lighter version of the effect. Same with invert(), grayscale() etc.

If we want to keep the link to hsl(), white() might be a better name. Although, I’m not sure if white(0%) == black is exactly intuitive, but it seems more intuitive than gray(0%).
Or, we might reverse the parameter and have black(100%) == black and black(0%) == white, which is on par with how many real life things work, such as (grayscale) printing.
Or maybe someone else has a better idea?

There was consensus that the name needs to change, but not to what. So I started a survey, which also confirmed that the name gray() as a bad idea.

The last post in the thread is by @tabatkins saying that "the results are impressive, let's let it run for another week and take what people decide".

Well, it ran for 5 years, and these are the results:

It looks like rgb(<number>) is overwhelmingly leading, but that is likely just a result of authors today being more familiar with the rgb() function. There is a famous quote (somewhat dubiously) attributed to Henry Ford: “If I had asked people what they wanted, they would have said faster horses.” The fact that RGB is not user friendly is well established in the literature, so I don't think it should be the only solution for easy specification of grayscale colors (though it may be nice to have it as an additional shortcut).
Apart from that, there doesn't seem to be any clear consensus on the name, besides that gray() is not the best option.
Renaming the function also eliminates the gray/grey confusion elaborated in #3298.

Since we're already working in Color 5, it would be nice to finally have a resolution on this, if it's going to be renamed.

To recap, here are some ideas for names that have been mentioned:

• black() with black(0%) = white and black(100%) = black`
• white() with white(0%) = black and white(100%) = white`
• grayscale()
• lightness()
• darkness()
• shade()

I personally feel much more strongly that gray() is a poor name choice than I feel that any of the above should be the one of choice. I think they're all better than gray(). Slight preference for white() as the absence of light producing black makes more sense than the absence of darkness producing white. We should also make sure that 50% is the gray that is perceptually between white and black, and not just hsl(0,0%,50%).
Whichever name you propose, please write it out with 0%, 50%, 100% and make sure it still makes sense and reads naturally for the color it produces.

[faceless2]

You could always add rgb(n) and rgb(n/a), which seems harmless enough, but please don't drop gray() without giving a syntax that doesn't presume RGB.

We've had a colorspace called "gray" in PDF/PostScript since forever, with 0=black. It's defined as the black in CMYK - so gray(1) == cmyk(0 0 0 1). I presume that's the origin of this name in CSS, but I completely agree that without this context the name is ambiguous. So while I can certainly live with gray(), if it's going to change then I'd go for black(), as it's mapped to black ink in print.

[Crissov]

What about any of these:

• Lab(0%) black through Lab(100%) white
• lch(0%) black through lch(100%) white
• light(0%) black through light(100%) white
• lightness(0%) black through lightness(100%) white
• gray(0%) white through gray(200%) black
• gray(-100%) white through gray(100%) black

[tabatkins]

I dislike most of these names, as they're misleading/weird:

• white()/black() are odd, as only color geeks consider white/black to be variations of each other. (and black(100%) being white is right out)
• shade()/tint() have specific meanings and we should reserve them for actually shading/tinting colors as color-manipulation functions
• lightness() is a maybe, but it's long. Not a killer objection, but still.

---

I'm not sure what you mean by:

Apart from that, there doesn't seem to be any clear consensus on the name, besides that gray() is not the best option.

since the data shows gray() as having the second highest individual % among all the options (only behind 1-arg rgb()).

If we did change the name, I'm okay with a 1-arg variant of an existing colorspace function, but not rgb() specifically, since gray() is not defined in terms of rgb(); it would be confusing and bad if rgb(50%) was not equal to rgb(50% 50% 50%). 1-arg lab() and/or lch() might work tho.

Another possibility, inspired by the existing (oddly named, but we're stuck with them) colorspace functions, is just l().

A final possibility is we just drop gray() entirely, since gray(X) is exactly equal to lab(X 0 0), which is an insignificant difference in typing. Downside of this is that you lose the potentially-useful immediately-obvious semantics of "this is a gray color". But we've lived without that for 20+ years, so we can probably continue to. ^_^

[svgeesus]

If we did change the name, I'm okay with a 1-arg variant of an existing colorspace function, but not rgb() specifically, since gray() is not defined in terms of rgb(); it would be confusing and bad if rgb(50%) was not equal to rgb(50% 50% 50%). 1-arg lab() and/or lch() might work tho.

Exactly.

Also, the fact that 1-arg rgb() was so popular means people responding did not read, or understand, what gray() does (although what it does now and what it did at several times in the past (rgb(x,x,x), hsl(0,0,x), etc) is not the same.

I'm tempted to leave it for now, and see what happens when lab() and lch() get implemented.

[Crissov]

Why not have both, single-argument rgb() and lab()/lch() for two different gray functions?

[tabatkins]

More impl and testing work for essentially zero benefit.

[smfr]

I don't like single-argument rgb() because gray() should be tied to the lab() and lch() colors by virtue of using the same colorspace, and the same lightness scaling (which is different from hsl etc). And at some point gray() may be able to represent super-bright HDR whites by having a lightness value > 100%.

lightness() is OK but sounds like an adjective. How about monochrome()?

[bradkemper]

Of all the suggestions so far, black([percentage]) seems most reasonable and intuitive to me. I don’t consider myself a color geek, but I am a web designer and developer, a former print designer, and someone who paints occasionally.

In printing with black ink, a 10% screen halftone is a very light gray, and a 90% screen halftone is a very dark gray. I also don’t think it is unusual to think of gray paints as being a percentage of black (with the rest of the mixture being white). See Exercise 2 on this page, for example:

http://kaplanpicturemaker.com/color/color_exercises

[Crissov]

I need to amend my earlier comment. Single-argument rgb() might be valuable, but would work differently from single-argument lab(): while the former would be a shorthand for setting all three components to the same value, e. g. rgb(50%) = rgb(50% 50% 50%), the latter would only set the first component and use a default value for the other two, e. g. lab(50%) = lab(50% 0 0).

It now seems most logical to me to use L(50%) or lightness(50%) instead of lab(50%) or lch(50%), while rgb(50%) is fine, though a different color – and perhaps rgb(127) (or even #7F and #7).

[css-meeting-bot]

The CSS Working Group just discussed Better name for gray()?, and agreed to the following:

• RESOLVED: drop gray() function

The full IRC log of that discussion

<dael> Topic: Better name for gray()?
<dael> github: https://github.com//issues/4621
<dael> leaverou: gray100% is white and gray 0% is black. Everyone agreed different name
<dael> leaverou: It's been a long time. I asked on twitter and my blog back then. I linked to the results
<dael> leaverou: Seems most people don't find it intuitive.
<dael> leaverou: People voted for simple argument rgb and gray isn't defined in rgb terms
<dael> leaverou: Not sure how much we should take it into account.
<dael> leaverou: I still stand by gray isn't a good name. White or black might be better. white 100% could make sense
<dael> leaverou: It's being impl so change is now or never
<bkardell_> should we try to do a post and evangelize with a good explanation along with the poll, just to check?
<dael> AmeliaBR: Agree it's surprising at 100 but gray(70%) to talk about a gray is something I've seen in design forums. If we are switcing I would argue l or lightness instead of white or black because then we have same confusion that 0% white is black
<dael> leaverou: L is good. lightness sounds like a filter, but not strong
<dael> AmeliaBR: I have same, lightness is close to brightness. L would be happy for me
<dael> bkardell_: Won't people ask what L means?
<dael> smfr: Can't google L
<tantek> what does the L in HSL stand for then?
<dael> florian: Not sure it's needed, but argument against gray is that in photographic field people speak as 80% as a middle gray and they mean 50% in lab. That's the stanard gray in photography
<dael> chris: They're talking about luminence
<AmeliaBR> s/80%/18%/
<dael> florian: Right so if gray 18% means something else it's not nice
<dael> fantasai: White and black are not much better than gray
<chris> monochrome?
<dael> Rossen_: If we did white or black are we signing up for both?
<dael> myles: 0 means none of it. For black(0) would mean same as black(100) and so that's why I'm for white
<dael> chris: What about monochrome? Makes hughless
<dael> leaverou: So long
<dael> florian: Any color is monochrome
<smfr> s/hughless/hueless/
<chris> lab(foo% 0 0)
<dael> TabAtkins: leaverou hit nail on head. Most suggestions will be longer than lab % 0 0 which is what gray does. gray isn't much of a savings. I prefer stick with gray or drop function
<dael> AmeliaBR: Any syntactic problem with making 2nd and 3rd value of lab options?
<dael> TabAtkins: I don't think there's precident for that
<dael> florian: I like it
<tantek> this sounds like a bunch of new bikeshedding and multiple options being considered that should first be added to the list in the GitHub issue comment thread rather than a phone call
<dael> chris: I think will be confusing
<dael> leaverou: Why privleage one coordinate?
<dael> AmeliaBR: Then I would argue drop gray. As florian pointed out gray(50%) isn't want people think of as 50% in design due to color space the shorthand isn't helpful
<dael> chris: Fine with that
<dael> myles: lab seems worse for people that don't know colors. What does lab mean?
<dael> leaverou: rgb is no more intuitive it's just been used for years
<dael> AmeliaBR: But people are familiar with it I'd be happy to have a one function rgb. But let's not have gray function that doens't do what people expect
<dael> Rossen_: Are we saying gray won't work as intended and will be unintuitive?
<dael> Rossen_: If we discount that half the people vots for rgbx which worked at the time everyone else voted gray
<dael> florian: We're defining it to work on l of lab and people mean 50% gray in srgb space. gray 15% in srgb is what people would see with 50% in lab
<chris> 50% shades of gray
<bkardell_> what about just mono?
<dael> fantasai: If using % in lab people will think of it as the gray function no matter the name. Calling it lightness or gray or whatever will not change the effect if they're thinking in srgb. Why not call it gray?
<dael> florian: Call it gray in do it in srgb
<dael> fantasai: gray makes it obvious the midpoint. That's useful. People that work with gray understand white and black and near and far ends. Whatever we call it people will be disappointed because not in the color space they want
<dael> myles: Maybe take an optional param
<dael> fantasai: Or we do single value lab and rgb functions. THis is syntax sugar. Want to make most common thing work
<dael> chris: A gray thing with an optional param to say warmer or cooler
<AmeliaBR> I'd argue for both `rgb(18%)` expanding to `rgb(18% 18% 18%)` and for `lab(50%)` expanding to `lab(50% 0 0)`. Don't use `gray()` because it's not clear which one it would be.
<dael> Rossen_: Since people are starting to impl let's get to a resolution or live with gray. Strong canadate names over gray?
<dael> bkardell_: monochrome was too long, would mono work?
<dael> TabAtkins: Don't generally go for shortening words as makes it hard to understand
<dael> chris: 3 options. Drop function. Keep as gray. Rename it now. smfr is impl so can't mess around with name
<dael> florian: Which gray is it?
<dael> chris: L as currently spec
<dael> Rossen_: Can we live with dropping?
<dael> Rossen_: I will take silence as a yes
<dael> bkardell_: It's less important than lab.
<dael> chris: You're not losing anything
<dael> Rossen_: Objections to drop gray() function
<dael> RESOLVED: drop gray() function
<bkardell_> we can always bring it back up
<dael> Rossen_: We can go back to these argumenents if we re-introduce
<dael> fantasai: Should we take up single value lab or rgb as equating to gray?
<chris> noooooo
<dael> TabAtkins: I don't think it's worthwile enough to take up.

[svgeesus]

Closed in accordance with CSS WG resolution 8 Jan 2020

8f2149e

[Crissov]

K(), key() for them print folks.

Also could have chosen for gray() to depend on the working color space. #4647 #300 😝

[tabatkins]

k/key was mentioned in the minutes; it's similarly wrong/misleading, as k(50%) is not a 50% K value...

[Crissov]

As far as I see, only black() was mentioned, which is not quite the same as key() in a rarely but in this case important way.

[tabatkins]

Ah, it was a side comment, looks like it didn't get minuted; Chris was referring to Brad Kemper's comment about black(), suggesting that it was in fact an intuition about K, which would be slightly off for a Lab-based function just like an rgb intuition would be.