W3C home > Mailing lists > Public > www-style@w3.org > March 2016

Re: [css-color] wider/deeper colors

From: Dean Jackson <dino@apple.com>
Date: Mon, 21 Mar 2016 23:05:36 -0700
Cc: www-style list <www-style@w3.org>
Message-id: <8AB943F0-3E29-48C3-AE58-120341F95C37@apple.com>
To: Rik Cabanier <cabanier@gmail.com>

> On 21 Mar 2016, at 19:34, Rik Cabanier <cabanier@gmail.com> wrote:

> But the developer is probably going to want to do that based on whether the device supports wider gamut, so it would cause multiple nesting.
> 
> Let's take an example of a developer creating an SVG in Illustrator who is using a wide gamut iMac. Since he wants to use all the available colors, he sets the document space to the monitor profile. 
> However regardless of the profile selected, the generated values in the SVG stay the same, so there needs to be a way to tag the SVG document profile as p3.
> 
> With your proposal, each color will have include a reference to the "p3" profile. This is cumbersome but will work, as long as there is no alpha or color blending or filters. 
> However, if you tag the inline SVG with the css property: 
>    compositing-space: "p3"
> the document will look correct on a p3 or higher display and as good as possible on a lesser display.

We definitely need something that allows an SVG to be tagged with a color space, but I think that's an SVG issue. Maybe we also need a CSS property, or HTML <img> attribute, that allows the referencing site to override the profile embedded in an image.

These are both good topics for discussion, but don't change what we've decided on so far.

>  
> I don't want to make this too complicated.
> 
> From my experience, authors find it easier to deal with a document color space than specifying colorspaces in the content.

Sure.

The case we're trying to cover right now is a Web page that wants to use some colors outside sRGB, when the combination of browser+display can handle it. This might be to match a CSS color to a pixel in a photograph. Note the "some" colors.

Maybe there should also be a way for the author to specify that the entire page should be tagged in a color space other than sRGB? I think that's also an interesting suggestion.

> For instance, originally InDesign encouraged a mixed content workflow but designers found it almost impossible to use. 
>  
> I doubt that people are going to want to specify a huge number of colors by hand that are outside sRGB, in the near future at least. It's more likely going to be something like this:
> 
> :root {
>   --my-color: rgb(255, 0, 0);
> }
> 
> @media (color-gamut: p3) {
>  :root {
>      --my-color: color(p3, 100%, 0%, 0%);
>   }
> }
> 
> Then var(--my-color) will be the brightest red on the display.
> 
> Only if you have a p3 display or one that matches sRGB.

Exactly.

> What happens if someone releases a display with an even higher gamut than p3 or one that is close but not the same (like AdobeRGB)? Do pages have to be redesigned to select the p3 media query?

I think you should go back and read the threads on this, plus the minutes of the meetings. I know this is a horrible thing to ask of any human, let alone a friend :) But we've discussed it a lot.

Here's a summary.

- No author can be expected to write content that supports all the possible color profiles
- Displays that claim to support a profile nearly universally fall short of the entire gamut (e.g. Ultra HDTV displays are nowhere near 100% of BT.2020), so 
- It's probably reasonable for now to group displays into tiers: sRGB-ish, P3-ish and BT.2020-ish.

Please don't argue against my summary. There was a lot more to the discussion.

We have also asked Adobe to explain what the workflow and tooling is for these situations, but haven't got any details yet. Maybe you can provide that? What does InDesign do if you want to match a color in the page content to something in a photo?

> 
> If the intent is to create consistent color, it seems that this is accomplishing the opposite. Maybe I'm missing something...

I don't understand how this is the opposite.

Dean



Received on Tuesday, 22 March 2016 06:06:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:01 UTC