Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-color] Working Color Space #300
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.
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).
Is that because when no interpolation / composition is needed, we can just do:
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?
The CSS Working Group just discussed
The full IRC log of that discussion
The Working Group just discussed
The full IRC log of that discussion<eae> Topic: Color
<Chris_> github: https://github.com//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?
<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
<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.
<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 :)