Brief   Full   Jump   ▶

Small
Medium
Large

Teal
High contrast
Bluish
Black

Sans-serif
Serif
Monospaced
Close
d
?
Styles

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

50 messages.

[css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Markus Bruch   Sun, 31 Jul 2011 13:34:53 +0200

www-style > August 2011 > 0000.html

Received on Tuesday, 2 August 2011 09:06:53 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: www-style@w3.org.

Hi, I'm new to this list, so please forgive if this topic has been talked about before. I'd like to propose to further shorten the css hex color notation. Known notation: .orange { color: #ff6600; } to: .orange { color: #f60; } I would suggest that for a specific set of 16 grayscale shades, to reduce the rgb-values to one single character: .gray { color: #ccc; } to: .gray { color: #c; } In addition to it's only marginal bandwith or space saving it would have the benefit of being concise and easily visible to the reader, that this code assigns a grayscale color (from a set of 16 shades, #0 - #f). What do you think? Regards, Markus Bruch -- macinfo@arcor.de
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Antony Kennedy   Tue, 2 Aug 2011 10:32:19 +0100

www-style > August 2011 > 0000.html

Received on Tuesday, 2 August 2011 09:32:53 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: macinfo@arcor.de
Copied to: www-style@w3.org.

I like this idea. To extend it to 255 shades of grey you could also use two characters, like #ac. Could a similar implementation be used with RGB()? Although easier to read, it is a more verbose format. A On 31 Jul 2011, at 12:34, Markus Bruch wrote: > Hi, I'm new to this list, so please forgive if this topic has been > talked about before. > > > I'd like to propose to further shorten the css hex color notation. > > Known notation: > > .orange { color: #ff6600; } > > to: > > .orange { color: #f60; } > > I would suggest that for a specific set of 16 grayscale shades, > to reduce the rgb-values to one single character: > > .gray { color: #ccc; } > > to: > > .gray { color: #c; } > > In addition to it's only marginal bandwith or space saving it > would have the benefit of being concise and easily visible to > the reader, that this code assigns a grayscale color (from a > set of 16 shades, #0 - #f). > > What do you think? > > Regards, > > Markus Bruch > > -- > macinfo@arcor.de > > >
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Alan Gresley   Tue, 02 Aug 2011 20:54:50 +1000

www-style > August 2011 > 0000.html

Received on Tuesday, 2 August 2011 10:55:18 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: antony@silversquid.com
Copied to: macinfo@arcor.de, www-style@w3.org.

I have sent this as a new message for a new thread. > On 31 Jul 2011, at 12:34, Markus Bruch wrote: > >> Hi, I'm new to this list, so please forgive if this topic has been >> talked about before. Welcome. It would be good to start a new topic instead of piggybacking on top of an existing thread. >> I'd like to propose to further shorten the css hex color notation. >> >> Known notation: >> >> .orange { color: #ff6600; } >> >> to: >> >> .orange { color: #f60; } >> >> I would suggest that for a specific set of 16 grayscale shades, >> to reduce the rgb-values to one single character: >> >> .gray { color: #ccc; } >> >> to: >> >> .gray { color: #c; } >> >> In addition to it's only marginal bandwith or space saving it >> would have the benefit of being concise and easily visible to >> the reader, that this code assigns a grayscale color (from a >> set of 16 shades, #0 - #f). >> >> What do you think? >> >> Regards, >> >> Markus Bruch If such hexadecimal notation was added, it would have to map the same as #rgb currently works. So #0 would equal #000000, #7 would equal #777777 and #f would equal #ffffff. On 2/08/2011 7:32 PM, Antony Kennedy wrote: > I like this idea. To extend it to 255 shades of grey you could also use two characters, like #ac. 256 different shade to be exact. > Could a similar implementation be used with RGB()? Although easier to read, it is a more verbose format. > > A Possibly but it would be not rgb() anymore. You would want grayscale() but this is counter to saving bandwidth. Possibly gs() with a range of '0' to '255'. I presume you are thinking of using this on handheld devices. -- Alan Gresley http://css-3d.org/ http://css-class.com/
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Antony Kennedy   Tue, 2 Aug 2011 13:23:56 +0100

www-style > August 2011 > 0000.html

Received on Tuesday, 2 August 2011 12:24:24 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: alan@css-class.com
Copied to: macinfo@arcor.de, www-style@w3.org.

> If such hexadecimal notation was added, it would have to map the same as #rgb currently works. So #0 would equal #000000, #7 would equal #777777 and #f would equal #ffffff. I think this is exactly what was suggested. > 256 different shade to be exact. Of course, apologies. #ab would equal #ababab, #cd would equal #cdcdcd and #f5 would equal #f5f5f5. To clarify: #000000 #000 #00 #0 All of the above values would evaluate to #000000. > Possibly but it would be not rgb() anymore. You would want grayscale() but this is counter to saving bandwidth. Possibly gs() with a range of '0' to '255'. I presume you are thinking of using this on handheld devices. I'm not sure why it wouldn't be rgb(). rgb(100) would be the same as rgb(100,100,100) – it would still have values for all three channels. gs() or gray() both offer more clarity, though. Yes, for handheld devices or just as a best practise, for reducing bandwidth and file sizes. AK On 2 Aug 2011, at 11:54, Alan Gresley wrote: > I have sent this as a new message for a new thread. > > >> On 31 Jul 2011, at 12:34, Markus Bruch wrote: >> >>> Hi, I'm new to this list, so please forgive if this topic has been >>> talked about before. > > > Welcome. It would be good to start a new topic instead of piggybacking on top of an existing thread. > > >>> I'd like to propose to further shorten the css hex color notation. >>> >>> Known notation: >>> >>> .orange { color: #ff6600; } >>> >>> to: >>> >>> .orange { color: #f60; } >>> >>> I would suggest that for a specific set of 16 grayscale shades, >>> to reduce the rgb-values to one single character: >>> >>> .gray { color: #ccc; } >>> >>> to: >>> >>> .gray { color: #c; } >>> >>> In addition to it's only marginal bandwith or space saving it >>> would have the benefit of being concise and easily visible to >>> the reader, that this code assigns a grayscale color (from a >>> set of 16 shades, #0 - #f). >>> >>> What do you think? >>> >>> Regards, >>> >>> Markus Bruch > > > If such hexadecimal notation was added, it would have to map the same as #rgb currently works. So #0 would equal #000000, #7 would equal #777777 and #f would equal #ffffff. > > > On 2/08/2011 7:32 PM, Antony Kennedy wrote: >> I like this idea. To extend it to 255 shades of grey you could also use two characters, like #ac. > > > 256 different shade to be exact. > > >> Could a similar implementation be used with RGB()? Although easier to read, it is a more verbose format. >> >> A > > > Possibly but it would be not rgb() anymore. You would want grayscale() but this is counter to saving bandwidth. Possibly gs() with a range of '0' to '255'. I presume you are thinking of using this on handheld devices. > > > > -- > Alan Gresley > http://css-3d.org/ > http://css-class.com/ >
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Alan Gresley   Tue, 02 Aug 2011 22:41:52 +1000

www-style > August 2011 > 0000.html

Received on Tuesday, 2 August 2011 12:42:29 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: antony@silversquid.com
Copied to: macinfo@arcor.de, www-style@w3.org.

On 2/08/2011 10:23 PM, Antony Kennedy wrote: > On 2 Aug 2011, at 11:54, Alan Gresley wrote: >> Possibly but it would be not rgb() anymore. You would want >> grayscale() but this is counter to saving bandwidth. Possibly gs() >> with a range of '0' to '255'. I presume you are thinking of using >> this on handheld devices. > > I'm not sure why it wouldn't be rgb(). rgb(100) would be the same as > rgb(100,100,100) – it would still have values for all three channels. > gs() or gray() both offer more clarity, though. Yes, for handheld > devices or just as a best practise, for reducing bandwidth and file > sizes. > > AK It would have to be gs() or gray() for forward compatibility since rgb(100) or something similar has to throw a parsing error since it is an invalid value in rgb(). -- Alan Gresley http://css-3d.org/ http://css-class.com/
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Antony Kennedy   Tue, 2 Aug 2011 14:02:09 +0100

www-style > August 2011 > 0000.html

Received on Tuesday, 2 August 2011 13:02:46 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: alan@css-class.com
Copied to: macinfo@arcor.de, www-style@w3.org.

Ah, yes, of course. We would probably want to allow alpha channels too, but gsa() and graya() do not feel especially intuitive… On 2 Aug 2011, at 13:41, Alan Gresley wrote: > On 2/08/2011 10:23 PM, Antony Kennedy wrote: >> On 2 Aug 2011, at 11:54, Alan Gresley wrote: > >>> Possibly but it would be not rgb() anymore. You would want >>> grayscale() but this is counter to saving bandwidth. Possibly gs() >>> with a range of '0' to '255'. I presume you are thinking of using >>> this on handheld devices. >> >> I'm not sure why it wouldn't be rgb(). rgb(100) would be the same as >> rgb(100,100,100) – it would still have values for all three channels. >> gs() or gray() both offer more clarity, though. Yes, for handheld >> devices or just as a best practise, for reducing bandwidth and file >> sizes. >> >> AK > > > It would have to be gs() or gray() for forward compatibility since rgb(100) or something similar has to throw a parsing error since it is an invalid value in rgb(). > > > > > -- > Alan Gresley > http://css-3d.org/ > http://css-class.com/ >
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
"Tab Atkins Jr."   Tue, 2 Aug 2011 11:01:00 -0700

www-style > August 2011 > 0000.html

Received on Tuesday, 2 August 2011 18:01:47 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: macinfo@arcor.de
Copied to: www-style@w3.org.

On Sun, Jul 31, 2011 at 4:34 AM, Markus Bruch <macinfo@arcor.de> wrote: > I would suggest that for a specific set of 16 grayscale shades, > to reduce the rgb-values to one single character: > >        .gray { color: #ccc; } > > to: > >        .gray { color: #c; } 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 am strongly opposed to a 2-digit variant, because it has a different expansion rule than the 3-digit hex that already exists. 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%). ~TJ
RE: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Brian Manthos   Tue, 2 Aug 2011 20:14:19 +0000

www-style > August 2011 > 0000.html

Received on Tuesday, 2 August 2011 20:14:48 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: jackalmage@gmail.com, macinfo@arcor.de
Copied to: www-style@w3.org, www-style@w3.org.

Tab: > I am strongly opposed to a 2-[hexa]digit variant, because it has a different expansion rule than the 3-digit hex that already exists. Doesn't the 1-hexadigit representation have the same concern (different expansion rule than 3-digit hex)?
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
"Tab Atkins Jr."   Tue, 2 Aug 2011 13:22:51 -0700

www-style > August 2011 > 0000.html

Received on Tuesday, 2 August 2011 20:23:46 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: brianman@microsoft.com
Copied to: macinfo@arcor.de, www-style@w3.org, www-style@w3.org.

On Tue, Aug 2, 2011 at 1:14 PM, Brian Manthos <brianman@microsoft.com> wrote: > Tab: >> I am strongly opposed to a 2-[hexa]digit variant, because it has a different expansion rule than the 3-digit hex that already exists. > > Doesn't the 1-hexadigit representation have the same concern (different expansion rule than 3-digit hex)? Not really. The 3-digit hex works by duplicating each digit in-place. The 1-digit hex would sextuple the single digit in-place. (One could also argue that 1-digit hex uses the same expansion rule as 2-digit hex, and one would be right. It's a degenerate case.) 2-digit hex, if it used the same expansion rule, would expand #12 into #111222 (which is obviously useless). ~TJ
RE: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Brian Manthos   Tue, 2 Aug 2011 20:35:26 +0000

www-style > August 2011 > 0000.html

Received on Tuesday, 2 August 2011 20:36:02 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: macinfo@arcor.de, www-style@w3.org, www-style@w3.org.

/confused Let's see if I can get this straight. You're opposed to 2 digit expansion because it follows a different pattern. But you're ok with 1 digit expansion which is a degenerate flavor of 2 digit expansion's pattern. Ok.... All that said (though certainly not sorted out), I don't think either #H or #HH are worthwhile *yet*. Current 3 digit expansion expands characters within a color channel. The proposed 1 and 2 digit expansions expand characters *across* color channels. That seems like a step in the wrong direction w/r/t complexity. 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. What I *would* like to see considered is using 4 digit and 8 digit syntax as an alternative to rgba(). Supporting any flavor of 1, 2, 4, or 5 digit syntax *before* addressing support for RGBA seems like a paint-your-self-in-a-corner exercise.
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
"Tab Atkins Jr."   Tue, 2 Aug 2011 13:49:50 -0700

www-style > August 2011 > 0000.html

Received on Tuesday, 2 August 2011 20:50:37 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: brianman@microsoft.com
Copied to: macinfo@arcor.de, www-style@w3.org, www-style@w3.org.

On Tue, Aug 2, 2011 at 1:35 PM, Brian Manthos <brianman@microsoft.com> wrote: > /confused > > Let's see if I can get this straight. > > You're opposed to 2 digit expansion because it follows a different pattern. > > But you're ok with 1 digit expansion which is a degenerate flavor of 2 digit expansion's pattern. No. 1-digit expansion can legitimately be explained as *either* using the same pattern as 2-digit expansion *or* 3-digit expansion. It's a degenerate case, and like all degenerate cases, is somewhat chimerical. > 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. Holy jeezus no. > What I *would* like to see considered is using 4 digit and 8 digit syntax as an alternative to rgba().  Supporting any flavor of 1, 2, 4, or 5 digit syntax *before* addressing support for RGBA seems like a paint-your-self-in-a-corner exercise. I have a patch for Webkit that's been pending for the last year on Colors 4 introducing that syntax (Hyatt won't let me introduce it until it's in a spec *somewhere*). Once someone has editting time to actually write it, I can drop it right in, because it's a trivial thing to add, as I'm sure you know. ^_^ ~TJ
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
"L. David Baron"   Tue, 2 Aug 2011 14:31:49 -0700

www-style > August 2011 > 0000.html

Received on Tuesday, 2 August 2011 21:32:15 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: macinfo@arcor.de
Copied to: www-style@w3.org.

On Sunday 2011-07-31 13:34 +0200, Markus Bruch wrote: > Hi, I'm new to this list, so please forgive if this topic has been > talked about before. One note: please start a new thread by emailing a new message rather than replying to an existing one and changing the subject, which makes it show up in the middle of some other unrelated thread in many mail clients. (Or, if you insist on replying, you need to delete the In-Reply-To and References headers.) > I would suggest that for a specific set of 16 grayscale shades, > to reduce the rgb-values to one single character: > > .gray { color: #ccc; } > > to: > > .gray { color: #c; } > > In addition to it's only marginal bandwith or space saving it > would have the benefit of being concise and easily visible to > the reader, that this code assigns a grayscale color (from a > set of 16 shades, #0 - #f). 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.) -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla Corporation http://www.mozilla.com/ 𝄂
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Alan Gresley   Wed, 03 Aug 2011 09:44:51 +1000

www-style > August 2011 > 0000.html

Received on Tuesday, 2 August 2011 23:45:32 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: brianman@microsoft.com, macinfo@arcor.de, www-style@w3.org, www-style@w3.org.

On 3/08/2011 6:22 AM, Tab Atkins Jr. wrote: > On Tue, Aug 2, 2011 at 1:14 PM, Brian Manthos<brianman@microsoft.com> > wrote: >> Tab: >>> I am strongly opposed to a 2-[hexa]digit variant, because it has >>> a different expansion rule than the 3-digit hex that already >>> exists. >> >> Doesn't the 1-hexadigit representation have the same concern >> (different expansion rule than 3-digit hex)? > > Not really. The 3-digit hex works by duplicating each digit > in-place. The 1-digit hex would sextuple the single digit in-place. > (One could also argue that 1-digit hex uses the same expansion rule > as 2-digit hex, and one would be right. It's a degenerate case.) > > 2-digit hex, if it used the same expansion rule, would expand #12 > into #111222 (which is obviously useless). > > ~TJ 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). -- Alan Gresley http://css-3d.org/ http://css-class.com/
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
"Tab Atkins Jr."   Tue, 2 Aug 2011 16:51:12 -0700

www-style > August 2011 > 0000.html

Received on Tuesday, 2 August 2011 23:51:59 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: alan@css-class.com
Copied to: brianman@microsoft.com, macinfo@arcor.de, www-style@w3.org, www-style@w3.org.

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
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Alan Gresley   Wed, 03 Aug 2011 12:17:07 +1000

www-style > August 2011 > 0000.html

Received on Wednesday, 3 August 2011 02:17:34 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: brianman@microsoft.com, macinfo@arcor.de, www-style@w3.org, www-style@w3.org.

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/
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Brad Kemper   Tue, 2 Aug 2011 21:47:15 -0700

www-style > August 2011 > 0000.html

Received on Wednesday, 3 August 2011 04:47:46 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: alan@css-class.com
Copied to: jackalmage@gmail.com, brianman@microsoft.com, macinfo@arcor.de, www-style@w3.org, www-style@w3.org.

On Aug 2, 2011, at 7:17 PM, Alan Gresley <alan@css-class.com> 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. I disagree. I think it would be confusing and inconsistent to have a short form of #RRGGBB (#RGB) to go with the long form, and NOT have a short form of #RRGGBBAA (#RGBA) to go with the long form. I don't feel there is much need for gray(n) or #H gray. Gray(n%) would be kind of convenient and easy to learn as an alternative to hsl(), as Tab mentioned. GrayA(n%,a) wouldn't be terrible, but it feels to me like it looses a bit of the simplicity that made me like the Gray(n%) idea.
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Antony Kennedy   Wed, 3 Aug 2011 10:40:22 +0100

www-style > August 2011 > 0000.html

Received on Wednesday, 3 August 2011 09:40:49 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: alan@css-class.com
Copied to: jackalmage@gmail.com, brianman@microsoft.com, macinfo@arcor.de, www-style@w3.org, www-style@w3.org.

> 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/ >
RE: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Sylvain Galineau   Wed, 3 Aug 2011 15:21:17 +0000

www-style > August 2011 > 0000.html

Received on Wednesday, 3 August 2011 15:21:48 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: antony@silversquid.com, alan@css-class.com
Copied to: jackalmage@gmail.com, brianman@microsoft.com, macinfo@arcor.de, www-style@w3.org, www-style@w3.org.

Not all savings are a worthwhile endeavor because they're trade-offs: savings do not come for free. If the goal is to improve minification, some data on the gains achieved on real-world CSS would be helpful. I find it hard to believe there are so many color values that can be reduced to 2 digits in the average stylesheet that it would significantly improve minification, at least by a rate that justifies the additional complexity. Never mind that in practice such savings are only really possible when most deployed browsers support the new syntax. Supporting alpha in the hex notation does make sense from a consistency standpoint; that it also saves a few extra bytes is a positive side-effect. From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Antony Kennedy Sent: Wednesday, August 03, 2011 2:40 AM To: Alan Gresley Cc: Tab Atkins Jr.; Brian Manthos; Markus Bruch; www-style@w3.org Subject: 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<mailto: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/
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Markus Bruch   Wed, 03 Aug 2011 17:32:54 +0000

www-style > September 2011 > 0000.html

Received on Monday, 5 September 2011 16:25:09 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: www-style@w3.org.

Am 02.08.2011 um 11:32 schrieb Antony Kennedy: > I like this idea. To extend it to 255 shades of grey you could also use two characters, like #ac. Ah great idea, I didn't think of that! If I understand it right you intend it to work like this: .gray { color: #acacac; } --> .gray { color: #ac } (Just store one of the 3 equal rgb-channnel bytes; at rendering put this one value back in any of the r-, g- and b-channels.) This addition would round the idea off nicely to render either 16-shade or 256-shade gray color. > > Could a similar implementation be used with RGB()? Although easier to read, it is a more verbose format. > > A > > On 31 Jul 2011, at 12:34, Markus Bruch wrote: > >> Hi, I'm new to this list, so please forgive if this topic has been >> talked about before. >> >> >> I'd like to propose to further shorten the css hex color notation. >> >> Known notation: >> >> .orange { color: #ff6600; } >> >> to: >> >> .orange { color: #f60; } >> >> I would suggest that for a specific set of 16 grayscale shades, >> to reduce the rgb-values to one single character: >> >> .gray { color: #ccc; } >> >> to: >> >> .gray { color: #c; } >> >> In addition to it's only marginal bandwith or space saving it >> would have the benefit of being concise and easily visible to >> the reader, that this code assigns a grayscale color (from a >> set of 16 shades, #0 - #f). >> >> What do you think? >> >> Regards, >> >> Markus Bruch >> >> -- >> macinfo@arcor.de >> >> >> > >
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Antony Kennedy   Thu, 4 Aug 2011 13:40:01 +0100

www-style > August 2011 > 0000.html

Received on Thursday, 4 August 2011 12:40:35 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: macinfo@arcor.de
Copied to: www-style@w3.org.

Exactly right. And I still think the savings are worth it. On 3 Aug 2011, at 16:29, Markus Bruch wrote: > > Am 02.08.2011 um 11:32 schrieb Antony Kennedy: > >> I like this idea. To extend it to 255 shades of grey you could also use two characters, like #ac. > > Ah great idea, I didn't think of that! > > If I understand it right you intend it to work like this: > > > .gray { color: #acacac; } --> .gray { color: #ac } > > > (Just store one of the 3 equal rgb-channnel bytes; at rendering put this one value back in any of the r-, g- and b-channels.) > > This addition would round the idea off nicely to render either 16-shade or 256-shade gray color. > > > >> >> Could a similar implementation be used with RGB()? Although easier to read, it is a more verbose format. >> >> A >> >> On 31 Jul 2011, at 12:34, Markus Bruch wrote: >> >>> Hi, I'm new to this list, so please forgive if this topic has been >>> talked about before. >>> >>> >>> I'd like to propose to further shorten the css hex color notation. >>> >>> Known notation: >>> >>> .orange { color: #ff6600; } >>> >>> to: >>> >>> .orange { color: #f60; } >>> >>> I would suggest that for a specific set of 16 grayscale shades, >>> to reduce the rgb-values to one single character: >>> >>> .gray { color: #ccc; } >>> >>> to: >>> >>> .gray { color: #c; } >>> >>> In addition to it's only marginal bandwith or space saving it >>> would have the benefit of being concise and easily visible to >>> the reader, that this code assigns a grayscale color (from a >>> set of 16 shades, #0 - #f). >>> >>> What do you think? >>> >>> Regards, >>> >>> Markus Bruch >>> >>> -- >>> macinfo@arcor.de >>> >>> >>> >> >> >
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Marat Tanalin   Tue, 06 Sep 2011 01:23:42 +0400

www-style > September 2011 > 0000.html

Received on Monday, 5 September 2011 21:24:17 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: www-style@w3.org.

Recently, when I (once again) was typing redundant #ccc, #666, #999, etc., I've arrived at the same idea: it would be nice to be able to use #c, #6, #9 shortcuts. Replacing #acacac with #ac looks quite nice and reasonable too. There is nothing wrong with #ac compared with #c as well as with existing #ccc. Such shortcuts are not more consusing than existing #ccc, #666, #999, etc. As for similar additions to rgba (that has been mentioned in the thread), I personally almost don't care about this since I consider rgba paradigm itself just wrong and almost useless as for CSS: instead of rgba(), it would be _much_ more useful to have background-opacity property that would control opacity of _entire_ background including background color _and_ image together. Those interested may see proposal in sibling thread I've started a moment ago: http://lists.w3.org/Archives/Public/www-style/2011Sep/0033.html
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
"Tab Atkins Jr."   Mon, 5 Sep 2011 15:34:08 -0700

www-style > September 2011 > 0000.html

Received on Monday, 5 September 2011 22:34:59 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: mtanalin@yandex.ru
Copied to: www-style@w3.org.

On Mon, Sep 5, 2011 at 2:23 PM, Marat Tanalin <mtanalin@yandex.ru> wrote: > Recently, when I (once again) was typing redundant #ccc, #666, #999, etc., I've arrived at the same idea: it would be nice to be able to use #c, #6, #9 shortcuts. > > Replacing #acacac with #ac looks quite nice and reasonable too. There is nothing wrong with #ac compared with #c as well as with existing #ccc. > > Such shortcuts are not more consusing than existing #ccc, #666, #999, etc. > > As for similar additions to rgba (that has been mentioned in the thread), I personally almost don't care about this since I consider rgba paradigm itself just wrong and almost useless as for CSS: > > instead of rgba(), it would be _much_ more useful to have background-opacity property that would control opacity of _entire_ background including background color _and_ image together. Those interested may see proposal in sibling thread I've started a moment ago: > > http://lists.w3.org/Archives/Public/www-style/2011Sep/0033.html There have been multiple threads talking about 1- or 2-digit hex shorthands. One of them was even posted to today or yesterday. I suggest a search of the archives (at lists.w3.org - use Google with that url) to catch up on the current discussion and/or find the previous thread to reply on. ~TJ
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Marat Tanalin   Tue, 06 Sep 2011 02:42:31 +0400

www-style > September 2011 > 0000.html

Received on Monday, 5 September 2011 22:43:09 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: www-style@w3.org.

My message _is_ reply to latest thread by Markus Bruch (consider subject). I've just recently joined to www-style, so cannot to reply directly to thread-starting message by Markus. 06.09.2011, 02:34, "Tab Atkins Jr." <jackalmage@gmail.com>: > On Mon, Sep 5, 2011 at 2:23 PM, Marat Tanalin <mtanalin@yandex.ru> wrote: > >>  Recently, when I (once again) was typing redundant #ccc, #666, #999, etc., I've arrived at the same idea: it would be nice to be able to use #c, #6, #9 shortcuts. >> >>  Replacing #acacac with #ac looks quite nice and reasonable too. There is nothing wrong with #ac compared with #c as well as with existing #ccc. >> >>  Such shortcuts are not more consusing than existing #ccc, #666, #999, etc. >> >>  As for similar additions to rgba (that has been mentioned in the thread), I personally almost don't care about this since I consider rgba paradigm itself just wrong and almost useless as for CSS: >> >>  instead of rgba(), it would be _much_ more useful to have background-opacity property that would control opacity of _entire_ background including background color _and_ image together. Those interested may see proposal in sibling thread I've started a moment ago: >> >>  http://lists.w3.org/Archives/Public/www-style/2011Sep/0033.html > > There have been multiple threads talking about 1- or 2-digit hex > shorthands.  One of them was even posted to today or yesterday.  I > suggest a search of the archives (at lists.w3.org - use Google with > that url) to catch up on the current discussion and/or find the > previous thread to reply on. > > ~TJ
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
"Tab Atkins Jr."   Mon, 5 Sep 2011 16:03:12 -0700

www-style > September 2011 > 0000.html

Received on Monday, 5 September 2011 23:03:59 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: mtanalin@yandex.ru
Copied to: www-style@w3.org.

2011/9/5 Marat Tanalin <mtanalin@yandex.ru>: > My message _is_ reply to latest thread by Markus Bruch (consider subject). I've just recently joined to www-style, so cannot to reply directly to thread-starting message by Markus. Ah, okay. Sorry about that, then. > On Mon, Sep 5, 2011 at 2:23 PM, Marat Tanalin <mtanalin@yandex.ru> wrote: >>  Recently, when I (once again) was typing redundant #ccc, #666, #999, etc., I've arrived at the same idea: it would be nice to be able to use #c, #6, #9 shortcuts. >> >>  Replacing #acacac with #ac looks quite nice and reasonable too. There is nothing wrong with #ac compared with #c as well as with existing #ccc. >> >>  Such shortcuts are not more consusing than existing #ccc, #666, #999, etc. >> >>  As for similar additions to rgba (that has been mentioned in the thread), I personally almost don't care about this since I consider rgba paradigm itself just wrong and almost useless as for CSS: >> >>  instead of rgba(), it would be _much_ more useful to have background-opacity property that would control opacity of _entire_ background including background color _and_ image together. Those interested may see proposal in sibling thread I've started a moment ago: >> >>  http://lists.w3.org/Archives/Public/www-style/2011Sep/0033.html 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. 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). 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.) 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. 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. ~TJ
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Marat Tanalin   Tue, 06 Sep 2011 03:32:33 +0400

www-style > September 2011 > 0000.html

Received on Monday, 5 September 2011 23:33:10 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: www-style@w3.org.

06.09.2011, 03:03, "Tab Atkins Jr." <jackalmage@gmail.com>: > 2011/9/5 Marat Tanalin <mtanalin@yandex.ru>: >>>   As for similar additions to rgba (that has been mentioned in the thread), I personally almost don't care about this since I consider rgba paradigm itself just wrong and almost useless as for CSS: >>> >>>   instead of rgba(), it would be _much_ more useful to have background-opacity property that would control opacity of _entire_ background including background color _and_ image together. Those interested may see proposal in sibling thread I've started a moment ago: >>> >>>   http://lists.w3.org/Archives/Public/www-style/2011Sep/0033.html > > 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). > 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. > 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. > 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. > ~TJ
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Alan Gresley   Tue, 06 Sep 2011 12:01:32 +1000

www-style > September 2011 > 0000.html

Received on Tuesday, 6 September 2011 02:01:27 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: mtanalin@yandex.ru
Copied to: jackalmage@gmail.com, www-style@w3.org.

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/
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Antony Kennedy   Tue, 6 Sep 2011 10:18:34 +0100

www-style > September 2011 > 0000.html

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

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: alan@css-class.com
Copied to: mtanalin@yandex.ru, jackalmage@gmail.com, www-style@w3.org.

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/ >
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
"Tab Atkins Jr."   Tue, 6 Sep 2011 08:31:09 -0700

www-style > September 2011 > 0000.html

Received on Tuesday, 6 September 2011 15:31:57 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: mtanalin@yandex.ru
Copied to: www-style@w3.org.

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
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Marat Tanalin   Tue, 06 Sep 2011 23:26:03 +0400

www-style > September 2011 > 0000.html

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

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: www-style@w3.org.

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
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Philippe Wittenbergh   Wed, 7 Sep 2011 11:34:23 +0900

www-style > September 2011 > 0000.html

Received on Wednesday, 7 September 2011 02:34:48 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: www-style@w3.org
Copied to: mtanalin@yandex.ru.

On Sep 7, 2011, at 4:26 AM, Marat Tanalin wrote: > 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). It may not be in _your_ interest, but personally I'm much more interested in having a gray() function than extending the hexadecimal notation. I suspect Tab is more interested in the the gray() function as well. But I don't live in his head to know… When discussing new proposals, the CSS WG should examine all options. imho. > 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. There are precedents for hexadecimal notation including opacity. Here is a code snippet from one of my stylesheets: filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#801e5799', endColorstr='#7db9e8',GradientType=0 ); /* IE6-9 */ note the startColorstr value, equivalent to rgba(30,87,153,0.5) That is implemented by Microsoft. Inkscape also uses that notation, fwiw. (not arguing if it is good or bad to have such a notation in CSS - personally, I strikes me as very hard to read, but that is just me; I'm satisfied with rgba() and hsla()). Philippe -- Philippe Wittenbergh http://l-c-n.com/
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Shane Stephens   Tue, 6 Sep 2011 19:52:49 -0700

www-style > September 2011 > 0000.html

Received on Wednesday, 7 September 2011 02:53:15 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: mtanalin@yandex.ru
Copied to: jackalmage@gmail.com, www-style@w3.org.

> > > 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. > > RGB components are represented by 256 values precisely because of representational issues - that is, each component is represented by a single byte. Alpha components are typically represented the same way, hence the very convenient 32-bit argb and rgba representations that one finds pretty much everywhere. To the extent that there's a problem here at all, it is with the fact that the existing opacity values notation is different to the existing rgb values notations when the underlying representations are identical, not with the proposed 4- and 8-character hex shortenings :) Cheers, -Shane
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Shane Stephens   Tue, 6 Sep 2011 19:54:48 -0700

www-style > September 2011 > 0000.html

Received on Wednesday, 7 September 2011 02:55:11 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: mtanalin@yandex.ru
Copied to: jackalmage@gmail.com, www-style@w3.org.

> > > RGB components are represented by 256 values precisely because of > representational issues - that is, each component is represented by a single > byte. > Woah. That's a horrible sentence. I blame the fact that I'm sick... Let me try again: There's no reason in color theory why RGB components should be confined to 256 values. They're this way because the underlying representation is a byte; which as it turns out is the same as the underlying representation of the alpha component. Cheers, -Shane
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Alex Danilo   Wed, 07 Sep 2011 13:04:50 +1000

www-style > September 2011 > 0000.html

Received on Wednesday, 7 September 2011 03:05:29 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: shans@google.com
Copied to: mtanalin@yandex.ru, jackalmage@gmail.com, www-style@w3.org.

Hi Shane, --Original Message--: > > >RGB components are represented by 256 values precisely because of representational issues - that is, each component is represented by a single byte. > > >Woah. That's a horrible sentence. I blame the fact that I'm sick... > >Let me try again: > >There's no reason in color theory why RGB components should be confined to 256 values. They're this way because the underlying representation is a byte; which as it turns out is the same as the underlying representation of the alpha component. How about: "Historically many graphics engine implementations used a byte to represent a colour value, that limits the possible resolution to 256 values and the hex notation reflects the historic implementations. Each colour channel can be represented with arbitrary precision, e.g. OpenEXR which can store floats per channel. Thus there is no distinction between a colour channel and an alpha channel in terms of precision and/or resolution". Cheers, Alex >Cheers, >    -Shane  > > > >
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Shane Stephens   Tue, 6 Sep 2011 20:07:10 -0700

www-style > September 2011 > 0000.html

Received on Wednesday, 7 September 2011 03:07:44 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: alex@abbra.com
Copied to: mtanalin@yandex.ru, jackalmage@gmail.com, www-style@w3.org.

> > > How about: "Historically many graphics engine implementations used a byte > to represent a colour value, > that limits the possible resolution to 256 values and the hex notation > reflects the historic implementations. > Each colour channel can be represented with arbitrary precision, e.g. > OpenEXR which can store floats > per channel. Thus there is no distinction between a colour channel and an > alpha channel in terms > of precision and/or resolution". > > Works for me :) Cheers, -Shane
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Alan Gresley   Wed, 07 Sep 2011 13:28:31 +1000

www-style > September 2011 > 0000.html

Received on Wednesday, 7 September 2011 03:28:19 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: mtanalin@yandex.ru
Copied to: jackalmage@gmail.com, www-style@w3.org.

On 7/09/2011 5:26 AM, Marat Tanalin wrote: > 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_. This is an statement that has no foundation. There is 256 possible values since all values must be transmitted as binary code which has only two value (either 0 or 1). Computing has expanded this in multiples like so: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024. A calculator set to decimals (dec), will change the value 'FF' to '255' when hexadecimals (hex) is selected. RGB color space can not be said to be *by nature*. Please read about RGB color space [1]. | RGB is a convenient color model for computer graphics | because the human visual system works in a way that | is similar — though not quite identical — to an RGB | color space. As I know from personal experimentation, color and human perception of it is far more mysterious than what is known in the mainstream science, but is is far from the scope of this thread. 1. http://en.wikipedia.org/wiki/RGB_color_space -- Alan Gresley http://css-3d.org/ http://css-class.com/
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Alan Gresley   Wed, 07 Sep 2011 13:39:36 +1000

www-style > September 2011 > 0000.html

Received on Wednesday, 7 September 2011 03:39:21 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: shans@google.com
Copied to: mtanalin@yandex.ru, jackalmage@gmail.com, www-style@w3.org.

On 7/09/2011 12:54 PM, Shane Stephens wrote: >> >> >> RGB components are represented by 256 values precisely because of >> representational issues - that is, each component is represented by a single >> byte. >> > > Woah. That's a horrible sentence. I blame the fact that I'm sick... Can relate somewhat. > Let me try again: > > There's no reason in color theory why RGB components should be confined to > 256 values. They're this way because the underlying representation is a > byte; which as it turns out is the same as the underlying representation of > the alpha component. > > Cheers, > -Shane I think the reason we have 256 colors per channel is that when tuples of this can generate 16,777,216 colors, it goes way over the 6 millions colors that human can differentiate and a larger share of these 6 million color are outside the sRGB gamut. Anyway the logical expansion would be #RRRGGGBBB and 4,096 colors per channel is just insane. -- Alan Gresley http://css-3d.org/ http://css-class.com/
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Alan Gresley   Wed, 07 Sep 2011 15:22:21 +1000

www-style > September 2011 > 0000.html

Received on Wednesday, 7 September 2011 05:22:06 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: www-style@w3.org.

On 7/09/2011 1:28 PM, Alan Gresley wrote: > A calculator set to decimals (dec), will change the value 'FF' to '255' > when hexadecimals (hex) is selected. I have that back to front. It should be: A calculator set to hexadecimals (hex), will change the value 'FF' to '255' when decimals (hex) is selected. -- Alan Gresley http://css-3d.org/ http://css-class.com/
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Marat Tanalin   Fri, 09 Sep 2011 19:27:28 +0400

www-style > September 2011 > 0000.html

Received on Friday, 9 September 2011 15:28:18 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: ph.wittenbergh@l-c-n.com
Copied to: www-style@w3.org.

1. Well, if we need for both features, then both features should be probably added to CSS spec. One feature (shortening hex values) just should not be confused with another one (gray() function that has nothing to do with shortening hex values): they are solutions for separate tasks, not an alternatives at all. 2. Since we are (well, trying) developing interoperable CSS, then proprietary solutions does not matter (though even MS uses decimal in -ms-filter: "alpha(opacity=70)" property). In standard CSS, opacity is specified as decimal number, and future decisions for CSS should be consistent with ones already existing in standard CSS. 07.09.2011, 06:34, "Philippe Wittenbergh" <ph.wittenbergh@l-c-n.com>: > On Sep 7, 2011, at 4:26 AM, Marat Tanalin wrote: > >>  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). > > It may not be in _your_ interest, but personally I'm much more interested in having a gray() function than extending the hexadecimal notation. I suspect Tab is more interested in the the gray() function as well. But I don't live in his head to know… > > When discussing new proposals, the CSS WG should examine all options. imho. > >>  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. > > There are precedents for hexadecimal notation including opacity. > > Here is a code snippet from one of my stylesheets: > filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#801e5799', endColorstr='#7db9e8',GradientType=0 ); /* IE6-9 */ > > note the startColorstr value, equivalent to rgba(30,87,153,0.5) > > That is implemented by Microsoft. Inkscape also uses that notation, fwiw. > > (not arguing if it is good or bad to have such a notation in CSS - personally, I strikes me as very hard to read, but that is just me; I'm satisfied with rgba() and hsla()). > > Philippe > -- > Philippe Wittenbergh > http://l-c-n.com/
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Marat Tanalin   Fri, 09 Sep 2011 19:46:26 +0400

www-style > September 2011 > 0000.html

Received on Friday, 9 September 2011 15:47:00 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: pgaries@fastmail.us
Copied to: jackalmage@gmail.com, www-style@w3.org.

> Unfortunately, CSS is locked into the confusing |#RRGGBBAA| syntax since > backward-compatibility with programs that already support this syntax > was part of the rationale for its inclusion. What exact programs you are talking about? For example, in Photoshop, opacity and nontransparent hex color are separate properties that needs to be copied separately anyway. > Adding a full stop (i.e., ".") character as a separator within the > syntax would break that compatibility. It's unclear what compatibility you are talking about, but just in case: point in my proposed syntax is decimal point of full fractional number (from 0.0 to 1.0). Integer part of number is just removed since it's needed only for exactly one opacity value: 1.0. But for 100% opacity we don't need for opacity component at all. So we can safely remove integer part and elegantly use decimal point itself as a compact hex/alpha separator. 07.09.2011, 07:06, "Patrick Garies" <pgaries@fastmail.us>: > On 9/6/2011 2:26 PM, Marat Tanalin wrote: > >>  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.). > > Unfortunately, CSS is locked into the confusing |#RRGGBBAA| syntax since > backward-compatibility with programs that already support this syntax > was part of the rationale for its inclusion. I believe the idea is that > you'll be able to copy and paste such values directly into a style sheet. > > Adding a full stop (i.e., ".") character as a separator within the > syntax would break that compatibility.
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Marat Tanalin   Fri, 09 Sep 2011 20:10:08 +0400

www-style > September 2011 > 0000.html

Received on Friday, 9 September 2011 16:10:48 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: alan@css-class.com
Copied to: jackalmage@gmail.com, www-style@w3.org.

There is no need to tell us about abstract binary representation of data in general since we are all already know this. Saying "nature" as for RGB in CSS, I mean that existing widely-used 24-bit RGB color table includes 256 values for each RGB channel (8 bit per RGB-channel), and that's why hex representation can be used to specify colors. Unlike color, opacity is _multiplier_ and is not and should not be limited to 256 gradations. Currently, opacity in standard CSS is specified as decimal number (e.g., in "rgba()" function, in "opacity" property), and decisions as for new CSS-spec features should be consistent with existing ones. 07.09.2011, 07:28, "Alan Gresley" <alan@css-class.com>: > On 7/09/2011 5:26 AM, Marat Tanalin wrote: > >>  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_. > > This is an statement that has no foundation. There is 256 possible > values since all values must be transmitted as binary code which has > only two value (either 0 or 1). Computing has expanded this in multiples > like so: > >    2, 4, 8, 16, 32, 64, 128, 256, 512, 1024. > > A calculator set to decimals (dec), will change the value 'FF' to '255' > when hexadecimals (hex) is selected. > > RGB color space can not be said to be *by nature*. Please read about RGB > color space [1]. > >    | RGB is a convenient color model for computer graphics >    | because the human visual system works in a way that >    | is similar — though not quite identical — to an RGB >    | color space. > > As I know from personal experimentation, color and human perception of > it is far more mysterious than what is known in the mainstream science, > but is is far from the scope of this thread. > > 1. http://en.wikipedia.org/wiki/RGB_color_space > > -- > Alan Gresley > http://css-3d.org/ > http://css-class.com/
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Christoph Päper   Mon, 12 Sep 2011 16:00:15 +0200

www-style > September 2011 > 0000.html

Received on Monday, 12 September 2011 14:00:45 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: www-style@w3.org, www-style@w3.org.

Tab Atkins Jr.: > As for 1-digit grays, I no longer think they're a good idea. Me neither, although I would have been fine with them, had they existed in level 2.0 or earlier. I think they would fit nicely in a new module, though: CSS Preprocessing, a module not suitable for browsers. That would also have variables, constants, mixins, selector nesting and all that crazy stuff that’s just to mean on backwards compatibility or real-time rendering.
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Chris Nager   Tue, 29 Nov 2011 12:34:01 -0500

www-style > December 2011 > 0000.html

Received on Thursday, 1 December 2011 09:34:09 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: www-style@w3.org.

Hey Markus, I completely agree. I sent a tweet out about this a while back: https://twitter.com/#!/ChrisNager/status/83651049558253568 @ChrisNager: "As far as color hexcodes go in #css, I've always thought if #0cf works for #00ccff, shouldn't #f work for #ffffff and #a1 work for #a1a1a1?" Cheers! Chris Nager cnager@gmail.com
RE: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Brian Manthos   Thu, 1 Dec 2011 11:55:01 +0000

www-style > December 2011 > 0000.html

Received on Thursday, 1 December 2011 11:55:38 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: cnager@gmail.com, www-style@w3.org, www-style@w3.org.

Given that "#rgb" expands within channels (#rrggbb), why should "#mn" expand across channels (#mnmnmn)? From: Chris Nager [mailto:cnager@gmail.com] Sent: Tuesday, November 29, 2011 9:34 AM To: www-style@w3.org Subject: Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades) Hey Markus, I completely agree. I sent a tweet out about this a while back: https://twitter.com/#!/ChrisNager/status/83651049558253568 @ChrisNager: "As far as color hexcodes go in #css, I've always thought if #0cf works for #00ccff, shouldn't #f work for #ffffff and #a1 work for #a1a1a1?" Cheers! Chris Nager cnager@gmail.com<mailto:cnager@gmail.com>
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
David Chambers   Thu, 1 Dec 2011 10:09:47 -0800

www-style > December 2011 > 0000.html

Received on Thursday, 1 December 2011 18:10:27 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: brianman@microsoft.com
Copied to: cnager@gmail.com, www-style@w3.org, www-style@w3.org.

Brian Manthos <brianman@microsoft.com> wrote: Given that “#rgb” expands within channels (#rrggbb), why should “#mn” > expand across channels (#mnmnmn)? I don't see this as a problem. Since there's no sensible way to expand "#mn" within channels, why not have it expand in a different — importantly, *obviously* different — manner? David On 1 December 2011 03:55, Brian Manthos <brianman@microsoft.com> wrote: > Given that “#rgb” expands within channels (#rrggbb), why should “#mn” > expand across channels (#mnmnmn)?**** > > ** ** > > *From:* Chris Nager [mailto:cnager@gmail.com] > *Sent:* Tuesday, November 29, 2011 9:34 AM > *To:* www-style@w3.org > *Subject:* Re: [css] Proposal: making Shorthand Hex Colors even shorter > (16 grayscale shades)**** > > ** ** > > Hey Markus,**** > > ** ** > > I completely agree. I sent a tweet out about this a while back:**** > > https://twitter.com/#!/ChrisNager/status/83651049558253568**** > > ** ** > > @ChrisNager:**** > > "As far as color hexcodes go in #css, I've always thought if #0cf works > for #00ccff, shouldn't #f work for #ffffff and #a1 work for #a1a1a1?"**** > > ** ** > > Cheers!**** > > ** ** > > Chris Nager**** > > cnager@gmail.com**** >
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
"Tab Atkins Jr."   Thu, 1 Dec 2011 10:33:18 -0800

www-style > December 2011 > 0000.html

Received on Thursday, 1 December 2011 18:34:09 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: cnager@gmail.com
Copied to: www-style@w3.org.

On Tue, Nov 29, 2011 at 9:34 AM, Chris Nager <cnager@gmail.com> wrote: > Hey Markus, > I completely agree. I sent a tweet out about this a while back: > https://twitter.com/#!/ChrisNager/status/83651049558253568 > @ChrisNager: > "As far as color hexcodes go in #css, I've always thought if #0cf works for > #00ccff, shouldn't #f work for #ffffff and #a1 work for #a1a1a1?" As I argued in the thread that you are responding to (starting at <http://lists.w3.org/Archives/Public/www-style/2011Aug/0037.html>), there's not much benefit to allowing these. The 2-digit hex syntax saves 1 or 4 characters (depending on whether the two digits are the same), and since the saved characters are just repetition, it's worth even less than that. The 1-digit hex syntax saves 2 character, and again the savings are pure repetition. This is an extremely minimal benefit. Neither of these play well with the plans to add alpha to the 3- and 6-digit hex syntaxes. I argued in the thread that there may be sufficient value in adding a gray() function which accepts a number or percentage, like rgb(), because the characters savings is greater there. As well, it can handle alpha better, as a second parameter. ~TJ
RE: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Brian Manthos   Thu, 1 Dec 2011 18:46:27 +0000

www-style > December 2011 > 0000.html

Received on Thursday, 1 December 2011 18:47:08 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: david.chambers.05@gmail.com
Copied to: cnager@gmail.com, www-style@w3.org, www-style@w3.org.

In IE5, “#12” was treated as the same as “#120” IIRC. Cases like “#1234” also have interesting treatment. So, compatibility is one concern. I don’t have an opinion on what’s sensible or not about that treatment. But I do take issue with saying “there’s only one way to intepret #mn” when we have at least one decacde-old public implementation that proves otherwise. -Brian From: David Chambers [mailto:david.chambers.05@gmail.com] Sent: Thursday, December 01, 2011 10:10 AM To: Brian Manthos Cc: Chris Nager; www-style@w3.org Subject: Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades) Brian Manthos <brianman@microsoft.com<mailto:brianman@microsoft.com>> wrote: Given that “#rgb” expands within channels (#rrggbb), why should “#mn” expand across channels (#mnmnmn)? I don't see this as a problem. Since there's no sensible way to expand "#mn" within channels, why not have it expand in a different — importantly, obviously different — manner? David On 1 December 2011 03:55, Brian Manthos <brianman@microsoft.com<mailto:brianman@microsoft.com>> wrote: Given that “#rgb” expands within channels (#rrggbb), why should “#mn” expand across channels (#mnmnmn)? From: Chris Nager [mailto:cnager@gmail.com<mailto:cnager@gmail.com>] Sent: Tuesday, November 29, 2011 9:34 AM To: www-style@w3.org<mailto:www-style@w3.org> Subject: Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades) Hey Markus, I completely agree. I sent a tweet out about this a while back: https://twitter.com/#!/ChrisNager/status/83651049558253568 @ChrisNager: "As far as color hexcodes go in #css, I've always thought if #0cf works for #00ccff, shouldn't #f work for #ffffff and #a1 work for #a1a1a1?" Cheers! Chris Nager cnager@gmail.com<mailto:cnager@gmail.com>
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
"Tab Atkins Jr."   Thu, 1 Dec 2011 10:53:55 -0800

www-style > December 2011 > 0000.html

Received on Thursday, 1 December 2011 18:54:50 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: brianman@microsoft.com
Copied to: david.chambers.05@gmail.com, cnager@gmail.com, www-style@w3.org, www-style@w3.org.

On Thu, Dec 1, 2011 at 10:46 AM, Brian Manthos <brianman@microsoft.com> wrote: > In IE5, “#12” was treated as the same as “#120” IIRC.  Cases like “#1234” > also have interesting treatment. > > So, compatibility is one concern. Is this only in HTML color attributes like <body bgcolor>? Those are required now to use a different parsing algorithm than CSS anyway (I fixed WebKit to stop treating it like CSS). IE5 compat is probably the farthest thing from an average author's mind, as well. ^_^ ~TJ
RE: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Brian Manthos   Thu, 1 Dec 2011 19:15:04 +0000

www-style > December 2011 > 0000.html

Received on Thursday, 1 December 2011 19:15:52 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: david.chambers.05@gmail.com, cnager@gmail.com, www-style@w3.org, www-style@w3.org.

I think it predates IE5 by quite a bit, but any-who... My point was that there are multiple ways to interpret less than 3 hex digits (as well as 4 and 5), so I think it's a bit foolish to introduce an additional incompatibility for an arguably ambiguous representation. -----Original Message----- From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] Sent: Thursday, December 01, 2011 10:54 AM To: Brian Manthos Cc: David Chambers; Chris Nager; www-style@w3.org Subject: Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades) On Thu, Dec 1, 2011 at 10:46 AM, Brian Manthos <brianman@microsoft.com> wrote: > In IE5, “#12” was treated as the same as “#120” IIRC.  Cases like “#1234” > also have interesting treatment. > > So, compatibility is one concern. Is this only in HTML color attributes like <body bgcolor>? Those are required now to use a different parsing algorithm than CSS anyway (I fixed WebKit to stop treating it like CSS). IE5 compat is probably the farthest thing from an average author's mind, as well. ^_^ ~TJ
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
Lea Verou   Thu, 01 Dec 2011 20:50:45 -0800

www-style > December 2011 > 0000.html

Received on Friday, 2 December 2011 04:51:15 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: jackalmage@gmail.com
Copied to: cnager@gmail.com, www-style@w3.org.

My impression is that the latest efforts of the W3C is to standardize not only correct behavior, but also error handling. Since 1-2 digit hex codes are already on the web, maybe it would be a good idea to standardize their behavior, rather than letting browsers decide. Whether they should be *valid* though, that's another question. -- Lea Verou (http://lea.verou.me | @LeaVerou)
Re: [css] Proposal: making Shorthand Hex Colors even shorter (16 grayscale shades)
"Tab Atkins Jr."   Thu, 1 Dec 2011 20:59:43 -0800

www-style > December 2011 > 0000.html

Received on Friday, 2 December 2011 05:00:31 UTC

Show in list: by date • by thread • by subject • by author

Link to this message in this page.

Sent to: leaverou@gmail.com
Copied to: cnager@gmail.com, www-style@w3.org.

On Thu, Dec 1, 2011 at 8:50 PM, Lea Verou <leaverou@gmail.com> wrote: > My impression is that the latest efforts of the W3C is to standardize not > only correct behavior, but also error handling. > Since 1-2 digit hex codes are already on the web, maybe it would be a good > idea to standardize their behavior, rather than letting browsers decide. > > Whether they should be *valid* though, that's another question. The behavior in HTML presentational attributes is well-defined, and I know that FF and WebKit have identical behavior for them (IE behavior is similar, but not identical last time I checked). They've always been invalid in CSS, though, and no modern browser accepts them. So, they're pretty well standardized and interoperable at this point. Brian's point was just that there is more than one reasonable interpretation of what a 2-digit hex color means. ~TJ