Re: [css-color] wider/deeper colors

> On 22 Mar 2016, at 00:25, Florian Rivoal <florian@rivoal.net <mailto:florian@rivoal.net>> wrote:
> 
>> 
>> On Mar 22, 2016, at 08:13, Dean Jackson <dino@apple.com <mailto:dino@apple.com>> wrote:
>> 
>> 
>>> On Feb 16, 2016, at 11:54 AM, Dean Jackson <dino@apple.com <mailto:dino@apple.com>> wrote:
>>> 
>>>> 
>>>> On 17 Feb 2016, at 6:49 AM, Chris Lilley <chris@w3.org <mailto:chris@w3.org>> wrote:
>>>> 
>>>> Hello Tab,
>>>> 
>>>> Tuesday, February 16, 2016, 7:53:29 PM, you wrote:
>>>> 
>>>>> On Tue, Feb 16, 2016 at 1:34 AM, Chris Lilley <chris@w3.org <mailto:chris@w3.org>> wrote:
>>>>>> Do you mean the existing CSS4 color function, or the function that
>>>>>> used to be called icc-color?
>>>> 
>>>>> Dont' worry about the existing CSS4 color() function, it's badly
>>>>> designed and I need to overhaul it, and the name isn't necessarily
>>>>> claimed.
>>>> 
>>>> Oh, good to know. (And I agree it is nice functionality but needs
>>>> work).
>>>> 
>>>> OK, I claim color() so we don't have to call it icc-color() and upset
>>>> people.
>>> 
>>> I think we're now settled on color() for the function name, color-gamut
>>> for the media-query name, and color-profile for the @rule that links
>>> to an ICC profile.
>> 
>> Step 1: https://github.com/w3c/csswg-drafts/pull/99 <https://github.com/w3c/csswg-drafts/pull/99>
> 
> Looks like Chris was a bit hasty in merging this. First, only the .bs file was updated, but MQ4 has the output html file committed to the repo as well, so we haven't actually udated the visible spec.

I'm confused. I only see a "mediaqueries" (without .html) and "mediaqueries-3" directory. Where is MQ4?

> Leaving that aside, the proposal looks good to me overall, but it still has issues:
> 
> *  We should be explicit about what happens on non rgb devices. Are they still allowed to match if their color space is wide enough (I think that's the right answer), or must they fail the media query regardless? Should the answer be the same for very different color models like CMYK and for similar ones like RGBY?

I don't mind what the answer is here. I'd lean towards non-rgb devices not passing the "srgb" value.

> 
> *  The prose uses the word "display" to describe the output medium. If this is meant to work the same on mediums that are not "displays", such as pieces of paper, we should change the phrasing (I think that's the right answer).

This query is in the "Display" section, and is next to the other queries that talk about the number of colors supported by the display.

> If it is not, then we should define what is and isn't a display (is e-ink one?), and say what happens if your output medium isn't one.
> 
> *  If the same MQ is supposed to work for RGB, CMYK, RGBY, or grayscale devices, then we may later add values for gamuts in these color models. I think would make it the first range media query to apply to a partially ordered set of values. I don't think this is inherently problematic, but it's new, so we may want to double check the definitions and be ready to add a note explaining. If it is NOT meant to apply to non RGB colors, that should be reflected in the name (rgb-gamut?)
> 
> * How evaluation of this MQ in a range context works is a bit unclear.
>  - If I read the spec right, 'color-gamut:srgb' means "sRGB or
>    thereabout, and possibly more", not "sRGB or thereabout,
>    but not more". This implies that "@media (color-gamut:srgb)"
>    and "@media (color-gamut >= srgb)" are meant to be the same.
>    Is that right?

Yes.

>  - What is "@media (color-gamut > srgb)" supposed to mean (note
>    the strict inequality)? Are we requiring that the color gamut
>    is at least as large as the next value (p3), or is a gamut
>    strictly larger than sRGB but not by much (and therefore not p3)
>    supposed to match as well?

For the sake of sanity, I think it should mean at least as large as the next value. These are already vague values. Let's not add sub-ranges of vagueness.

>  - If a display's gamut is strictly smaller than p3, but pretty
>    close to p3 nonetheless, does it match "(color-gamut < p3)"?
>    I.e., can "(color-gamut:p3) and (color-gamut < p3)" be true?

Again, vagueness. It's going to depend on what you mean by pretty close. Or actually what the browser considers to be pretty close. I think they will tend to have such a display match p3, in which case it would not match (color-gamut < p3).

This does mean that the author has to trust the browser is making good decisions. I think that's ok. We'll probably get prompt feedback if the decision for a particular device is bad. (I say this because it is a lot easier for Apple, at least on iOS)

>  - What is "@media (color-gamut < sRGB)" supposed to do?
>    Should it match devices with a gamut narrower than sRGB or
>    thereabout, or should it match nothing, because the color-gamut
>    MQ has no value smaller than sRGB?

Technically CSS is using sRGB, so I think we should assume that as a baseline. So < srgb matches nothing.

>  ...
>  As long as the values have the implied "or larger" semantics,
>  I think we would make things clearer by dropping support for
>  inequalities on this media feature. Or maybe vice versa.

I think it might be best to drop them.

> 
> * The meaning of this media query in a boolean context may shift
>  depending on how we resolve the questions above. When is
>  "@media (color-gamut)" false?
>  - If the device is not a visual one (that's for sure)
>  - If the device is not a screen (if we keep the "display" phrasing)
>  - If the device has a gamut smaller than sRGB (yes, unless we add
>    CMYK or grayscale gamuts to the list, changing which is the smallest
>    gamut)
>  - If the device has a gamut that matches neither sRGB nor p3
>    nor rec2020, even if it is large (if the semantics no longer
>    imply "or larger" in the values)
>  - If the device has a non RGB color model (maybe)

I'd suggest that (color-gamut) is always true in the presence of a visual device. If someone uses that then they probably don't know what they are doing, so we just need to be consistent.

> 
> Hopefully we can agree quickly about these. If not, I'll probably add them as inline issues in the spec. That sounds better than reverting until we solve it all.

I need to send a followup to make some changes.

Dean