W3C home > Mailing lists > Public > www-style@w3.org > July 2005

Re: [CSS3 Color] Percentages in Alpha Value etc.

From: Christoph Päper <christoph.paeper@tu-clausthal.de>
Date: Thu, 14 Jul 2005 19:03:04 +0200
Message-ID: <42D69AC8.5010701@tu-clausthal.de>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:19 UTC