Re: [css3-color] #rrggbbaa annotation

@Patrick Garies:

Reading back your comments, It is pretty clear to me that you just
don't like #HEX annotation or you think it is too complex (at it seems
that you understand it).

On Tue, Apr 6, 2010 at 4:16 PM, Patrick Garies <pgaries@fastmail.us> wrote:
> On 2010-04-04 9:55 PM, Eduard Pascual wrote:
>>
>> Can anyone bring forth any *objective* argument against
>> #rrggbbaa/#rgba? (and keep in mind that "it's ugly" is an aesthetic
>> perception, so it is not objective... actually, I find rgb() and its
>> kind ugly, and hex-notation quite elegant).
>
> Such arguments have already been put forward. To summarize:
>
> 1. Hex notation is likely not fully understood by most authors.

What do you mean by "most authors"? It sounds like you are generalizing...

> 2. Use of hex notation is harder to teach than the functional notation.

Depending who your target is. For people who have been using HEX
annotations for a while this is not an issue.
If it is that difficult, why many systems/applications/languages use
this annotation?

> 3. It is generally more difficult to determine what the used color is
> than with RGB functional notation.

I think it depends on the developer. For me, its easier to "guess" the
color in: #A5906A than rgb(165,144,106) or hsl(39%,36%,65%).

> Exceptions include basic colors such as red, green, blue, yellow,
> magenta, cyan, black, white, and shades of gray; for other colors, it
> would be harder to decipher what they are. It's already hard enough to
> do that with functional notation.
>
> 4. It is generally more difficult to create a color without the aid of a
> color generator or color list than with RGB functional notation.

The same as #3... I have been using HEX annotations for 10 years now
and not always I use a color generator. I don' have to convert any
value or use a calculator, as I'm used to see colors in 0-255 range
combinations rather than 0-100. I can guess that pretty much the same
as you do using rgb().

> Ditto on the above exceptions which are easy to commit to memory, but
> that's bypassing the mechanism more than using it since you're only
> using zeros, "F"s, or sequences of identical characters (i.e., for
> shades of gray).
>
> 5. You have to get someone to volunteer to specify it.

Hey! I'm here!

> 6. You have to get someone from all of the major browser vendors to
> implement it. Then you have to be willing to work around targeted
> browsers that don't support it or accept CSS fallback which may consume
> more time than this feature saves.

The implementation would take few hours (plus some more for testing).
I'm sure of it, as transparency feature is already implemented. This
is just matter of adding few lines to the parser and call the
transparency function. As most of the transparency in C is generally
handled in 0-255 (1 byte) it could be even faster than converting
rgb() values into C. I haven't look at the browsers code but if you
want I can post here the required changes for Webkit or Gecko for this
feature. I personally would be glad to help its implementation.

As for older versions, there is no need to be added.

> 7. You have to add it to CSS learning guides.

As you can see in the previous links I posted, #rrggbbaa explanation
is not that complicated.

> 8. You have to be willing to delay CSS3 reaching W3C Recommendation
> status or deferring this to CSS4.

All depends on the css-color module editors.

> 9. The benefit is marginal since it duplicates existing functionality.

Sorry buddy, but it seems that you haven't read the threat in detail.
We have presented not only one advantage of adding this feature
against the actual rgba() annotation. If you think #rrggbbaa is to
duplicate rgba() , then hsla() is also a duplicated feature of rgba().

Received on Tuesday, 6 April 2010 07:49:59 UTC