- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Sun, 27 Jul 2014 11:22:32 -0700
- To: François REMY <francois.remy.dev@outlook.com>
- Cc: Jan Tosovsky <j.tosovsky@email.cz>, www-style list <www-style@w3.org>
- Message-Id: <0ADD9906-7042-44AB-8452-2C000C6E6C22@gmail.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: http://en.m.wikipedia.org/wiki/Under_color_removal http://en.m.wikipedia.org/wiki/Grey_component_replacement
Received on Sunday, 27 July 2014 18:23:01 UTC