W3C home > Mailing lists > Public > www-style@w3.org > July 2008

Re: [css3-color] New last call for comments on CSS Color

From: Chris Murphy <lists@colorremedies.com>
Date: Tue, 22 Jul 2008 07:16:44 -0400
Cc: W3C style mailing list <www-style@w3.org>
Message-Id: <C254544D-A84C-4A61-80AF-A1612BD359C4@colorremedies.com>
To: Dave Singer <singer@apple.com>

I agree that stating colors are sRGB is sufficient. Everything else is  
either confusing or obvious.

Chris Murphy

On Jul 22, 2008, at 3:57 AM, Dave Singer wrote:

>
> some quick personal comments...
>
>
> Isn't it enough to say that all colors are in the sRGB color space?  
> Isn't it a tautology to say that they should be correctly displayed  
> (e.g. an ICC sRGB profile associated with them, and then they should  
> be correctly converted to the display color space)?  It feels a bit  
> like saying that straight lines should appear straight on the  
> display...but at most, 3.1.1 should say basically like the sentence  
> above, and not go into details of how one displays sRGB values,  
> gamma correction, out-of-gamut color handling, etc.
>
> Is the HSL full-range (0-255 luminance) or video-range (16-235  
> luminance)?  This makes a BIG difference.
>
>
> At 0:31  -0400 22/07/08, Chris Murphy wrote:
>> I'm not sure what you mean by "handling out-of range or invalid  
>> values." Do you mean a JPEG or text that somehow has an encoded  
>> value for red greater than 255? I don't see how that happens in an  
>> 8bpc world. There simply isn't a place holder for a value greater  
>> than 100%.
>>
>> But OK, if that can happen (?), then yes instead of the browser not  
>> displaying the image or content, or crashing or otherwise dramatic,  
>> fine just say anything higher than 100% is only 100% and proceed  
>> normally. But I would not call this gamut mapping or clipping, this  
>> is error correction in reading the page document or image data.
>>
>> I see in the example RGB 300,0,0. Umm, 300 levels don't exist in  
>> 8bpc. 110%? Doesn't exist. To me this implies floating point where  
>> values can be greater than 100% and less than 0%.
>>
>> That sRGB 255,0,0 may be out of gamut for my display, but how is  
>> this even knowable? You send the color to a CMS and ask it "is this  
>> out of gamut or not?" It can be done, but why bother? Just send the  
>> value to the CMS and say "display this" and it does the best job it  
>> can. Whether it's in or out of gamut doesn't, in my view, need to  
>> enter into the equation. The gamut check is a feature in Photoshop,  
>> but it's not particularly useful in my view, so I guess I'm just  
>> confounded why in and out of gamut colors is even a relevant issue  
>> for the developer of a web browser. Tag the data, let the CMS do  
>> the rest.
>>
>> Chris Murphy
>>
>>
>>
>> On Jul 21, 2008, at 11:59 PM, L. David Baron wrote:
>>
>>> On Monday 2008-07-21 23:47 -0400, Chris Murphy wrote:
>>>> That whole paragraph.
>>>
>>> So the normal behavior in CSS for handling out-of-range or invalid
>>> values is to treat them as parse errors.  Since device gamuts vary,
>>> we don't want to do that here.  So I think the spec needs to say
>>> something so that it's clear that the colors specified should
>>> somehow be mapped into the device gamut rather than dropped.
>>>
>>> Is there a more general term than "mapped" that you would prefer?
>>>
>>> -David
>>>
>>> --
>>> L. David Baron                                 http://dbaron.org/
>>> Mozilla Corporation                       http://www.mozilla.com/
>
>
> -- 
> David Singer
> Apple/QuickTime
>
Received on Tuesday, 22 July 2008 11:36:40 GMT

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