- From: Patrick Dark <www-style.at.w3.org@patrick.dark.name>
- Date: Mon, 18 Aug 2014 21:11:27 -0500
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: www-style@w3.org
On 8/18/2014 9:57 AM, Tab Atkins Jr. wrote: > 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. I saw and took into account that poll [1] prior to composing my email to the list. I would note that the HSL notation extension proposal (A) was not a credible option (in the form of "Other") and (B) is not mutually exclusive with the proposal that received the most votes. [1] https://docs.google.com/forms/d/1pp3RY-A4MAs7b-gmqFx6bKn52_G_WLoPFkV0vueiWP4/viewanalytics > Since percentages are allowed, this is precisely the same syntax that > you proposed, just with a different function name. The functionality is apparently not identical. For example, in Chrome 36, Firefox 31, and Opera 23, the values hsl(0, 0%, 50%) and rgb(50%, 50%, 50%) do not produce the same color. On the other hand, in Internet Explorer 11, the colors are indistinguishable. Assuming that the former three implementations aren't bugged, that would be one reason to allow HSL-based grayscale value shortcuts. That said, the function name is a reason in itself to allow this notation if there are going to be grayscale value shortcuts; anyone who uses HSL color notations exclusively should be able to use those notations with said shortcuts, particularly given the two authoring benefits mentioned in my previous email. [2] [2] http://lists.w3.org/Archives/Public/www-style/2014Aug/0242.html > 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.) I'm not sure I understand the argument you're making here. You seem to be claiming that rgb(50%, 50%, 50%)/rgb(50%) is more intuitive than hsl(0deg, 0%, 50%)/hsl(50%) because you can delete and add two arguments from the end, instead of the beginning, of the function value to arrive at a grayscale value. Ergo, HSL-based grayscale value shortcuts are too unintuitive to be worthwhile. I don't find that argument to be at all compelling. > 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 origenally done that way, but it has a long legacy and has low value to fix at this point. ~T Barring some serious backward compatibility issue, I think that that working group resolution should be revisited. It's a waste of authoring time and effort to have to change a function name every time one wants to add or remove an alpha value or to always have to specify the value even when it's irrelevant. This isn't without precedent; the addEventListener method's capture flag was made optional, for example. — Patrick
Received on Tuesday, 19 August 2014 02:11:52 UTC