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

> While I'm not necessarily opposed to something like this, I question
> the utility of saving two characters on a mere 16 colors.  I think the
> 3-digit hex is very readable and trivial to type.


I respectfully disagree. I think the saving of any amount of characters is a worthwhile endeavour, and aids future minification scripts and methodologies. I think a one or two character hex code is trivial to read and understand.

> I am strongly opposed to a 2-digit variant, because it has a different
> expansion rule than the 3-digit hex that already exists.

Again, I disagree. The shorthand for, for example, margins varies dramatically according to the amount of properties you pass it. I believe this falls into the same category. The point of a shorthand is to reduce the amount of characters or properties, and give the same result. I don't see an issue with different expansion rules, when the use cases are this simple.

> If we wanted to make it easier to write grays, I'd be more in favor of
> a gray(<number> | <percentage>) function.  However, it's relatively
> easy to use the hsl() function to create grays already, with
> "hsl(0,0%,<gray percentage>)".  50% gray is just hsl(0,0%,50%), which
> is slightly more verbose than gray(50%), but much better than
> rgb(50%,50%,50%).

I'm not against a Gray() or GrayA() function. True, you can achieve the same with HSL, but let's be honest, have you seen anyone in the wild using HSL other than with pre-compilers for calculated values? It's included for completeness, not for clarity.

> What should 4 digit expansion do?  Should it expand characters in both ways (same channel and across channels)?  I think we can agree on a strong "No!" at such chaos.

Obviously a 4 digit expansion is nonsensical in this scenario.

> I tend to think any benefit in space or typing here is not worth the
> potential confusion for those reading style sheets written by
> others.  (I'm particularly hesitant to add new syntax that's hard to
> search for with search engines -- somebody who doesn't know what
> hsl() is can search for it; that's a good bit harder in this case.)

I don't think it is hard to search for "hexadecimal colour shorthand". How would you search for the current incarnation of e.g. #123?

> I support an 8-digit hex with an extra two hex places for alpha (#RRGGBBAA). I believe having a shortcut for this is extra confusing an unnecessary.

I too support this. I think it's strange that alpha has been represented as a decimal rather than a hexadecimal value in RGBA, while the other channels are hex. I don't see an issue in having a 4 digit shorthand for this property.

Thanks,

AK

On 3 Aug 2011, at 03:17, Alan Gresley wrote:

> On 3/08/2011 9:51 AM, Tab Atkins Jr. wrote:
>> On Tue, Aug 2, 2011 at 4:44 PM, Alan Gresley<alan@css-class.com>  wrote:
>>> I totally agree with Tab here regarding a 2-hexadigit variant. The expansion
>>> rule is different and could be confusing to authors if any method was
>>> spec'd. I'm also against having a 4-hexadigit as a shortcut for 8-hexadigit
>>> (last two digits for alpha).
>> 
>> Bwuh?  Are you against an 8-digit hex variant as well, or just against
>> the 4-digit variant specifically?  If the latter, why?  4-digit hex is
>> expanded to 8-digit hex in exactly the same way that 3-digit expands
>> to 6-digit.
>> 
>> ~TJ
> 
> 
> I support an 8-digit hex with an extra two hex places for alpha (#RRGGBBAA). I believe having a shortcut for this is extra confusing an unnecessary.
> 
> 
> 
> 
> -- 
> Alan Gresley
> http://css-3d.org/
> http://css-class.com/
>