Re: [css-color] wider/deeper colors

On Tue, Mar 22, 2016 at 1:44 AM, Florian Rivoal <florian@rivoal.net> wrote:
> But then I don't know why your now-merged commit does appear in the git repo but is not reflected on on https://drafts.csswg.org/mediaqueries/.

Because it had markup errors. I'm fixing those now.

>>> 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.
>
> Why? I'd lean the other way. The Y in RGBY display is there in order to make them wider gamut. Denying them wide gamut images would be cruel. And similarly, if we're printing to some wide gamut CMYK profile, why would we want to only get narrow gamut images?
>
> This definition would not constrain browsers into supporting CMYK or RGBY if they don't care to, but if the combination of the browser and the device does allow output to a wide gamut non RGB space, why not let the content take advantage of it?

Yes, "approximately supports the set of colors describable with this
colorspace" is completely possible for non-RGB output devices too.
They just need to be wide neough.

>>> *  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.
>
> "The color media feature describes the number of bits per color component of the output device"
>
> "The resolution media feature describes the resolution of the output device"
>
> "The scan media feature describes the scanning process of some output devices"
>
> "The update media feature is used to query the ability of the output device"
>
> I think "output device" is the preferred phrasing.

Yup.  Fixed.

>>> * How evaluation of this MQ in a range context works is a bit unclear.
>
>> [ ... snip a bunch of sub-issues on which we don't agree about the details
>>   because we agree on the overall conclusion ... ]
>>>
>>>  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.
>
> Agreed.

Done.  I've made it clear that the values are true if you support the
gamut "or more".

>>> * 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.
>
> That sounds ok with me. To make that work, we need to do one of the following:
>
> - add specific prose overriding the normal way boolean context evaluation works. The normal definition is "If the feature would be true for any value other than the number 0, a dimension with the value 0, or the keyword none, the media feature evaluates to true. Otherwise, it evaluates to false.")
>
> - add a value that matches when the others don't.
>    color-gamut: narrow | srgb | p3 | rec2020
>
> - Rename sRGB (legacy? narrow?), and say it always matches if the other values don't

We don't need to do that.  It's possible for an MQ to just be false
for all possible values, and that makes the boolean-context return
false according to the existing definition.  That is, given the three
values we already have, "not (color-gamut)" will be true in
narrow-gamut devices only (like monochrome).

That said, I added a note calling this out, and put an issue into the
spec about if we want a value just in case.

~TJ

Received on Tuesday, 22 March 2016 18:53:35 UTC