Re: [css3-color] ICC implementation

Hi Bert,

Thanks for the informative response. Please indulge me further.

Where I lose you entirely, is that ICC color profile and intent  
support was in a May 14 2003 Candidate Recommendation. That's five  
years ago that it had made it at least that far. So how did it make it  
that far given it had not been implemented?

And now that much of what is desperately needed has been implemented,  
albeit not enabled yet by default, in two major web browsers, color  
management is being pulled from the spec?

And then also that there has been no implementation of gamma  
correction, and still there is no implementation of gamma (only)  
correction, Section 3.1.1 which remains in the spec?

Gamma correction has been standardized now TWICE even though it has  
not been implemented. And color management which is now implemented  
(albeit not by default and not exactly as originally proposed for  
CSS3) cannot go into the spec? Seems backwards to me.

Now, as the spec was written, I have just two (major) problems.

1.  with the rendering-intent property "auto" (default) behavior. It  
causes the browser to defer to the intent flag in the embedded ICC  
profile. This is unreliable. The spec needs to specify an intent,  
that's all. No options. And it needs to specify an intent anyway  
because most images do not have embedded profiles, therefore there is  
no intent flag.

A future spec could allow explicit ways for content creators to  
override that, and specify another intent on a per object basis.

2. with the color-profile property value set to anything except auto.  
When set to anything other than auto, the web browser is compelled to  
ignore all embedded profiles, which is a color management heresy. This  
is only bad, there is no good reason for doing this, and it amounts to  
a kind of data loss and sabotage of the original intent of the images  
with embedded profiles.  So again, the spec needs to specify just the  
auto behavior, that's all. No options.

This all seems to be rather straightforward. It doesn't require  
content creators to do anything differently than they are now. The  
entire burden is on the web browser and that is all but wrapped up in  
Firefox and Safari (flip the switches for default).

As you point out SVG is color managed, and now so is Flash 10. I don't  
see why CSS3 should be relegated to effectively saying that monitor  
RGB is acceptable. If cyan is a close enough approximation to blue, in  
the view of the W3C, then OK I will relent. Because that is the  
difference between quite a large percentage of LCD blue compared to  
sRGB blue.

Also IE Mac did have an option to use ColorSync, it wasn't on by  
default. If checked it assumed untagged images were sRGB. I don't  
recall if other content was color managed.


Chris Murphy




On Jul 10, 2008, at 8:50 AM, Bert Bos wrote:

>
> On Wednesday 09 July 2008 05:26, Chris Murphy wrote:
>> Hi list,
>>
>> I've just learned of some changes basically pulling planned ICC
>> profile and rendering intent support for CSS3. Considering the recent
>> work and achievement with Firefox and Safari web browsers in this
>> regard, I find this a disappointing.
>>
>> Considering that:
>>
>> 1. display technologies are diverging from sRGB, in the high-end
>> photo use where gamuts are substantially exceeding that of sRGB, and
>> in the laptop arena which has exploded in numbers where gamuts are
>> not only smaller than sRGB but have variably shaped gamuts; and
>>
>> 2. that CSS3 has been in the works for almost a decade and will
>> likely be around for a very long time as CSS2 has been and will
>> continue to be around for a long time;
>>
>> I think the w3c needs to join the 21st century in recognizing the
>> inherent issues with respect to content creation and display on
>> myriad devices and display technologies, instead of looking backwards
>> (i.e. section 3.1.1 on gamma correction).
>
> You're preaching to the choir. Device-independence was already a  
> goal of
> W3C (and of CSS) when most people still thought that "Web" was another
> word for "Mosaic." But W3C also has another goal: making standards  
> that
> work in practice.
>
> There were demands for reliable color rendering already back in 1996
> (from online shops, e.g.) and the authors of CSS tried to convince
> implementers to support color profiles even then. But the implementers
> (which basically meant Netscape, in those days) decided it was too
> difficult and wouldn't bring them any money. We made them promise,  
> as a
> compromise, to at least compensate the gamma on different platforms,
> but in the end they didn't keep their promise. (IE on Mac may have  
> done
> it, but I think that was the only one.)
>
> We did manage to reach consensus on sRGB (basically because it  
> required
> no implementation effort on most platforms). At the time, we had to
> work off early drafts of sRGB that people gave us, and we had trouble
> finding anything to put in the bibliography section of CSS, but it
> turned out the right thing to do.
>
> We have made some progress since then, however. SVG includes color
> profiles with rendering intent and although we again failed to put
> color profiles in CSS, they are at least mentioned now. (And you can
> include SVG from within CSS.)
>
> Note that sRGB is not a gamut for CSS. CSS only uses it as a  
> "coordinate
> system" for colors. CSS can specify every color; it is the device that
> CSS is rendered on that has a gamut. However, because of the way sRGB
> is defined, some colors may require unintuitive notations, such as
> negative numbers: rgb(0, 0, -0.1), or numbers greater than 1: rgb(0,  
> 0,
> 1.1).
>
> The reason color profiles are not in CSS is not that they are a bad
> idea, the reason is that there too many other good ideas competing for
> limited resources. It makes no sense (and the W3C process even  
> forbids)
> to standardize a feature that has not been implemented. To get color
> profiles into CSS requires either making an implementation yourself,  
> or
> convincing others who make implementations that this has higher
> priority than, say, columns, page numbers, vertical text, drop  
> shadows,
> downloadable fonts, hyphenation, leaders, transition effects, resizing
> backgrounds, attribute selectors, Greek list counters, grid layout or
> vh/vw units...
>
>
>
> Bert
> -- 
>  Bert Bos                                ( W 3 C ) http://www.w3.org/
>  http://www.w3.org/people/bos                               W3C/ERCIM
>  bert@w3.org                             2004 Rt des Lucioles / BP 93
>  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
>

Received on Thursday, 10 July 2008 15:03:40 UTC