[MQ] color-gamut Keywords

[Crissov]

The Color Display Quality color-gamut media-query currently supports three keyword values:

• srgb
• p3
• rec2020

Alas, they explicitly (though perhaps not intentionally) do not exactly match the similar colorspace keywords in css-color in neither keyword nor meaning:

• srgb (identical)
• display-p3 (DCI uses a different reference illuminant optimized for cinemas, rather than the common D65)
• rec-2020 (note the hyphen!)
• (a98-rgb)
• (prophoto-rgb)

It seems that more descriptive terms would be more appropriate, though Iʼm not exactly sure which:

• expanse: narrow / limited, normal, wide, wider / extra-wide, natural
• target technology: crt, lcd, led, oled, laser, ink, …
• primary medium: screen, cinema, print, photo, …
• television definition:
  • sd, hd, uhd
  • sdtv, hdtv, uhdtv; hdr
• standard:
  • rec-470/rec-601, rec-709, rec-2020; rec-2100; …
  • itu-r-bt470/itu-r-bt601, itu-r-bt709, itu-r-bt2020,
    iso-22028-2, iso-22028-3, iso-22028-4,
    iec-61966-2-1, iec-61966-2-2,
    smpte-eg-432-1, smpte-rp-431-2
  • bt-470/bt-601, bt-709, bt-2020; bt-2100;
    iso-2, iso-3, iso-4;
    iec-1/iec-2-1, iec-2/iec-2-2;
    eg-432/smpte-1, rp-431/smpte-2
• …

[AmeliaBR]

Relevant discussion at the end of the thread about color-profile names in #4056

Also note that Chromium and WebKit have shipped support for the color-gamut MQ. Doesn't mean we can't change to using keywords that are less likely to be misinterpreted, but the existing keywords might need to be kept around for compat.

[tabatkins]

Yeah, the differences are unintentional; we recently changed the color() keywords to have more reasonable hyphenation, but didn't think to go update the similar ones in color-gamut.

As Amelia says, the current keywords are already widely shipping, and probably shouldn't be changed. But I think it's cheap to add more keywords when they're just synonyms.

I agree that, unless there's a significant objection, we should make sure that the color() keywords and the corresponding color-gamut keywords should match exactly.

[svgeesus]

@tabatkins I suggest not, because they mean different things as I explained

[Crissov]

… and thatʼs why I think that very different keywords should be used, even if the current, similar ones would need to be kept for compatibility with existing implementations.

[svgeesus]

technology and medium look very like the old Media Types that were found unworkable and abandoned.

If we were designing this from scratch and no-one had shipped, then normal | wide | ultrawide or something like that would be reasonable (but then, people would complain and ask for more specific examples of what exactly is wide, for example is P3 wide or ultrawide, etc).

Given that this has shipped, I am reluctant to add aliases which would be partly supported for some time. But I won't oppose it if the CSS WG decides to add aliases.

[css-meeting-bot]

The CSS Working Group just discussed [MQ] color-gamut Keywords.

The full IRC log of that discussion

<dael> Topic: [MQ] color-gamut Keywords
<dael> github: https://github.com//issues/4535
<dael> TabAtkins: Is chris on?
<dael> Rossen_: I think he is
<dael> [silence]
<dael> florian: I think he said since they mean different it's okay that they are different
<dael> TabAtkins: I want to ask followups. I think it's bad that they're slightly different and spelled differently. I want to discuss with him on.
<dael> Rossen_: fwiw I agree with you on principle to either merge or break far apart
<dael> fantasai: I think chris is saying- there's 2 things to consider. One is this is shipping in impl. Other is these are not keywords that hook into those color profiles. They hook into color profile that's similar tot he named profile. There's a concern if we rename to match the color profile keywords people will expect to match that profile exactly.
<fantasai> https://drafts.csswg.org/mediaqueries/#color-gamut
<dael> fantasai: The definition is much more handwavy
<dael> florian: I don't think spelling is enough.
<dael> TabAtkins: Original intent is they were intended to be the same. That they divereged now seems after the fact reasoning. Shouldn't play into if it's good.
<dael> florian: Is other shipping?
<dael> TabAtkins: No
<dael> AmeliaBR: We can rename it but can't change to be equally value
<dael> florian: Meaning can't change. Property is intentionally specific.
<dael> TabAtkins: Maybe
<dael> florian: If divergence is accidental then solution seems easy
<dael> TabAtkins: We'd need to remove the dash from ref-2020 which makes it less consistent, but it's not a huge deal since the - is just between word and number. Just realign the color keywords.
<dael> AmeliaBR: Concern is using the keywords for meanings and when people are using color profile as color values would they expect to use the MQs to test specifically what profile is supported.
<dael> florian: Keywords have same meaning, MQ has different. MQ is if the gamut is roughly similar
<dael> TabAtkins: Reasonable to conclude if gamut is P3 you should be able to use the full range and have it work. Might have some clipping at the ends
<dael> AmeliaBR: Sounds like call preference is to revert some of the changes to keywords in color profiles so they match color gamut MQ keywords
<dael> AmeliaBR: That might be pending objections from chris
<dael> florian: Put in GH and sit on it for a week
<dael> TabAtkins: Yep
<dael> Rossen_: Let's not resolve now we can take it next week.
<dael> Rossen_: Proposed resolution is align the color function keywords with preexisting color gamut keywords

[svgeesus]

I'm less than enthusiastic about the suggestion on the Dec 11 call to roll back the consistent hyphenation for built-in color profiles.

I agree with @AmeliaBR and @fantasai that if we make them exactly the same as the built-in colorspaces, then people will assume they are testing for that exact profile and will then also want a bunch of other profiles added (a98-rgb, prophoto-rgb, and so on; or even manufacturer specific profiles).

This is very different to the roughly sRGB | common wide gamut | superwide 4k TV gamut buckets for MQ.

As I said earlier, if this was being designed now then maybe better keywords could be used but then there would be a drawback on that. Given that it shipped already in 2 browsers the cost of bikeshedding (there is always a cost, but this time it is high) seems excessive.

[tabatkins]

I'm still strongly on the position that "if they're exactly the same people will expect them to be the same" is a post hoc rationalization, and "these are spelled slightly differently, now nobody will make that assumption" is simply false.

What'll actually happen is people will be confused and annoyed by the seeming lack of consistency, and have trouble learning and remembering which is which.

The two things are using these keywords to mean approximately the same things. We should just be consistent in the naming. I agree it's not worth changing the (color-gamut) keywords, which means I'm still strongly supportive of switching the color() keywords back to being consistent.

[css-meeting-bot]

The CSS Working Group just discussed [MQ] color-gamut Keywords, and agreed to the following:

• RESOLVED: Remove Hyphen from rec2020 in all context; everything else stays as is

The full IRC log of that discussion

<dael> Topic: [MQ] color-gamut Keywords
<dael> github: https://github.com//issues/4535
<dael> astearns: chris you commented last
<dael> chris: I'm of the opinion this is shipped in 2 browsers so large change cost. If we designed now more generic names would be better but fact is Apple and others have shipped P3-gamut.
<dael> chris: We discussed hyphenation and got consensus on that and I don't want to rename them back. We went to display-P3 and then we'd have to rename and it would become ambig again. TabAtkins has a different opinion that they mean the same. I don't think they do mean the same
<dael> TabAtkins: I said they are approx the same. They're close to meaning same. Especially in ref2020 where one is a hypen and one not is extremely bad. p3 and display-p3 are different words.
<fantasai> s/is a hypen/has a hyphen/
<dael> TabAtkins: Still of opinion we should be consistent. We shouldn't change color gamut so we should revert color function keywords because else people will ask why different
<dael> florian: I would argue mean the same. If you understand MQ to ask if gamut is supported by screen with this approx as large as this color space then it's yes. If screen isn't an exact match it's okay. You're not asking about color space specifically
<dael> chris: No one suggests renamining display-P3 to P3?
<dael> TabAtkins: I'm possibly in that relm. I would like ref2020 to be consistently hyphenless. P3 and display-P3 sound different. Hyphen diff shoudln't be
<dael> florian: I would align P3 to the one used in MQ.
<dael> chris: Remember Apple wanted display-P3. When we reverted to what they wanted and what everyone talks about that's the name
<dael> TabAtkins: That's why I'm okay with display-P3. A subset of name in color gamut is okay. P3 means approx any of these.
<dael> florian: I don't think I would object to different P3. But your question was anyone suggesting we merge and I suggest we do. Won't object to don't
<dael> TabAtkins: Revert ref2020 in color to be hyphenless and leave p3/display-p3 alone?
<dael> chris: Okay with that....
<fantasai> I would strongly object to having the only difference be the presence of hyphens
<dael> florian: Maybe hear from Apple?
<dael> smfr: Apple prefer to keep
<dael> astearns: Prop: Remove Hyphen from ref2020?
<dael> astearns: Objections?
<smfr> s/ref2020/rec2020/
<chris> s/ref/rec/
<dael> RESOLVED: Remove Hyphen from rec2020 in all context; everything else stays as is