Re: [css-color] Color issues for F2F discussion

> On May 17, 2016, at 13:55, Rik Cabanier <cabanier@gmail.com> wrote:
> 
> Hi Dean,
> 
> The meeting went well and I think we covered most of your points.
> Unfortunately, we didn't have enough time to cover them all.
> 
> The WG decided to move to github so maybe we need to break your and the spec issues in separate github issues.

Nitpick: we decided to move to github *after setting up mailing list to which all github activity would be forwarded*, which we haven't done yet.

> 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?
> 
> [didn't discuss this] If the user does this, they probably want to see over-saturated colors so it should return sRGB.

Not sure it made its way into the minutes, but I think we did discuss this, and concluded that the media query should match the display-profile as set by the OS, rather than the physical hardware. so the mq would match sRGB.

> 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.
> 
> [didn't discuss this] I agree, this keyword seems unnecessary. 

We did touch on this indirectly, by pointing out that if we do have the srgb value,
@media not (color-gamut) { } would match on any device crappy

> 
> 1.4 Should we add a "narrow" for displays less than sRGB (or something like that)?
> 
> [we briefly talked about this but I don't remember the conclusion. It's also not in the minutes]

The conclusion was that @media not (color-gamut) { } is equivalent to @media (color-gamut:narrow) { }, so we didn't need the value.

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

Actually, Tab's write up in the spec did address the issues I had raised against the mailing-list discussion, so I don't plan to re-raise them again, unless we change the wording into something I have issues with.

> 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"?
> 
> [we discussed] the group decided not to allow profile extraction from images. CORS would also have to apply which could be confusing. 

Did we decide against it? I must have been tired and failed to pay attention at that point, as I think we should support it.

> 3.2 Would untagged images follow the same rule?
> 
> [we didn't discuss this] Yes, we should assume that untagged images are into the document space.
> Moreover, I believe CSS RGB colors should also be in the document profile. That way "red" really is 100% red

Not sure about that. I think that assuming sRGB is safer.
* There are lots of images out there which do not expect to become super saturated as displays get better

* for css colors, assuming that they are in the document profile means that including a new stylesheet which changes the document profile into a document would break/change all previously specified colors in that document and its other stylesheets. This seems unfortunate. being able to specify colors in the document profile seems useful as well, but I'd rather have that go through new syntax. How about using "document" as a reserved keyword for color profiles and use it in the color function?
  background: color(document, 255 0 0, red /*this is the fallback*/);

> 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.
> 
> [we discussed this] Gradients are interpolated in the document's colorspace. There was no mention that linear sRGB wouldn't work (but I might have missed it) 

If we have Lab as a possible document color space (which I think we should), then that would probably be good enough for gradient interpolation.

Do you think we need to be able to specify the gradient interpolation color space separately to avoid paying the cost on the entire document? I wouldn't be opposed, but it seems overspecialized.
> 
> 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)
> 
> Is there a problem with banding today? An HDR monitor should render with at least 10 bits per channel which should mitigate issue caused by the higher gamut.

I think this has been discussed in some other thread earlier this year, and the conclusion was that dithering was probably a good idea in many cases, but that it could be left as a quality of implementation question, and that there was no need for authors to opt in or out.la

> 4.3 What about blending? Should there be a way to specify the way colors are blended?
> 
> [we touched upon this] Alpha and color blending blending will work the same as before.
> Chris and Florian wanted Lab as a working space but it implies different formulas.
> For instance, if you multiply Lab(100, -10, 0) with Lab(100, 10, 0), you don't want Lab(100, -100, 0) as a result.

I am not sure why there should be different formulas for Lab. The only open question might be whether the some range of the a and b channel should be normalized to [0,1] the same way the 0-255 range of r/g/b (and the [0,100] range of Lab's L) are before applying the multiplication, .

 - Florian