Re: [css-color] wider/deeper colors

>>> Step 1: 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?

No, I'm the one who's confused. MQ4 is indeed "mediaqueries", and there's no .html.

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

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

That could be done with separate MQs for each color model, but the likelyhood of them being implemented and of authors using them right seems pretty low to me:
@media (rgb-gamut: p3) or (rgby-gamut:p3yish) or (cmyk-gamut: gracol) {...}

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

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

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


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

Thanks.

Received on Tuesday, 22 March 2016 08:44:44 UTC