W3C home > Mailing lists > Public > www-style@w3.org > February 2003

Re: CSS3 module: Color

From: Jonathan Stanley <jon@asciigrackle.eclipse.co.uk>
Date: Thu, 27 Feb 2003 07:51:29 -0500 (EST)
Message-ID: <049501c2de5e$f3150b90$702698d5@meugh>
To: "Chris Lilley" <chris@w3.org>
Cc: <www-style@w3.org>




----- Original Message ----- 
From: "Chris Lilley" <chris@w3.org>
To: "Bert Bos" <Bert.Bos@sophia.inria.fr>; <www-style-request@w3.org>;
"Jonathan Stanley" <jon@asciigrackle.eclipse.co.uk>
Cc: <www-style@w3.org>
Sent: Thursday, February 27, 2003 10:59 AM
Subject: Re: CSS3 module: Color


> On Thursday, February 27, 2003, 3:58:40 AM, Jonathan wrote:
>
>
>
>
> JS> Hi
>
> JS> Had a good little read from a users point of view, and quite excited
about
> JS> some of the things it'll bring (though how soon browsers support it is
a
> JS> slightly different matter :( )
>
> JS> Anyway, I see within the RGB(A) model, the valid ranges are defined in
> JS> section 4.2.2:
>
> JS> ---
> JS> em { color: rgb(255,0,0) }      /* integer range 0 - 255 */
> JS> em { color: rgba(255,0,0,1)     /* the same, with explicit opacity of
1 */
> JS> em { color: rgb(100%,0%,0%) }   /* float range 0.0% - 100.0% */
> JS> em { color: rgba(100%,0%,0%,1) } /* the same, with explicit opacity of
1 */
> JS> ---
>
> JS> If R, G and B can have values from 0.0% to 100.0% percent, then why is
A,
> JS> alpha, so limited within the bounds of 0.0 to 1.0, equivanlent to 0%
to 100%
> JS> in 10% steps.
>
> The precision is not limited to 10% steps. It can be any value, for
> example 0.123456

Right I see, far greater prescision than I think anyone would need, however,
I assumed the values were indeed 0.0 to 1.0, with 1 decimal place accuracy,
as that's what secion 3.2 implied with regards to opacity:
---
Computed value: The same as the specified value after clipping the
<alphavalue> to the range [0.0,1.0].
---
If it is, say to 6 decimal places, then perhaps notating accepted value as:
0.000000 to 1.000000?

>
> JS> There also isn't bounds for values when using the HSL(A) colour model,
other
> JS> than definition of hue, that 0 = 360, no definition of how negative
values
> JS> are handled, eg:
>
> JS> * { color: hsl(-240, 100%, 50%) }
>
> JS> ... or going round "more than once" in the colour wheel:
>
> JS> * { color: hsl(840, 100%, 50%) }
>
> I agree that this aspect should be more clearly specified. It seems
> obvious that hue is a wraparound value but for consistency of
> implementation, it should be explicitly stated.

Thanks :)

It working correctly as a wraparound value would be good for scripting (no
need to check "out of bound" values in runtime) and better for accessibilty
(ie, how to clip value, render as black/white/transparent/etc)

>
> JS> Then the "currentColor" property which is treated as "inherit" at
parse
> JS> time, would be better hypenated? That is: "current-color"
>
> There is an issue with hyphens in names, to do with scripting. In
> response to a request from the DOm working group, SVG WG changed all
> the names that it had to camelCase, except for existing CSS names that
> we did not control.
>
> Since the currentColor value comes from SVG, that is why it uses
> camelCase.

Right I see, would this also mean existing CSS1/CSS2 hyphenated names become
depreciated in this/future versions of the CSS specification?
>
> It has been in SVG since 1999 and is implemented in 15 or so different
> implementations.
>
> Thanks for your comments.
>
> -- 
>  Chris                            mailto:chris@w3.org
>
>

Regards

Jonathan Stanley
Received on Thursday, 27 February 2003 12:21:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:20 GMT