Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)

I think we're missing two important tenets here.

CSS should be easy for authors to write and understand.
CSS should be lightweight and efficient.

I'm sure it should also be easy to process, but not at the cost of these two factors.

> #ccc became redundant in a sense when 32-bit processors came out. I would suggest you read about the development of computer color and true color [4].

I don't see any reason that CSS authors should have to care about 32-bit processors. We write colours in hex now, and will continue to. All that is being discussed here is a way to make them easier to read, and shorter. I personally find the notation we are suggesting very easy.

I think once you have the understanding the hexadecimal colours should never support an alpha channel, this becomes a no-brainer. Perhaps if hexadecimal colours (in Colors 4) are to support an alpha channel, a different prefix to the pound symbol could make this clear?

I have no issue with rgb() or rgba() notation, and am not sure why anyone would have. It clearly fulfils the first of the tenets I stated, although not the second. gray() also seems a logical progression of these.

> #ccc was created as a shorthand for #cccccc where the reverse is true.

From my perspective, and the way I use #ccc – it is entirely as a shorthand. If this is just serendipitous luck, then so be it, but implementation trumps specification. I'm not sure why – as an author in 2011 – I should care about 16-bit colour processing.

On 6 Sep 2011, at 03:01, Alan Gresley wrote:

> On 6/09/2011 9:32 AM, Marat Tanalin wrote:
>> 06.09.2011, 03:03, "Tab Atkins Jr."<jackalmage@gmail.com>:
> 
>>> I don't understand how you think rgba() is wrong and how it can be
>>> replaced by 'background-opacity'.  Colors are used in far more than
>>> just 'background-color'.  Partially-transparent border or text
>>> colors are useful, and specifying them with an alpha color is
>>> simple (better than adding 'border-color-opacity' and
>>> 'color-opacity' properties, for certain).  Alpha colors are also
>>> very useful as color-stops in gradients, where there is absolutely
>>> no way to replace them with a property.
>> 
>> Just most often rgba is used for background in practice. You are
>> right that it might be used with border-color or color (though,
>> e.g., semi-transparent text color is used far rarely).
> 
> Don't forget that rgba can also be used for text-shadow and box-shadow [1]. Also, rgba can be build up in layers to produce more colors [2] [3] (example is with hsla).
> 
>>> After more thought on the matter of 1- or 2-digit hex shorthands,
>>> though, I've now come down against it.  I gave my reasoning against
>>> 2-digit grays previously in the thread (the expansion rule is
>>> different than for 3-digit color).
>> 
>> Even if expansion rule is different, it does not mean this is
>> something bad.
>> 
>>> As for 1-digit grays, I no longer think they're a good idea.  When
>>> Colors 4 gets written I'll be pushing for (or writing, if I end
>>> up the editor) 4- and 8-digit hex colors so you can specify alpha
>>> without having to switch to rgba() and convert your components to
>>> decimal.  I don't think it's good to add a new hex variant that
>>> can't similarly receive an alpha.  (Obviously, having #0 expand
>>> into #00000000 isn't useful.  Adding a second digit, like having
>>> #0c expand into #000000cc, is just confusing.)
>> 
>> rgba values (including its probable hex syntax) is a topic for
>> another thread (if someone needs it at all) and is quite alien thing
>> in this thread, in my opinion. Let's try to isolate regular
>> hex-values discussion here.
> 
> I don't see why you say this. rgba and 8-digit hex color are the same thing. rgb and 6-digit hex color are the same thing. The only difference between the two are their notation. I am in agreement with Tab here. #0c expanding into #000000cc is not a good thing and can lead to confusion.
> 
>>> The benefit of 1-digit grays is extremely minimal.  You get to hit
>>> a key once instead of three times.  It's the same key all three
>>> times, too, so the burden of hitting it thrice is basically nil.
>> 
>> It's not about key-hitting. #ccc just _redundant_ compared with #c.
> 
> #ccc became redundant in a sense when 32-bit processors came out. I would suggest you read about the development of computer color and true color [4].
> 
>> So, if we able to shorten #cccccc to #ccc, then shortening #ccc to
>> #c (as well as #acacac to #ac) seem just logical.
> 
> It's not about shortening. The reserved has happened. Please read about web-safe colors [5].
> 
>>> I am still okay with a gray() function, though, which takes a
>>> single number/percentage, and then optionally an alpha value.  I'm
>>> not sure if we *need* it, but I'm favorably disposed to it.
>> 
>> The topic is not about some new functions, it's about shortening
>> existing hex values.
> 
> I would recommend that you look into the concept or reasoning behind a gray() function. I see no reason to shorten hex values where their use was for a legacy 16-bit processor. You seem to be making a argument that #ccc was created as a shorthand for #cccccc where the reverse is true.
> 
> 
> 1. http://css-class.com/test/css/shadows/text-shadow2.htm
> 2. http://css-class.com/test/css/colors/color-transparent1.htm
> 3. http://css-class.com/test/images/hsla-color-merging.png
> 4. http://en.wikipedia.org/wiki/Color_depth#Truecolor
> 5. http://en.wikipedia.org/wiki/Web_colors#Web-safe_colors
> 
> 
> -- 
> Alan Gresley
> http://css-3d.org/
> http://css-class.com/
>

Received on Tuesday, 6 September 2011 09:19:17 UTC