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

Re: [CSS3 Colors] HSL colors, hue and allowed values, [CSS3 gcpm] CMYK colors and allowed values.

From: Chris Murphy <lists@colorremedies.com>
Date: Thu, 30 Jul 2009 10:37:59 -0400
Cc: Ludger Buenger <ludger.buenger@realobjects.com>
Message-Id: <96621DF7-3A7D-4343-BB55-28055E03CD3C@colorremedies.com>
To: W3C style mailing list <www-style@w3.org>
On Jul 30, 2009, at 4:13 AM, Ludger Buenger wrote:
> Take PDF/X-1a then. Same game but requires CMYK.
> You asked for an application.

Using that logic, CSS3 should support YCbCr because that is a required  
color space for JFIF/JPEG files.

Just because a color space is required by an image file format does  
not mean CSS must support that same color space to correctly encode  
color. The point being, why exactly should we care about how color is  
encoded? If a designer wants to work in CMYK, there is absolutely  
nothing preventing an application from presenting CMYK controls for  
defining color in whatever units desired. How that color is encoded in  
CSS has nothing to do with how the user can define color.

I still do not get the rationale for including CMYK support in CSS3,  
which implies there is an actual need to encode color with four  
discreet channels, one of which is redundant, implying the *final*  
destination for the CSS content itself is a mechanical reproduction  
process that uses ink on some kind of substrate. CSS isn't a command  
and control language. It should be up to the application that  
processes it into the language/format for output to

And in particular there is no case to be made for subjecting the  
planet to a page description language that is incapable of  
unambiguously defining color.

Chris Murphy
Color Remedies (TM)
New York, NY
Co-author "Real World Color Management, 2nd Ed"
Received on Thursday, 30 July 2009 14:38:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:37 UTC