W3C home > Mailing lists > Public > www-style@w3.org > November 2015

[css-color] wider/deeper colors

From: Dean Jackson <dino@apple.com>
Date: Mon, 2 Nov 2015 15:09:28 -0800
Message-Id: <5B15F03C-533C-4CBD-B266-4A499E230C18@apple.com>
Cc: Chris Lilley <chris@w3.org>
To: www-style <www-style@w3.org>
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.

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

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

3. We won't update image-set to allow images with different color profiles. Instead, authors will use the media query from above to switch between available images.


New comments:

A. Section 3.2 of the current CSS Color 4 draft has a note with this content: "This is not yet reliably implemented across implementations, though it has been shown to be implementable." The first part of the sentence is definitely true, but seeing as Safari has shipped for two major yearly releases with everything in sRGB, I think we can remove the last part of the sentence.

B. Section 4.1 includes comments about how values outside of 0%-100%/0-255 are allowed - this is great. There is a small typo at the end of the second paragraph after the definition: "gamut.)"

C. I filed this issue on the HTML specification about supporting wider color buffers in <canvas>
https://github.com/whatwg/html/issues/299

D. The CSS/SVG Filters specifications might need some love in order to support wider colors.

Dean
Received on Monday, 2 November 2015 23:09:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:58 UTC