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

On Thu, Aug 21, 2014 at 6:04 AM, Florian Rivoal <florian@rivoal.net> wrote:
> 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.

Yes, this is approximately what I expect will happen as well.

> 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

This is also my plan.  I don't think we need to do anything about it
for now, though; we can always add an attribute for the color space
later, when we have declarative colorspace support.  Right?

~TJ

Received on Thursday, 21 August 2014 14:29:34 UTC