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

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

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.

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.

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

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

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