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