W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: [css-color] wider/deeper colors

From: Florian Rivoal <florian@rivoal.net>
Date: Fri, 19 Feb 2016 13:18:04 +0900
Cc: "L. David Baron" <dbaron@dbaron.org>, Chris Lilley <chris@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Dean Jackson <dino@apple.com>, www-style list <www-style@w3.org>
Message-Id: <5CAE0F85-F860-4180-B43B-01A37BE50D1C@rivoal.net>
To: Simon Fraser <smfr@me.com>

> On Feb 19, 2016, at 04:03, Simon Fraser <smfr@me.com> wrote:
>> On Feb 16, 2016, at 10:12 PM, L. David Baron <dbaron@dbaron.org> wrote:
>> On Tuesday 2016-02-16 10:34 +0100, Chris Lilley wrote:
>>> Monday, February 15, 2016, 1:07:08 AM, Florian wrote:
>>>> On Feb 12, 2016, at 11:16, Simon Fraser <smfr@me.com> wrote:
>>>>> I think we’re prefer to avoid referencing external resources for
>>>>> colors. What do you show before the resource is available? Transparent?
>>>> That's a real issue, and we should find some way of dealing with
>>>> the fall back, but I don't think we can have a solution that
>>>> does not allow for external color profiles.
>>> Absolutely. Otherwise we fail at one of the commonest use cases - CSS
>>> for print publishing, where there is an external profile for the
>>> target printing device but we want the same colors shown on screen.
>> I'm confused here.
>> I thought this discussion was about use of a color profile for
>> conversion of input colors specified in CSS.  But this requirement
>> sounds like you're talking about conversion of colors to the color
>> space of the output device.
> It’s the former, but maybe Chris thinks that once this is available, people will use it to make print-targeted content that “hardcodes” the colorspace of the output device?

I don't see that as hardcoding, rather the opposite. Unlike the device-cmyk() approach where you don't specify what the color space is and therefore depend on the output device being what you hope it will be to get your colors right, when you actually specify color spaces, you can optimize your assets (both images and explicit colors) to be the best match for what you think is the most likely output medium, while still having them work when rendering to something else.

We could just drop all color spaces other than CIELab, but that'd be hugely impractical. When you know something is most likely to come out into an sRGB environment, specifying things in sRGB makes sense, and color management deals with other environments. Just the same, if something is  likely to or meant for being printed on US Web Coated SWOP, working in that space makes sense, and doing so explicitly lets UAs deal with different situations.

 - Florian
Received on Friday, 19 February 2016 04:18:31 UTC

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