- From: Christoph Päper <christoph.paeper@tu-clausthal.de>
- Date: Thu, 14 Jul 2005 19:03:04 +0200
- To: www-style@w3.org
Matthew Raymond: > Christoph Päper wrote: > Then again, integer values don't make much sense for the "opacity" > property... Not more or less than inside 'rgb()'. > Degrees really only make sense for hue, since all other values are > non-circular. Therefore, it's just easier to drop degrees than to just > support it for hue. You effectively ruin the possibility of later allowing integer or float values then. It is really, really bad style to omit units (despite percents and degrees being not "true" units). > Most people do not think of color in terms of angular units. Most people do not think of color in terms of any unit. ;) CNS or <http://lists.w3.org/Archives/Public/www-style/2002May/0201.html> would have been nice for that reason. >> - float (0.0--1.0). > > Well, there's are problems with float. For example, is "1" supposed > to be an integer "1" or the float "1.0"? Still, it's not to hard to > conceptually understand that the period (".") changes the units. The period is the distinctive feature I had in mind, too, but I suppose existing implementations are treating "1" and "1.0" alike. That is a problem. We would not have this mess, if percentages had been used in the first place. Although it should have happened a while ago, if the expected behavior is not (re)defined now, it never can. What about other color pseudo-functions that might be added in a future level of CSS? > What would "rgba(360deg,360deg,360deg,360deg)" be? White? Transparent > black? The same as "rgba(0deg, 0deg, 0deg, 0deg)" or "rgba(0, 0, 0, 0)", I suppose. The maximum of angular values would be 360°·n - 1°. Okay, it is not intuitive, but imagine four dials or clock-like gauges displaying the values. > Or perhaps we could do something to make it a bit > more clear like "##FFFFFFFF" or "#FFFFFF-FF". No, inconsistent. I assume the WG did not include this, because of typos: #FFF and #FFFFFF are easily dinstinguished and two, four, five or seven digits are always typos that yield no color, but with #FFFF (and #FFFFFFFF) possible, the short forms (three or four digits) could be typos of each other. Five and seven digits staid always being typos, though. > Perhaps we'd be better off dropping float and making the ranges for > alpha 0-255 and 0%-100%, just like the values in rgb(). That would be fine with me, but apparently it is a *tradition* to have alpha values in the range 0.0--1.0. Remember, traditions are always right and must not be questioned, beware changed. They brought us X11^WSVG color names, too (with each gr[ae]y value twice, but still no 'colour' property). Still, I could tolerate floats for 'alpha-value', if I was /allowed/ to use the more consistent '%'. The way it is now, is just stupid.
Received on Thursday, 14 July 2005 17:03:10 UTC