[css-color] Color issues for F2F discussion

[Personal note: it was painful to not spell colour correctly all through an email that uses the word so much]

I won't be able to dial in for the discussion of color on Wednesday but Simon (smfr) will be there representing Apple (and that's always an improvement on me anyway!)

I think there are a few things that could be discussed. If it helps, I've numbered everything.

Note that there are a few other parts of the platform trying to solve similar issues. For example, there is a discussion about how to specify the profile and backing-store depth of an HTML canvas element (https://github.com/whatwg/html/issues/299). What we decide has a impact there. e.g. the "fillStyle" and "strokeStyle" properties accept CSS colors, so will likely be what people use to draw with extended colors. 

1. The color-gamut media query [https://drafts.csswg.org/mediaqueries-4/#color-gamut]

WebKit now has an implementation of this, but it currently only works on iOS and we don't have public/nightly builds on that platform (sorry). We're discussing the best way to implement this on OS X with other engineers. Here are some things that we've uncovered:

1.1 What should happen to the query if the user has set, via the OS, their display profile to sRGB when they are on a P3-ish or above display?

1.2 The query (color-gamut: sRGB) should evaluate as true on nearly all modern display hardware. However, it evaluates as false on browsers that haven't implemented the query yet. This isn't unusual, but it makes me wonder if there is any point in having an sRGB keyword at all, and just let the parameter-less version handle that.

1.3 Following on from that, since @supports only takes property:value statements, you can't detect if a browser has implemented the color-gamut query. This is fine for stylesheets, where you'd just put the conditional content inside the @media condition, but it means there isn't any way to detect from JavaScript. It would be nice if CSS.supports() had a way to detect the implementation. Obviously this isn't specific to color-gamut.

1.4 Should we add a "narrow" for displays less than sRGB (or something like that)?

1.5 Florian asked a lot of specific questions on color-gamut. I think he intended to add them as inline issues in the spec.

2. Specifying colors outside of sRGB

I *think* we're mostly in agreement here, but we just need to work out the details.

2.1 Values outside of [0,1] in rgb/rgba. We need to choose a function for mapping such values into colors. The two candidates proposed so far are scRGB and xvYCC.

2.2 I think we're still waiting for Adobe to give us feedback on the workflow for these situations. Basically, how do people choose colors outside their display gamut. (Rik did explain some things in an email around 23 March, and I would summarise it to be "there is a document profile and everything maps into that" - which is part 3 below)

2.3 The new function for specifying a color in a given profile. Candidates were "color" and "icc" (at least a few people didn't like "icc", and on 17 Feb I declared that we'd agreed on "color"). Unless someone objects, let's pick "colour". OK, "color".

2.4 What are our hardcoded profiles? I don't have strong feelings, other than "p3" being one of them.

2.5 Should we support external profiles? In the first version of the feature? How do we reference them? (Note that CSS has survived without this for a while, even though SVG has supported it)

2.5 If we do support external profiles, what MUST an implementation do if the author specifies a color in one? Can it choose to ignore it? (It has to be able to do something in the case where it can't fetch the resource)

2.6 Again, if we support external profiles, should there be a way to simply point at an image and say "use whatever that uses"?

3. Document profiles

This is something that came up in one of the very long email threads (I think from Rik). 

3.1 Should there be a way to specify a profile for the entire document? That would mean all (existing) CSS color rules would use that rather than sRGB.

3.2 Would untagged images follow the same rule?

3.3 Would ImageData from <canvas> elements also follow?

4. Other stuff

4.1 There was a request to specify the colorspace used for gradients, possibly by extending SVG's color-interpolation property. The request explicitly said that the only other option, linear sRGB, isn't good enough.

4.2 The same email mentioned something that's specific to gradients, but we might as well discuss it here: should there be a way to request dithering of gradients on 8-bit displays? (Personally, I can't imagine any designer wanting banding unless they explicitly asked for it)

4.3 What about blending? Should there be a way to specify the way colors are blended?

5. Really other stuff

5.1 Black point compensation?

5.2 High dynamic range images?

5.3 Tagging SVG images?

Received on Wednesday, 11 May 2016 13:26:43 UTC