- 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