Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-color] Working Color Space #300

svgeesus opened this issue Jul 10, 2016 · 5 comments


None yet
5 participants
Copy link

commented Jul 10, 2016

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.

@svgeesus svgeesus self-assigned this Jul 10, 2016


This comment has been minimized.

Copy link

commented Jan 10, 2017

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.


This comment has been minimized.

Copy link
Contributor Author

commented Jan 24, 2017

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


This comment has been minimized.

Copy link

commented Jan 25, 2017

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)

@grorg grorg added the Agenda+ F2F label Apr 19, 2017


This comment has been minimized.

Copy link

commented Apr 21, 2017

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

This comment has been minimized.

Copy link

commented Nov 7, 2017

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:
<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 :)

svgeesus added a commit that referenced this issue Apr 22, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.