W3C home > Mailing lists > Public > www-style@w3.org > September 2013

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 24 Sep 2013 12:01:54 -0700
Message-ID: <CAAWBYDAHxHS0D3a9eFUGMLeLZH9q88VsfNQU4aEBo3w=c1qPrg@mail.gmail.com>
To: Simon Sapin <simon.sapin@exyr.org>
Cc: www-style list <www-style@w3.org>
On Thu, Sep 12, 2013 at 8:29 AM, Simon Sapin <simon.sapin@exyr.org> wrote:
> Hi,
> In CSS Color Level 3, all values of the <color> type (eventually) resolve to
> a (R, G, B, A) value.
> When multiple colors interact with each other in an interpolation
> (transition, animation, or gradient) or with alpha compositing
> (transparency), they do so in RGBA space.
> The addition of device-cmyk() changes that: not all colors are in the same
> space anymore. The spec needs to define how interpolation and alpha
> compositing works.
> Note that probably none of these cases are useful, we just need to pick
> something so that they’re well-defined.
> Possible suggestions:
> * Gradients whose color stops are not all in the same color space could be
> invalid.
> * I don’t expect any media to support both CMYK colors and
> transition/animations. But in case it happens, interpolating colors in
> different color spaces could switch at 50%, like interpolation of other
> discrete types.
> * Alpha compositing could be done in device CMYK space, after all RGB colors
> have been converted per a device-specific color profile.
> There may be further interactions with the Filter Effects and Compositing
> and Blending specs that need to be specified.

For now, I've specified this as converting to an RGBA color at
computed-value time.  I've extended the syntax as suggested at the f2f
to have an alpha and a fallback color, and if the fallback color isn't
specified, it converts automatically.  UAs are allowed to do the
conversion with output-device-specific information, or else use the
default conversion specified in the spec.

This avoids any of the complications we were talking about before,
like having individual pixels using the fallback color when it was
necessary to composite/blend them, or things like that.  It doesn't
seem even remotely worth going to that effort for an effect that'll be
ugly and undesirable anyway.

I suggest that we may want to add an at-rule to CSS that specifies the
conversion parameters, so authors can tweak them rather than relying
on unspecified "information available to the user agent".  (I thought
about doing a property, but we use colors in places that aren't on
elements, so we can't rely on that.)

Chris, how does this sound?  If it's okay, can you help me define the
conversion-profile specifier?

Received on Tuesday, 24 September 2013 19:02:41 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:32 UTC