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

Re: [css-color] Remove gray() Notation

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 18 Aug 2014 07:57:56 -0700
Message-ID: <CAAWBYDDCn-xEqazhOSj-mof+OSSAEHJZ7CM82Y1xR3Hi3dup_w@mail.gmail.com>
To: Patrick Dark <www-style.at.w3.org@patrick.dark.name>
Cc: www-style list <www-style@w3.org>
On Sat, Aug 16, 2014 at 8:58 PM, Patrick Dark
<www-style.at.w3.org@patrick.dark.name> wrote:
> I would suggest scrapping the gray() notation and replacing it with the
> following:
> • hsl(<lightness>) where hue = 0deg and saturation = 0%
> • hsla(<lightness>, <alpha>) where hue = 0deg and saturation = 0%
> These notations have the following authoring advantages over the gray()
> notation:
> • Hue and saturation can be added without replacing or removing parts of a
> preexisting value; only additions are required.
> • Hue and saturation can be removed by simply deleting preexisting values.

We just did a poll of authors, actually, and got the result that rgb()
with a single value (or rgba() with two values, for gray and alpha) is
strongly preferred by authors.

Since percentages are allowed, this is precisely the same syntax that
you proposed, just with a different function name.  You can also use
numbers 0-255 if you prefer, though.  (It also has a slight learning
advantage, I think. Removing from the front is slightly less intuitive
than removing from the back, and repeating the provided argument for
the missing ones is easy to understand as well.)

> Better yet, extend the aforementioned advantages by modifying the HSL
> notation to be less restrictive:
> • hsl(<hue>, <saturation>, <lightness>, <alpha>)
> • hsl(<lightness>) where hue = 0deg, saturation = 0%, and alpha = 100%
> • hsl(<lightness>, <alpha>) where hue = 0deg and saturation = 0%
>  This proposal is compatible with rgb()- and rgba()-based equivalents (which
> I wouldn't use because I consider RGB unintuitive for anything other than
> copying-and-pasting).

I had hsl() and rgb() with optional alpha in the draft earlier, but
the WG didn't feel it was a sufficiently worthwhile change.  I agree
that it's clumsy to have two different functions just to handle an
optional argument and have no idea why it was originally done that
way, but it has a long legacy and has low value to fix at this point.

Received on Monday, 18 August 2014 14:58:43 UTC

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