W3C home > Mailing lists > Public > www-style@w3.org > June 2012

Re: [css4-color] Make the r/g/b components be <number> rather than <integer>?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 15 Jun 2012 11:41:29 -0700
Message-ID: <CAAWBYDCm5HYBJ+sv_=oCjfmt8aUR9zhjJL4UX5q591N4-4wLvA@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, www-style@w3.org
On Fri, Jun 15, 2012 at 11:24 AM, Rik Cabanier <cabanier@gmail.com> wrote:
> sRGB is a simplistic profile. It's gamma correction + a simple translate
> function. Clamping to [0..1] is part of the definition
> (see http://en.wikipedia.org/wiki/SRGB)
> I can see how this would make it tempting to just remove the clamp so you
> can get to XYZ that is outside of the regular gamut.
> The problem with this is:
> a. This is breaking the profile math.  Are all out of gamut colors possible
> or only a subsection?
> b. Colors with out of gamut colors will display different than they print
> c. What if we want to improve color on the web later on? sRGB used to make
> sense but current displays are capable of a wider gamut (ie Super OLED)
> which currently goes unused (or abused to show colors that are too vibrant).
> New displays will probably have table based profiles where negative input
> make no sense.
> I think point c is most important.

I'm not sure how any of this is relevant to either the original
discussion in this thread, or the tangent topic that has split off.

The rgb() function allows unrestricted integers (and percentages).
UAs may clamp the arguments to whatever gamut the output device
supports.  This might be [0-255], or it might be a larger range if
you're using a higher-gamut display or a printer. It could even be a
lower range on some printing devices.  So, this is all undefined by
CSS and up to the UA - it's a quality of implementation issue.

Received on Friday, 15 June 2012 18:42:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:00 UTC