- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Thu, 14 Jul 2005 08:01:26 -0400
- To: Laurens Holst <lholst@students.cs.uu.nl>
- CC: www-style@w3.org
Laurens Holst wrote: > Matthew Raymond wrote: >> Okay, sounds fine. Or perhaps we could do something to make it a >>bit more clear like "##FFFFFFFF" or "#FFFFFF-FF". > > Don’t see why. Red, green and blue aren’t distinguished from another > either, why should the opacity value be different. And the ## seems to > unnecessarily complicate things. Neither #FFFFFFFF nor the shorthand > #FFFF will conflict with anything else. It really doesn't matter to me. I was just offering an alternative in case the #FFFFFFFF and #FFFF formats met with resistance. >> 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(). > > Personally, I’d prefer 0...255, 0%...100% and 0.0...1.0 to apply to both > the rgb values and the alpha channel. That makes it consistent, and I > like the thought of specifying colour values in the 0-1 range, although > in practice few people will probably use that. I don't mind floating points either. It's sort of OpenGL-like to me. My only concern is how to deal with the "1" vs. "1.0", since the spec actually uses "1" as the alpha value, not "1.0". Therefore, anything based on the current CR will treat 1 as opaque, regardless if whether it's an integer or a float. Also, if people have already used the current CR as reference, there may already be pages out there that use "1" as meaning fully opaque. Still, if we're going to have non-float units, then floats without decimals ("0" and "1") are toast--Hey!--Wait a second... rgb(i,j,k,0.0) = transparent rgb(i,j,k,1.0) = rgb(i,j,k) Nevermind. Probably no one is going to use those values anyway.
Received on Thursday, 14 July 2005 12:01:38 UTC