Re: [css-color] more detailed proposal for "compositing-space"

On Tue, Mar 22, 2016 at 10:15 PM, Florian Rivoal <florian@rivoal.net> wrote:

>
> On Mar 23, 2016, at 12:58, Rik Cabanier <cabanier@gmail.com> wrote:
>
> All,
>
> here is a more detailed proposal for the compositing-space CSS property.
>
> * compositing-space is a non-inherited property that creates a stacking
> context if a color space is specified.
>
> * It takes the current values:
> - "default": the default value which doesn't create a new space
> - "uncalibrated": composite in the color space of the output device
> - "sRGB"/"P3"/"BT.2020": composite in the specified standard color space
> then map to the output device
> - "url(path.to.a.icc.profile)": composite with the supplied profile , then
> map to the output space
>
> * The root element has a value of "uncalibrated" by default.
>
> * The value is not animatable
>
> * Applies to all elements. In SVG, it applies to container elements,
> graphics elements and graphics referencing elements
>
>
> I agree about the overall idea, syntax, and choice of the default value in
> general and on the root element.
>

Thanks for the feedback. I agree with all of your points.


> For the url notation, I think you should be able to point to an icc
> profile or to an image with an embedded profile. Or preferably, we add a
> layer of indirection, and icc profiles or images with embedded profiles can
> be turned into named color spaces that can be used by this property using
> @color-profile.
>
> Also, I hope we can make it so that "composite in the .... color space"
> means not only compositing and blending, but any kind of color math,
> including for example gradients.
>

Yes. it should apply to everything.


> I would add "CIELab" to the list of predefined names. As discussed
> elsewhere, composition/color math in that space gives pretty results, and
> even if that's subjective, using CIELab as a working space is a thing that
> exists and is sometime desired, and that would be the natural way to ask
> for it.
>

 After getting feedback, I agree it's a reasonable option.
I worry that the implementation cost is too high and the feature too
advanced for most users.

> * If the compositing space is uncalibrated, CSS color values are defined
> as sRGB
> Otherwise if the compositing space is specified, CSS color values are in
> that color space.
>
>
> I believe that this is what makes the ability to specify a value to
> compositing-space other than default, uncalibrated or CIELab useful.
>
> I would argue that the existing hex colors, named colors, rgb(), rgba(),
> hsl(), hsla(), hwb() and gray() notations should be in sRGB no matter what.
>
> On the other hand, the color() function, which has so far been assumed to
> take an explicit color space as its first argument, could be made to work
> in the compositing color space as you describe if that first argument is
> "default" or something like that.
>
> A few reasons why I don't think we should change the spaces of the other
> color notations away from sRGB:
>
> 1) compatibility. Regardless of whether a UA supports color() or
> compositing-space, you can rely on the traditional notations always
> resulting in the same colors, which is useful for providing fallbacks, or
> to make it easier to start using the color profile aware css features
> (color() or compositing-space) in pre-existing stylesheets without having
> to worry about what is going to happen.
>
> 2) Cascading. If you've applied something like h1 { background:
> rgb(0,0,64); }, you probably expect all h1 elements in the document to have
> the same background. Just because some subtree of your document is doing
> fancy color-space aware stuff doesn't mean you expect the background of
> your titles to be different there.
>
> 3) when you point to an arbitrary icc color profile, there's not guarantee
> it's going to be an rgb one. It could be, but it might be something else.
> Mapping the the r, g and b channels of the rgb() function to the first 3
> channels of a not-necessarily rgb profile is suspicious.
>

Maybe we can stay in the rgb realm for now. CMYK has a whole other set of
requirements that we should tackle separately.
This proposal will work for that colorspace; we just need to add additional
parameters specific to prepress.


> 4) For named colors, how to map the names to anything other than the
> currently agreed sRGB values is unclear.
>

True. The color correct way is for them to stay in sRGB. It's just a bit
strange that "red" won't be 100% red.
FWIW in our applications, named and custom swatches are always in the
document colorspace


> 5) We've discussed the color() function having a fallback value, in case
> you fail to load the profile it wants to use. If we don't define that
> fallback as always sRGB, it will need to be context dependent (if the
> compositing-space property points to a correctly loaded color profile, use
> that, otherwise fallback to sRGB), which would be super confusing, and of
> questionable usefulness. And if it is always in sRGB, having the same
> notation mean something else if it is used as something else than the
> fallback of the color function in going to be confusing as well.
>
>  - Florian
>