- From: Simon Fraser <smfr@me.com>
- Date: Thu, 18 Feb 2016 11:03:22 -0800
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: Chris Lilley <chris@w3.org>, Florian Rivoal <florian@rivoal.net>, "Tab Atkins Jr." <jackalmage@gmail.com>, Dean Jackson <dino@apple.com>, www-style list <www-style@w3.org>
> 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? Simon
Received on Thursday, 18 February 2016 19:03:54 UTC