Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MQ] color-gamut Keywords #4535

Closed
Crissov opened this issue Nov 24, 2019 · 14 comments
Closed

[MQ] color-gamut Keywords #4535

Crissov opened this issue Nov 24, 2019 · 14 comments
Labels

Comments

@Crissov
Copy link
Contributor

Crissov commented Nov 24, 2019

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 AmeliaBR added css-color-4 Current Work mediaqueries-4 Current Work labels Nov 25, 2019
@AmeliaBR
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

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

@Crissov
Copy link
Contributor Author

Crissov commented Nov 27, 2019

… 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
Copy link
Contributor

svgeesus commented Dec 4, 2019

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
Copy link
Member

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
Copy link
Contributor

svgeesus commented Jan 15, 2020

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
Copy link
Member

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
Copy link
Member

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

@svgeesus
Copy link
Contributor

(This change also rolls-back the hyphenation introduced in #4056 for rec-2020 only).

@Crissov
Copy link
Contributor Author

Crissov commented Jan 16, 2020

Shouldn't this media query also include a value for devices with color gamuts significantly narrower than sRGB? Wouldn't such an addition be reason enough to add (recommended) aliases for all of them?

@tabatkins
Copy link
Member

CSS has not traditionally recognized the existence of narrower-than-sRGB gamuts, so no.

@Crissov
Copy link
Contributor Author

Crissov commented Jan 17, 2020

The gamut of CMYK devices is not necessarily narrower than sRGB, but certainly shaped differently. Iʼm not sure whether that matters.

@jstblck
Copy link

jstblck commented May 31, 2020

I just noticed this thread. I'm the person who proposed the hyphens in the color keywords. I see this is resolved but I just want to add the following for the record.

First, (for what it's worth) I'm completely fine that rec-2020 has been changed (back) to rec2020.

Second, I think rec2020 is still compatible with the hyphenation scheme proposed here. It simply depends on whether the period in "Rec.2020" is considered a space or not.

Therefore, in my opinion, rec-2020 and rec2020 are both compatible with the naming scheme for css-color and I'm happy that rec2020 is being used for consistency between color and color-gamut as well as compatibility with the shipping browsers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants