Re: [css-color] Doubts on how we handle device-cmyk() and similar things

On Wed, 13 Aug 2014 21:48:52 +0200, Tab Atkins Jr. <jackalmage@gmail.com>  
wrote:

> Once again, the CMYKColor class is merely echoing the behavior of the
> device-cmyk() function.  I'm not comfortable with making a change to
> one without changing the other.
>
> If you have a suggestion as to how to make device-cmyk() work better,
> we can discuss that, and after it's adopted I'll have CMYKColor mirror
> it.

Once we move into a color managed css world, I assume we will have  
something along these lines, with the obvious semantics:

@color-profile aRGB {
  type: rgb;
  src: url("http://www.example.com/adobe-rgb.icc");
}

@color-profile fogra39 {
  type: cmyk;
  src: url("http://www.example.com/forgra39.icc");
}

div {
  background-color: rgb(0, 128, 255, aRGB);
  color: cmyk(0, 50%, 50%, 10%, 1, forgra39);
}

In such a world, rgb(,,) would be the same as rgb(,,,sRGB), where sRGB  
would be a built-in color space.

The declarative syntax we have today is forward compatible with such a  
world, because the object created by these function is not observable, but  
understood to carry information (if implicitely) about the color space it  
is in.

I see 3 ways of thinking about the JS syntax we are discussing:

1 - It is a purely syntactic object, distinct from the internal color  
objects that carry color space information, which are still not  
observable. If so, there should not be methods on this object to do color  
math.

2 - It is an (interface to an) instance of this internal representation,  
in which case it must be color space aware. sRGB device-CMKYK values  
should be explicitly tagged as such, and APIs expecting these specific  
color spaces (all of them as of now?) should reject objects that do not  
carry this tag, or cannot be converted into one.

If we want to go that route, the tag should probably be a read only  
attribute pointing to an object that has (for now), only the name of the  
color profile as attribute, and can later be augmented with more things.

This is my favorite

3 - Every color space gets a different class deriving directly from  
CSSColor. Adobe RGB for example would not derive from RGBColor, but from  
CSSColor, and anyone wanting to do HSL in Adobe RGB space would need to  
define a separate class for that as well, rather than rely on the  
HSLColor. I suppose this is actually what you intended.

If that's the case, I suggest that CMYKColor should be called  
DeviceCMYKColor (and toCMYK() should be called toDeviceCMYK()), since this  
is not a generic CMYK class, but a very particular one. Similarly,  
RGBColor might be better off being called SRGBColor (although the  
existence of color-correction: auto | sRGB makes this not entirely  
obvious).

I think this could work reasonably well, except that it makes (s)RGB  
special as the intermediate space of every color space conversion, which  
is not too great if we ever want to be able to use anything else as the  
working color space.


Either way, I don't think I have the definitive answer to the question,  
but it does not seem wise to me to settle down on something without  
considering how that will map to the declarative syntax to for colors in  
different color spaces, and how it will deal with trying to have something  
else than sRGB as the working space.

I think it is time to go read the API of well established CMS systems, and  
see that that makes me any wiser.

Cheers,
Florian

Received on Thursday, 21 August 2014 13:04:35 UTC