W3C home > Mailing lists > Public > public-html@w3.org > March 2010

Re: Color Management in HTML5?

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 06 Mar 2010 18:19:35 -0800
Cc: "L. David Baron" <dbaron@dbaron.org>, "public-html@w3.org" <public-html@w3.org>
Message-id: <95A94566-F20D-4168-A21F-B81A117A5CF4@apple.com>
To: Leonard Rosenthol <lrosenth@adobe.com>

On Mar 6, 2010, at 5:53 PM, Leonard Rosenthol wrote:

> _IF_ the HTML5 specification was only a file format description,  
> then I would be in complete agreement with you – that color  
> management is outside of scope.  BUT since the spec clearly  
> stipulate quite exacting behavior (including algorithm  
> implementation requirements) for many aspects of the implementation  
> of a UA, then I have to disagree (strongly).   What makes the  
> details of URL decoding any more important to be consistent in the  
> UA than that of color management?

We moved the details of URL parsing out of the spec precisely because  
of concerns about overriding other specs. I expect the HTML WG would  
be similarly concerned about redefining CSS or SVG requirements. Just  
because HTML5 is currently the most visible spec, does not mean we  
should put everything in it. Rather, the HTM WG has been moving in the  
other direction; we have been breaking out pieces of the spec for  
greater modularity.

> To your points.
> CSS only applies to some elements on the page.  It does not apply to  
> images or video, thus even if we were to accept that CSS dictates  
> those elements that it impacts, there would still be limitations in  
> the others.

Indeed, but CSS colors are the ones most directly related to HTML as  
such, rather than to linked media. CSS should be the starting point.  
For linked media (images and videos) we may need some sort of cross- 
W3C spec that defines how it is done. Note that images and videos can  
be linked from many W3C languages, not just HTML. CSS and SVG can both  
link to images, and in the latter case videos.

> > Typically, W3C and other specs seem to agree that the default  
> colorspace is sRGB, though that is generally not implemented
> That would seem to be a problem then, would you not agree?

Yes, it's a problem. But moving color management requirements from CSS  
to HTML is not the critical part of the solution. To be totally clear  
on this: Safari is currently directly violating the requirements of  
the CSS spec to treat all colors as sRGB. And CSS 2.1 is a spec where  
we strive for total conformance when possible. This violation is  
because of technical issues, not because it isn't mentioned in enough  

I already mentioned the two blockers for us to do it in Safari: (a)  
figure out how to do it with acceptable performance; and (b) find a  
way for plugins, most notably Adobe Flash, to participate in color  
management. Basically we don't want to slow down the Web, and we don't  
want pages that use Flash to look ugly all of a sudden. In our testing  
we found that a lot of pages use Flash content that's meant to match  
seamlessly with a background color or image. (A similar issue may  
apply to Silverlight, but it's not used on nearly as many pages; and  
other plugins do not seem to be used for content that is seamlessly  
matched to the embedding page.)

Incidentally, if there's any way you can put issue (b) on Adobe's  
radar, that would be great.

> As you know, the documentation for image formats(!) is just that –  
> the file format.  The documentation for JPEG, PNG, etc. doesn’t  
> concern itself with rendering in any way – only the encoding and  
> decoding of the pixel data (and associated pieces).   As such, those  
> documents won’t be relevant here.  However, if you look at the  
> current section on <img> (http://www.w3.org/TR/html5/text-level-semantics.html#the-img-element 
> ) it talks about various things that a UA should do with the image  
> and its data including some basics on how to “present it”.  Seems  
> like a logical addition here for CM.

Are you sure about this? The PNG spec for example says: "PNG decoders  
are strongly encouraged to use this information, plus information  
about the display system, in order to present the image to the viewer  
in a way that reproduces as closely as possible what the image's  
original author saw." <http://www.w3.org/TR/PNG/#4Concepts.ColourSpaces>

(Note that all HTML5 rendering requirements are also "encourage"  
statements rather than formal conformance requirements.)

So it seems like PNG is covered; I have not checked other image format  
specs, but it seems like they certainly *could* have this type of  
statement, even if they do not currently.

>  If the correct procedure is the filing of bug reports, then I will  
> report that back to the ICC and ask them to file the reports so that  
> the various issues can be tracked and processed accordingly.   
> However, I wonder how the filing of reports will enable discussion  
> by the committee on the topic at hand, since it seems like a fairly  
> significant and far-reaching one.

If your initial goal is just discussion, and not necessarily a spec  
change, then the right thing to do would be to start a conversation on  
public-html, as you have done already. Feel free to continue this  
thread or bring up other topics.


> Leonard
> From: Maciej Stachowiak [mailto:mjs@apple.com]
> Sent: Sunday, March 07, 2010 10:31 AM
> To: Leonard Rosenthol
> Cc: L. David Baron; public-html@w3.org
> Subject: Re: Color Management in HTML5?
> On Mar 6, 2010, at 5:29 AM, Leonard Rosenthol wrote:
> And this discussion is EXACTLY why the ICC wants to get involved.
> As has been stated many times, the HTML5 spec is not only about the  
> language & grammar BUT is also a set of requirements for UAs to  
> ensure that all browsers render the same page in the same way.  As  
> such, that includes not only that the right image goes in the right  
> place on the page BUT that its colors are correct and match the  
> colors shown in other browsers.
> Nonetheless, most color management issues are not HTML issues. They  
> are mostly an issue for CSS. I would say the most fruitful avenue  
> for the ICC would be to coordinate with the CSS WG.
> To accomplish this will mean that rules for color management within  
> a browser need to be stipulated in the standard itself.   For  
> example, the following (non-complete) list of questions need to  
> answered…
> ·         What is the “default colorspace”?
> This is not an HTML issue. It's an issue for individual specs that  
> deal with color. Typically, W3C and other specs seem to agree that  
> the default colorspace is sRGB, though that is generally not  
> implemented (except perhaps on Windows where it's typical to assume  
> that device color is approximately sRGB.)
> ·         How to handle embedded profiles in images (and possibly  
> even how to look for them)
> This is an issue for image format specs, or perhaps for a spec about  
> how images should work on the Web.
> ·         How to handle CSS colors
> That's an issue for the CSS spec.
> ·         How to handle SVG colors (which extend CSS a bit)
> That's an issue for the SVG spec to the extent that it does not just  
> defer to CSS.
> ·         Does Canvas need to be extended to deal with richer color  
> (ala SVG)?
> My interpretation would be that Canvas uses CSS colors and therefore  
> should follow CSS rules about color. If the spec doesn't clearly say  
> that, then that's a bug.
> ·         Does video need to be extended?
> Would the correct process forward then be for the ICC to draft one  
> or more formal & comprehensive Change Proposals (which will most  
> likely be fairly widespread throughout one or more of the documents  
> currently being authored)?
> The correct first step to request a spec change for HTML5 would be  
> to file a bug. A Change Proposal would be out of order.
> In all fairness I should warn you that it's likely the bug would be  
> rejected as out of scope for HTML.
> Is it possible that some form of decision could be made to determine  
> the “feelings” of the committee ahead of time?  I would hate to  
> recommend to someone at the ICC that they invest the (huge) time  
> necessary to draft such a document , only then to have it not  
> approved.  Is there some sort of “pre-vote” or something that could  
> be used in this case?
> Even without a "pre-vote", a Change Proposal would be out of order  
> without following the earlier steps in the process. And in any case,  
> probably the best venue to make proposals would be the CSS WG, not  
> the HTML WG.
> Regards,
> Maciej
> Leonard
> From: Maciej Stachowiak [mailto:mjs@apple.com]
> Sent: Saturday, March 06, 2010 7:15 AM
> To: L. David Baron
> Cc: Leonard Rosenthol; public-html@w3.org
> Subject: Re: Color Management in HTML5?
> On Mar 5, 2010, at 2:04 PM, L. David Baron wrote:
> On Friday 2010-03-05 00:08 -0800, Maciej Stachowiak wrote:
> Just to report on what Safari does: we colormatch images that are
> tagged with an explicit colorspace, but we treat CSS colors and
> colors in untagged images as being in the device color space
> (instead of treating as sRGB). This seems to give a good balance
> between performance for the common case and color-correctness for
> cases where precise color is desired.
> Gecko does this too (I think starting in Firefox 3.5?), but we got
> quite a few complaints about it, and I'd like to change it.
> It has the significant disadvantage that the relationships between
> colors in different parts of the same page can be different
> depending on the device (when a page has both tagged images and
> other colors).
> I think we should move towards treating CSS colors (and untagged
> images) as sRGB, as CSS1, CSS2.1, and css3-color require.
> Long-term, we would like to do this in Safari (treat CSS colors and  
> untagged images as sRGB). In our attempts so far, there have been  
> two blockers:
> 1) Our attempts to do this so far have resulted in significant  
> performance regressions. We're still working on a way to do this  
> with good enough performance.
> 2) We have no way to get plugins to participate in colormatching. We  
> need additions to NPAPI to tell plugins whether to use device color  
> or sRGB, and we need plugins to adopt them. This is especially  
> critical for Adobe Flash, since there are pages that try to match  
> static background colors or background images to Flash. We've had  
> some discussions on this.
> Regards,
> Maciej

Received on Sunday, 7 March 2010 02:20:11 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:13 UTC