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

1. As for gray() function.
I don't want gray() function, I want to shorten hex values. %) The thread author obviously wants the same. You do not want gray() function, others including topic author dont't want this too. So there is no sense to discuss something that is not of our interest at all (with same success we could discuss, say, weather or hadron collider).

2. As for alpha opacity.
The only reason why RGB components can be represented as hex is that each RGB component has exactly 256 possible values _by nature_. But this has NOTHING TO DO with opacity. Opacity is always specified as decimal number: for example in "opacity" CSS-property, opacity in "rgba()" CSS-function, or percentage transparency in Photoshop. So, hex representation is not only nonapplicable to opacity values, but just inconsistent with existing opacity values notation. Therefore, opacity should be kept specified as a decimal number and is not a subject to shorten at all.

Exact possible syntax for adding alpha-opacity to hex colors is following:

#cad8d9.0   -- zero opacity;
#cad8d9.27  -- 27% opacity;
#cad8d9.275 -- 27.5% opacity;
#cad8d9     -- 100% opacity (no need for opacity component at all, using just regular hex value.).

3. Expansion rule.
The expansion rule is consistent: we shorten shortest _currently available_ values. #acacac is shortest. #ccc is shortest too. If all RGB components are identical (ac|ac|ac; c|c|c), we can collapse them to one component with the same value: thus, #acacac collapses to #ac, #ccc collapses to #c. So expansion rule _is_ consistent.

4. Shortening syntax -- complete solution.
Complete list of all possible shortening scenarios:

#cccccc => #ccc => #c
#acacac => #ac
#cccccc.5 => #ccc.5 => #c.5
#acacac.5 => #ac.5

That's all.


06.09.2011, 19:31, "Tab Atkins Jr." <jackalmage@gmail.com>:
> 2011/9/5 Marat Tanalin <mtanalin@yandex.ru>:
>
>> �06.09.2011, 03:03, "Tab Atkins Jr." <jackalmage@gmail.com>:
>>> �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.
>
> The difference in expansion rules is definitely bad. �This doesn't
> *necessarily* mean the feature is bad, but it is a strike against it.
> Consistency is important in a language.
>
>>> �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.
>
> We're talking about colors. �Colors should be consistent. �It is
> completely relevant to discuss existing color syntaxes and
> already-planned extensions of them when considering a further
> extension.
>
>>> �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. So, if we able to shorten #cccccc to #ccc, then shortening #ccc to #c (as well as #acacac to #ac) seem just logical. Anyway, we would _lose nothing_ if this feature would be added.
>
> Redundancy isn't necessarily bad - sometimes it can make things easier
> to understand. �Even when it is bad, one still has to consider the
> *amount* of bad that it is, and judge whether it's worth fixing, and
> whether the solution chosen is worth the cost.
>
> I don't think the redundancy of tripling a single character is very
> significant, and the cost of augmenting a compact shorthand notation
> is relatively high (higher than other things with googleable names).
>
>>> �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.
>
> Again, the topic is about colors, specifically about making it easier
> to represent grays. �A gray() function is another option to consider.
>
> ~TJ

Received on Tuesday, 6 September 2011 19:26:42 UTC