Csswg-drafts: [css-color] Working Color Space

[svgeesus]

https://drafts.csswg.org/css-color/#working-color-space

Resolved at San Francisco to add a working-color-space at-rule, which affects the entire document. Compositing, interpolation, blending use this. Initial value is sRGB. linear-sRGB, p3, rec2020, and lab were also discussed as values. Chris to read the canvas spec to see what it does there, particularly for the "optimal" value.

[karip]

Should the initial value be "auto"? Safari 10 seems to implement something like that. It means that on sRGB monitors, the working colorspace is sRGB. On P3 monitors, the working colorspace is P3.

Edit: actually, I'm not sure what Safari does. But, it is able to show P3 images correctly on P3 monitors without a working colorspace at-rule.

[svgeesus]

Edit: actually, I'm not sure what Safari does. But, it is able to show P3 images correctly on P3 monitors without a working colorspace at-rule.

That doesn't require a working colorspace. Things like interpolation and compositing of colors from different spaces are where this is needed.

The initial value, for Web-compat reasons, will be sRGB (because that is what is currently used).

[frivoal]

That doesn't require a working colorspace

Is that because when no interpolation / composition is needed, we can just do:
input space ---- (via CIE-lab)----> output space (which is a no-op when input=output)
instead of
input space ---- (via CIE-lab)----> working-space ----(via CIE-lab)----> output space
?

Presuming that's the case, it means that converting from the input to the output space is something that can happen late in the pipeline, well after computed or even used values. In which case the resolved value (result of getComputedStyle()) would presumably be the same as the specified value. This also seems fine when it comes to compositing.

However, when it comes to interpolation (gradients, animations...), this looks like something that you should be able to resolve at computed value time, as it does not depend on layout, much less painting or compositing. And that means it should affect the computed value and the result of getComputedStyle() somehow.

So how do we spec that? do we say that the computed and used values are the specified values, even in the cases where they will be used as inputs for an interpolation, but that when a property is set to a color that is the result of an interpolation (e.g. because of an animation / transition), then it is set to the right color in the working color space at computed value time?

---

Note: this relates to #871, #741, #480, #867, #883 (at least)

[css-meeting-bot]

The CSS Working Group just discussed Color properties, and agreed to the following resolutions:

• RESOLVED: Interesting idea, dino will experiment and come back with results.

The full IRC log of that discussion

<flackr> Topic: Color properties
<dino> Github Topic: https://github.com/w3c/csswg-drafts/issues/300
<flackr> dino: idea is that document will have working color space, some kind of css syntax to say what it is, default is srgb
<flackr> dino: there was some discussion as to what does the value if you specify background-color: rgb(255, 0, 0) what space are they in?
<flackr> ChrisL_: this is in sRGB
<flackr> dino: this didn't matter because everything was in sRGB. we think older style colors should be in working color space
<flackr> ChrisL_: downside is if you view source and copy some of their style and document the colors become different
<flackr> ChrisL_: also, one reason to change working color space is because you've got some bit of content you want in a different color space, like a video
<flackr> ChrisL_: you don't want your existing colors to change because you have a new element needing a wider gamut
<flackr> dino: adding the new element doesn't necessarily change colors
<flackr> ChrisL_: if you then want to have a gradient you need to change working color space
<flackr> dino: i propose we change default working color space away from srgb but to be the same as it
<dbaron> s/the same as it/extended sRGB/
<flackr> ChrisL_: in SRGB you've got 0-255 and we used to say you could theoretically go below 0 or above 255 but it was undefined what the transfer code was
<flackr> ChrisL_: there was defined a transfer space called ?? which was a linear mapping which was tried in HTML context for a while but it didn't work well
<dbaron> s/??/scRGB/
<flackr> ChrisL_: you need a wider gamut. going for an older model which isn't compatible with color management systems isn't going to work well
<flackr> dino: concern that ChrisL_ is bringing up is that you would end up with a band as you clamped at the edge of your color space
<flackr> ChrisL_: what is complete gamut range?
<flackr> dino: goes on forever
<flackr> dino: it covers at least P3
<flackr> dino: and should cover ?? (2020?)
<flackr> dino: should we distinguish between linear, SRGB, etc
<flackr> dino: we don't have any way to handle blending in linear space yet
<flackr> dino: designers don't understand what it is, are very used to non-linear blending
<jihye> s/??(2020?)/rec2020
<Rossen> q?
<flackr> ChrisL_: once we're finished with this easy stuff we need to get linear for when we get onto HDR
<flackr> dino: definitely do not want to block out linear, we could definitely add it now
<flackr> ChrisL_: i'd like to see more details about your proposal
<flackr> dino: I was hoping to implement it, do everything in extended SRGB and see what happens. and whenever doing an interpolation convert to the working color space and see how well this works
<flackr> dino: we could make the default working color space extended SRGB, which should be lossless, not out of gamut
<flackr> dino: I can do some experimentation and see if that's okay
<flackr> RESOLVED: Interesting idea, dino will experiment and come back with results.

[css-meeting-bot]

The Working Group just discussed Color, and agreed to the following resolutions:

• RESOLVED: Chris to do more work :)

The full IRC log of that discussion

<eae> Topic: Color

<Chris_> github: https://github.com/w3c/csswg-drafts/issues/300

<eae> Chris_: This issue is about making computations on color boundaries.

<eae> Chris_: If used in a gradient, transitions, animations, etc.

<eae> Chris_: Right now, by default, given that we've never had anything outside of srgb, is that it happens in srgb which is unfortunate. You'll end up with the wrong color due to the gamma curve.

<eae> Chris_: We've had several resolutions where we don't have the right color space.

<eae> Chris_: In April we discussed this and someone suggested a linear 16 bit color space.

<eae> Chris_: That would allow colors outisde of the srgb gamma to be expressed. Another option would be to have it be unbounded.

<leaverou> s/outisde of the srgb gamma/outisde of the srgb gamut/

<eae> Chris_: I'd like to push this forward to have spec text about this.

<eae> Chris_: There will be people here at 3:30 that are exerts in this and will have an in-depth dicussion about it.

<eae> Chris_: One of the reasons I started this community group is to get expert input - should help the spec move forward.

<eae> I don't have a better proposal yet. Does anyone have any thoughts on this?

<dbaron> q+

<eae> pkerr: You need to do you calculations in a linear space. Whether it is sRGB or float-16 that gives you the same flexibility but with better math

<eae> pkerr: Gives an infine space between 0 and 1

<eae> Chris_: The movie industry likes having absolute values defined.

<eae> pkerr: Linear pixels is the way to go.

<astearns> ack bkardell_

<astearns> ack dbaron

<smfr> q+

<eae> dbaron: One comment: I'm fine with putting stuff in spec that isn't quite sure yet but please stick a note on it to explain that/

<dbaron> ack next

<eae> smfr: You can't change the color space to be linear without breaking stuff. A lot of pages have assumptions that would break. Authors needs to opt in.

<Rossen> q?

<eae> pkerr: When I said use linear I meant use it for the math and then convert back, not necessarily switching everything to linear.

<eae> RESOLVED: Chris to do more work :)

[george-steel]

Has this gone anywhere? I made a demo of color blending issues to demonstrate the need for this as well as the filter version of this property. Forefox renders to-spec while Chrome uses sRGB even for SVG filters (which should use RGB by default).

[george-steel]

The choice of which representation of linear space to use should probably be left unspecified (probably to be implemented as whatever's native on the platform in question) as all the operations currently used on colors are isomorphic over conversion between different linear spaces. The only caveat should be that tests should allow for enough imprecision for platforms that use float16.

[svgeesus]

RESOLVED: Chris to do more work :)

OK, more work done. To catch up on this long-standing issue:

There cannot be a per-document or even per-element working colorspace because different options require calculations to be done in different colorspaces:

• color interpolation is now defined in CSS Color 5 and uses Lab by default, but individual properties or functions can override this
• color-mix() overrides the interpolation default to LCH, but has syntax to specify a different colorspace
• compositing currently uses gamma-encodes sRGB (which is terrible, but Web compatible) and will need to be upgraded to at minimum allow a linear-light option. CIE XYZ is the obvious choice here. Implementations can calculate in another linear-light space, like linear-light display-p3, and get the same result modulo gamut clipping. See https://github.com/w3c/csswg-drafts/issues/5669
• gradients currently use alpha-premultiplied gamma-encoded sRGB for Web compat, and will need to be upgraded to allow a perceptually uniform (still alpha premultiplied) option. Lab and LCH are the obvious candidates there. CSS Color 5 defines alpha-premultiplication for all color spaces

Also the need for a working colorspace for serialization was removed, serialized value is in the colorspace it was declared.

[svgeesus]

In consequence, related issues are being or have been raised on other specs. Color 4 says how to specify, resolve, and serialize the colors. Combining them is handled on the appropriate spec as mentioned above, and does not affect Color 4. Thus, this issue can finally be closed.