Add a color_scheme member to ImageResource

[aarongustafson]

With operating systems beginning to offer multiple color schemes (e.g., “dark mode” and “light mode”) and with CSS offering a media query for that user preference, it is important to enable web apps to offer appropriate iconography for the context. As such, we need to upgrade the ImageResource dictionary to include an optional member indicating which color scheme a given image should be associated with.

I’ve worked up an explainer on this here: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/ImageResource-color_scheme/explainer.md

Related: #618

[marcoscaceres]

Generally, this sounds good. Would probably need to tweak to color_scheme values a little bit, but nothing big. Ideally, we would just reuse whatever CSS is using. Could you please provide a link?

[tomayac]

The spec for this is here. In CSS, you'd do something like this (greatly simplified):

/* Default assumes light theme */
body {
  background-color: white;
  color: black;
}

/* For dark mode folk, invert */
@media (prefers-color-scheme: dark) {
  body {
    background-color: black;
    color: white;
  }
}

So we could either make the values of theme_color and background_color more complex by somehow adding alternatives; one idea could be "theme_color": "black / @media (prefers-color-scheme: dark) white" (similar to https://drafts.csswg.org/css-content/#alt).

Alternatively, we could add more properties like theme_color_dark and background_color_dark, which would be backwards compatible and simpler. And while Media Queries Level 5 defines more user preference media queries, none of the other ones seem super relevant for Web App Manifest (apart from maybe inverted-colors), so we'd probably not have to introduce further properties for them.

[aarongustafson]

Worth noting: there is some discussion around potentially aligning Microsoft’s high-contrast proposal with prefers-color-scheme. I haven’t been tracking that, but if it was merged in, the values for this property could naturally expand to encompass that as well.

[aarongustafson]

Another interesting side note: some OSes (like Windows) currently invert black icons to white and vice versa. Based on conversations with a few devs, they seemed to lean toward that being fine for "no preference" images, but not for ones with a preferred color scheme. Makes sense to me as well.

[tomayac]

Yeah, high contrast mode and inverted color mode generally are considered a medical necessity, so people are fine if things look a little off rather than not being able to see/read anything at all [citation needed].

Dark mode is a little different (I have survey results on that that I’m going to publish soon). The gist being some users need it, but some users also just appreciate the elegance.

[tomayac]

I was experimenting with leveraging the media attribute to make the manifest URL dynamic, but found this isn't being honored for <link rel="manifest"> (nor for <link rel="icon"> FWIW). I have filed https://bugs.chromium.org/p/chromium/issues/detail?id=970159 for Chrome.

[aarongustafson]

I was experimenting with leveraging the media attribute to make the manifest URL dynamic, but found this isn't being honored for <link rel="manifest"> (nor for <link rel="icon"> FWIW). I have filed https://bugs.chromium.org/p/chromium/issues/detail?id=970159 for Chrome.

Interesting. I guess one thing I question—and I know this is a semi-loaded topic—is what the development community’s appetite would be for maintaining multiple manifests. This is already somewhat of an open question with respect to translations. Would we want developers to have to maintain multiple permutations of "light" and "dark" icon versions of multiple language-specific manifests? That seems like a bumpy road to go down.

[aarongustafson]

Open to discussing this (and related topics) @ TPAC today or tomrrow.

[laukstein]

See GoogleChrome/lighthouse#3891 (comment), prefers-color-scheme supported also in SVG used in App Manifest.

[aarongustafson]

Migrated to ImageResource#26