Re: [csswg-drafts] [css-color] Working Color Space

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

<details><summary>The full IRC log of that discussion</summary>

```
<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.
```
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/300#issuecomment-296028894 using your GitHub account

Received on Friday, 21 April 2017 02:51:59 UTC