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

Christoph Päper wrote:
> Dear CSS WG,
> 
> I know it is pretty much too late and I have asked this before¹---for I 
> am really not happy about this part of the specification at all---, but 
> what is the rationale for not allowing percentage values for 'alpha'?
> After all the current allowed value range of 0.0--1.0, which was for 
> some reason blindly inherited from SVG and there from unquestioned 
> graphic designer tradition, is just a percentage value in disguise.
> Is the sole reason that this percentage value would not refer to some 
> value of the parent?

    Agreed. "rgba(255,0,0,1)" and "rgba(100%,0%,0%,1)" are idiotic. You 
should allow the same units for every value. Does anyone honestly thing 
RGB channels are stored as 8-bit integers while alpha is stored as 
floating point?

    Then again, integer values don't make much sense for the "opacity" 
property...

> Furthermore, is it really wise to not use 'deg'---a unit already
> introduced in CSS 2.0, although only used with later removed aural 
> properties there---in a value that is indeed an angle, namely the _h_ue 
> in 'hsl()' and 'hsla()'?
> At least /allow/ the unit!

    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.

> Maybe the pseudo-functions for color calculation ('rgb()', 'rgba()', 
> 'hsl()' and 'hsla()') could be thought over once again, in a way that 
> allows *any* of their parameters to be *any* of these:
> 
>   - angular:
>     · degree:   'deg'  ("100%" = "360deg"),
>     · gon/grad: 'grad' ("100%" = "400grad"),
>     · radian:   'rad'  ("100%" ~= "6.283rad");

    No. Most people do not think of color in terms of angular units. I 
might entertain it just for the hue value, but not for anything else.

>   - percentage ('%');
>   - integer

    Sure.

>     and, perhaps, just for
>     compatibility with implementations of the current draft
>   - 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.

    Thought: "opacity" should support percents and floats, while rgba() 
would support percents, floats and integers? Not consistent, but more 
intuitive. Besides, opacity and the alpha channel are separate entities.

> Of course nobody is using angular "green" values (AFAIK), but the
> conversion is simple and one certainly could make up a visual model, in
> which a color is representated by three angular values for red, green
> and blue (or hue, saturation, luminance).

    What would "rgba(360deg,360deg,360deg,360deg)" be? White? 
Transparent black?

> There also seems to be little reason not to allow alpha values in the 
> short and long hexadecimal format, they would just have to gain a digit:
> #0000--#FFFF and #00000000--#FFFFFFFF. After all, from my experience, 
> this is the most popular form for specifying colors out there in 
> stylesheets. I will not go as far as suggesting, that something like 
> "rgb(#0, #F, #0F)" (= "#00FF0F" = "rgb(0, 255, 15)") should be allowed.

    Okay, sounds fine. Or perhaps we could do something to make it a bit 
more clear like "##FFFFFFFF" or "#FFFFFF-FF".

> The only (probably unresolvable) problems I see is 
> with pioneering implementaions, which treat any unit-less hue as a 
> degree, and alpha values of '1' as '1.0' = '255' ('0' == '0.0'). That 
> you get from inconsistency, you cannot extend/correct later easily.

    I can kinda see their reasoning for having floats for alpha, since 
integers aren't intuitive for opacity, and allowing multiple units for 
alpha in rgba() would cause confusion about what units you can use. Then 
again, if they allow all values for opacity, and just accept that 
integers, being counterintuitive for opacity, are going to be little 
used, then we'd probably be fine.

    There's still the backwards compatibility problem in that "1" can be 
"1.0" in the current spec. 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().

Received on Wednesday, 13 July 2005 16:54:09 UTC