- From: Patrick Garies <pgaries@fastmail.us>
- Date: Fri, 09 Apr 2010 00:03:36 -0500
- To: Alberto Lepe <dev@alepe.com>
- CC: www-style list <www-style@w3.org>
On 2010-04-06 2:49 AM, Alberto Lepe wrote: > Reading back your comments, It is pretty clear to me that you just > don't like #HEX annotation or you think it is too complex (at it > seems that you understand it). I don't when using it to pick a color. I prefer keywords in general, really. It's nice for picking gray out of thin air, mainly because |rgb()| wants me to specify the same number three times. > What do you mean by "most authors"? It sounds like you are > generalizing... Educated guess. I don't have a statistic, sorry. (I did, at least, intentionally qualify it with "likely" instead of making a statement of incontrovertible fact.) > I think it depends on the developer. For me, its easier to "guess" > the color in: #A5906A than rgb(165,144,106) or hsl(39%,36%,65%). Unless you're thinking directly in 0-F (without a 0-255 mental conversion), I don't see how this can be possible: #A5906A = 155/135/90. If you had to do that mental conversion, you could have avoided it with: rgb(155, 135, 90) I could always be missing something though. Feel free to explain your mental process. HSL is the easiest to write in when R,G, or B aren't dominant, but not as easy to read. I was expecting a yellow-orange color (which is true when fully saturated), but it instead ended up being a tan color due to the low saturation. > I don' have to convert any value or use a calculator, as I'm used to > see colors in 0-255 range combinations rather than 0-100. Isn't this an argument in favor of using the |rgb()| notation? Hex uses the 0-F (0-16) range. > Hey! I'm here! Yup, I saw that. I was merely relaying the "objective" arguments requested. > The implementation would take few hours (plus some more for > testing). I'm sure of it, as transparency feature is already > implemented. This is just matter of adding few lines to the parser > and call the transparency function. As most of the transparency in C > is generally handled in 0-255 (1 byte) it could be even faster than > converting rgb() values into C. I haven't look at the browsers code > but if you want I can post here the required changes for Webkit or > Gecko for this feature. I personally would be glad to help its > implementation. Point taken on the implementation part. I don't think you addressed the time-saving part, but that would largely be mitigated if this made it into IE9 (which already doesn't support HSLA and RGBA). The other vendors can catch up fast. However, if you want to support a maximum of older browsers, you'll still be using HSLA/RGBA. > As you can see in the previous links I posted, #rrggbbaa explanation > is not that complicated. It's still more complicated than the alternatives. One more thing is one more piece of cruft. I guess people already have to explain this though due to #RGB, so I'll concede this. > All depends on the css-color module editors. This mainly was about those adamant that this make it into CSS3. It seems that the majority prefers CSS4, so I guess this is a moot point. > Sorry buddy, but it seems that you haven't read the threat in > detail. We have presented not only one advantage of adding this > feature against the actual rgba() annotation. If you think #rrggbbaa > is to duplicate rgba() , then hsla() is also a duplicated feature of > rgba(). See my reply to Brad. I'll concede this point.
Received on Friday, 9 April 2010 05:04:16 UTC