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

Re: [css4-color] unclamped values for RGB

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 15 Jun 2012 12:24:51 -0700
Message-ID: <CAAWBYDA0eXLG92nzyaFsd8SbZrqPYOTO_837i8NeF-gvEFHzGA@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: www-style list <www-style@w3.org>
On Fri, Jun 15, 2012 at 12:07 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> currently the CSS color allows color values larger than 1 and smaller than 0
> (see the bottom section
> of http://www.w3.org/TR/CSS21/syndata.html#value-def-color). I'm unsure if
> anyone has actually implemented this.
> The spec currently defines that all non-image colors are defined in sRGB
> which 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)
> 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 unclamped input
> makes no sense.
> I think this feature should be dropped and replaced with something that is
> colorimetrically correct. This could be Lab or the ability to specify what
> profile the author intends to use (or both :-0)

The intention (possibly not properly captured in the draft) is that
the rgb() function specifies a color in an unclamped sRGB space.  The
browser can then clamp the components to restrict the color to the
gamut of the output device.

Received on Friday, 15 June 2012 19:25:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:35:11 UTC