W3C home > Mailing lists > Public > www-style@w3.org > July 2014

Re: [css-color-4] Renaming gray()

From: Brad Kemper <brad.kemper@gmail.com>
Date: Sun, 27 Jul 2014 11:22:32 -0700
Cc: Jan Tosovsky <j.tosovsky@email.cz>, www-style list <www-style@w3.org>
Message-Id: <0ADD9906-7042-44AB-8452-2C000C6E6C22@gmail.com>
To: François REMY <francois.remy.dev@outlook.com>

> On Jul 27, 2014, at 9:18 AM, François REMY <francois.remy.dev@outlook.com> wrote:
> >> On 2014-07-23 Lea Verou wrote:
> >> 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.
> >
> > I prefer black() to gray(), so it is a percentage of how black it is. This
> > jives with my experience in the print industry, where, while working
> > with one-color spot printing, specifying a shade of the color (most
> > often of black), we did not gave under color removal or grayscale
> > replacement to deal with. It was just a line screen representing a
> > percentage of how dark (how solid, really, since you could print in
> > some other spot color like yellow once you put it on the press) it
> > should be. You had to deal with dot gain that depended on what
> > kind of paper you printed on, but I don't think that's relevant here.
> >
> > My point is that black() should not be treated the same as the K in
> > CMYK after a non-naive conversion from RGB. Black(100%) should
> > be treated the same as rgb(0,0,0).
> If I can add my two cents to this discussion, I would avoid "black(x%)" 
> because there's no reason why "black(0%)" should be white, actually. When 
> you're in print, it is the default color of the paper, which may or may not 
> be white. The analogy is even worse for our OLED devices where the default 
> state is to be black, and white is only an action of the simultaneous 
> lighting of a red, a green and a blue light. In this case, "black(0%)" 
> doesn't mean anything.

It does mean something in the same sense that rgb(0,0,0) means black and cmyk(0,0,0,0) means white, and neither of them means "default screen/paper color", nor do any of them mean transparent. 

'Grayscale()' would be another possibility, as 100% black is a measurement within the grayscale. But I don't think black(100%) is really any less clear, and it is shorter. 

> I'm not a huge fan of "white(x%)" but at least, if you consider a light, it 
> is obvious that if you set your light to 0% you'll get a totally dark 
> environment, and therefore a black. That, and we're pretty often recalled 
> that "our clothes are grayish, but if we had used <insert-some-product-here> 
> we would have got a pure white" so the concept of less-white-than-white 
> should be widely preceived as intuitive. However, I recognize that this is 
> just yet another subjective point of view.
> As a result, I think we should probably answer two questions here:
> 1) do we really need this shorthand ?

It seems useful to me, and easier than the current alternatives. 

> 2) if we do, how can we make this shorthand objective and obvious?
> If there is a concensus that the answer to (1) is yes, then I believe I 
> would cast my vote for Lea's proposal to make this "rgb(0%) -> rgb(100%)" 
> because it's totally objective, easy to spec, and everyone can understand 
> this if you understand CSS Colors to begin with. Also, if you have to change 
> it at a later point to a color that isn't quite gray (because the designer 
> thinks it would be better) then you don't have to change the function name.
> Thoughts?
> François 

What the value of 100% represents depends on the name. I'd prefer the name to measure the amount of black, rather than the amount of white, because that is how I think of blacks and grays on the gray scale. So I'd vote for 'black()', which seems very clear. 

Here are a couple definitions, btw, of terms I mentioned in my last email:



Received on Sunday, 27 July 2014 18:23:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:45 UTC