Re: [css-color] wider/deeper colors

On 16/03/22 08:25, Florian Rivoal wrote:
> Looks like Chris was a bit hasty in merging this.
I was  -  I went straight from reading the [css-color] email to the pull 
request and the comments, without noticing that the spec being modified 
was in fact MQ :) That said, I still think the pull request was a good 
one and it is much easier to discuss a concrete proposal while tidying 
up the remaining issues.
> the proposal looks good to me overall, but it still has issues:
>
> *  We should be explicit about what happens on non rgb devices.
Yes. There are multiple ways to address this:
a)  applies to RGB screens only (ie most of them, except for a few RGBY 
TVs currently plus monochrome eBook readers)
b)  applies to screen media only (so, say what happens with the non-RGB 
screens)
c) applies to all visual media, so say what happens to printers.

I think a) would be shortsighted and is not a good choice. b) is 
relatively easy and would be my preference. c) requires more work (in 
particular on how we would extend it) but I am fine with it if that is 
what we want to do.
> 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?
>
> *  The prose uses the word "display" to describe the output medium.
That leads me to think it is for screen (which now includes projection) 
media only. Which may be a better approach, another one can be done 
later for print media (to cover looks-like RGB inkjets, CMYK presses, 
wide gamut things like hexachrome, and so on) without holding up the 
screen-oriented MQ.
And this fits better with the MQ media types, where print and screen are 
explicitly disjoint.
> 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). 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.
e-ink is a useful example there. I would say it is a screen and is a display
> *  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 think it would. I agree that this could get complex the more terms we 
add, given that the gamuts are not strictly supersets and thus ordering 
is a judgement call. Using separate print and screen MQs would make that 
easier.
> 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?)
I would be fine with the more precise name if that is the direction we go.
> * 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".
Agreed. Displays that do a bit more than sRGB but are clearly closer in 
gamut volume coverage to sRGB rather than DCI P3 should give true for 
sRGB and false for the other two. The question becomes, where is the 
breakpoint between them?

One datapoint may come from UHDTV, according to wikipedia:
   "On January 4, 2016, the UHD Alliance announced their specifications 
for Ultra HD Premium which requires devices to display at least 90% of 
the DCI P3 color space.[8]"
https://en.wikipedia.org/wiki/DCI-P3

(not clear if this is 90% by gamut volume, or some less useful 2D 
coverage on xy or u'v' chromaticity diagrams, but it gives a ballpark 
figure of 90% for "or thereabouts".
> This implies that "@media (color-gamut:srgb)"
>      and "@media (color-gamut >= srgb)" are meant to be the same.
>      Is that right?
Depends how much greater.
>    - 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?
I would say that is within range (around 90% ) of the next value .
>    - If a display's gamut is strictly smaller than p3, but pretty
>      close to p3 nonetheless, does it match "(color-gamut < p3)"?
Again the 90% seems a good breakpoint there
>      I.e., can "(color-gamut:p3) and (color-gamut < p3)" be true?
>    - 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?
Good question. Can we assume we never add another term smaller than 
sRGB? I would say it should match 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.
Yes.
> * 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)
I prefer to restrict it to screen
>    - 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)
(They should explicitly cover "or larger")
>   - If the device has a non RGB color model (maybe)
>
> 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.
Inline issues (or inline links to github issues, easier for tracking) is 
a good way to go.

-- 
Chris Lilley
@svgeesus
Technical Director, W3C Interaction Domain

Received on Tuesday, 22 March 2016 14:31:44 UTC