Re: [css-color] wider/deeper colors

> On 03 Nov 2015, at 08:09, Dean Jackson <dino@apple.com> wrote:
> 
> Hi,
> 
> We had a productive discussion about colors outside sRGB last week and I wanted to summarize the outcome. I also have provided some new comments. Please let me know if I got details incorrect. And please remember, IANACE (color expert).
> 
> 1. Add a new media query that is able to detect the "depth" of the display. I put that word in quotes because I think the current "color" query isn't sufficient and we need a term to better describe what we're trying to detect. The "color" query examines the number of bits per channel, but that doesn't allow you to ask if the display can show things outside sRGB. Instead we suggest there should be range-type query that allows you to detect "normal" (typical displays from today, in the sRGB range or about), "extended" (wider gamut displays, in the DCI P3 range or about) and "super-awesome-needs-a-better-name" displays (very wide gamut displays, in the Rec. 2020 range or about). I believe this might be the first media query that has named values but works as a range. We don't have good suggestions for the name of this query.

Note sure this has to be a range query. If you go with "awesome-colors: none | some | plenty", you can do "@media (awesome-colors) {...}" and have it match whenever the value is something other than none. Wouldn't that be enough?

Also, while I agree we should have a media query on this topic, is this the right way to slice the problem?
Maybe we should parallel the approach suggested for round display, and let you specify a color (in CIE-Lab) or a color space profile, and have the media query tell you whether or not the display can handle it.


> 2. The specification already says that values outside the sRGB space are supported. We're thinking of turning this on in WebKit soonish, but have some fears that there is content out there that might change as a result. You could argue that such declarations are probably an error, but you never know. It's also not yet clear how an author will calculate these values, considering popular imaging software doesn't provide them (e.g. photoshop clamps the RGB values and gives you a warning).

Also, if you're specifying values outside of the color space used by the display (sRGB), don't you need to chose on a rendering intent to have any idea what these are supposed to be displayed as?

> 3. We suggested adding a form of the rgb() function that takes a fourth parameter that names a colorspace. The name might come from an @color-profile rule, and we might have some hard-coded names. FWIW, we think that we should wait to see if Comment 2 works in practice before adding new syntax. And we'd need to decide what hard-coded profiles are useful ("AdobeRGB" was mentioned, although that seems to be designed for CYMK workflows - DCI P3 could be more appropriate).

We also said that having this "fourth" parameter be the first one would make things more flexible, allowing color space with 3 parameters (rgb), 4 parameters (cmyk), or even a single parameter (pantone, or other named colors).

 - Florian

Received on Tuesday, 3 November 2015 00:58:35 UTC