[ImageResource Color Scheme] Google's feedback on the ImageResource Color Scheme Explainer

[tomayac]

The ability to specify separate light/dark mode home screen icons is something that we have definitely heard developer need for.

On the other hand, as far as we can tell, operating systems like Chrome OS, Android, iOS, and macOS, do not have a specific notion of light/dark mode icons (yet?), but apparently, according to the Explainer, Windows does. Of course this doesn't mean that web apps couldn't be pioneering this.

First, a formal note: In https://github.com/mozilla/wg-decisions/issues/266, the CSS WG have removed no-preference; the to-be-expected default experience now is light. We have opened a PR that removes the outdated value and that was since merged.

For favicons, developers can leverage the regular prefers-color-scheme media query), which, in theory, also would be possible to do for SVG ImageResources. In practice, however, most operating systems limit icons to be used on the home screen to PNG, so the approach doesn't work.

Again for favicons, developers expect to be able to leverage the media attribute on link, but it's currently not supported.

Yet a different approach would be to conditionally load different manifests controlled by the media attribute on link, which doesn't work in practice (the same bug that was opened for favicons).

Given the above constraints, the proposed "color_scheme" field in ImageResource sounds reasonable for the narrow use case of specifying a dark/light mode icon, albeit unfortunate that due to the convention of underscores in field names in Web App Manifest, the name differs from "color-scheme", the CSS property and meta tag (different from—but related to—prefers-color-scheme).

Since the Explainer mentions high contrast mode, it might make sense to instead use "media" as the field name and allow for full-fledged media query expressivity as in link, so features like prefers-reduced-motion would be possible, to prevent, for example, potentially future live-updating clock icons (as on iOS), as well as support prefers-contrast, etc.

As a final remark, unlocking the opposite approach of conditionally loading different manifests would also allow for different manifests to be loaded for different languages using the hreflang attribute, which search engines have used for a while. Since there would be a lot of duplication in various manifests, we think it makes more sense to keep the branching in the ImageResource (and thus the manifest).

Concluding, we are interested in collaborating on the spec, are willing to review Chromium code, and are encouraging you to turn the explainer into a PR.

Tom, on behalf of the Chrome team