Re: [css-gcpm][css-color] device-cmyk() interaction with RGB-space colors.

On Mon, Sep 30, 2013 at 12:33 PM, Tab Atkins Jr. <>wrote:

> On Mon, Sep 30, 2013 at 4:14 AM, Chris Lilley <> wrote:
> > Tab asked why some colourspaces could perform independent channel by
> > chanel operations, suspected that it applied to RGB but not Lab; and I
> > answered why (you can do it with ones that are additive). Lab is an
> > example of an additive colourspace and can be, and is, used for
> > compositing.
> Okay, so, synthesizing everything I understand of the thread so far, I
> think I need to make the following changes:
> 1. Allow computed values to be CMYKA quints, rather than RGBA quads,
> when UAs wish to do so.  Normal browsers wouldn't do that, but
> print-based UAs might.  (And make sure I do this in a sufficiently
> generic way that UAs can hold computed values in other spaces, too,
> like Lab.)
> 2. Define which types of operations work equally over RGBA and CMYKA
> as simpler per-channel operations (and so can be done in either space,
> as long as both inputs are the same type of color), and which don't.
> For those that don't, require converting CMYKA to RGBA for those
> operations.  When the inputs don't have matching spaces, convert them
> both to RGBA and do the operation there.  (If we add more possible
> spaces, we'll need rules about what to convert between - if we had
> Lab, for example, I suspect we'd want to preserve it and convert the
> other to Lab as well.)

CSS filters and the Blend modes 'hue', 'saturation', 'color', 'luminosity'.
If we support Lab as a document color space (not sure if that's a good
idea), all blend modes are out.

> 3. Serialization is always in RGB.

What does that mean?

> 4. Maybe have some way to define a color profile for accurate mapping
> between spaces.  (Or maybe save that for Colors 5.)

yes, something like 'color-correction' [1] except it would describe your
target colorspace.


Received on Monday, 30 September 2013 23:30:44 UTC