Re: [css-color] wider/deeper colors

On Thu, Feb 18, 2016 at 8:18 PM, Florian Rivoal <florian@rivoal.net> wrote:

>
> > 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.
>

This is a very weird way of thinking about color management.
Can you point to a spec that say where the output profile come from? Is
there such a thing as a document profile?