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

Add a color_scheme member to ImageResource #758

Closed
aarongustafson opened this issue Mar 21, 2019 · 10 comments
Closed

Add a color_scheme member to ImageResource #758

aarongustafson opened this issue Mar 21, 2019 · 10 comments

Comments

@aarongustafson
Copy link
Collaborator

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

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

tomayac commented Mar 22, 2019

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

tomayac commented Mar 22, 2019

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

tomayac commented Jun 4, 2019

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

@laukstein
Copy link

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

@aarongustafson
Copy link
Collaborator Author

Migrated to ImageResource#26

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

No branches or pull requests

4 participants