This looks like something we'll want to implement on Chrome OS.

While websites today have dynamic control over their color scheme using HTML, they aren't able to dynamically change the color scheme until the page is loaded. During that time, the user will see a "flash" of the window dressing in the app's default theme color, before the page loads and dynamically sets it to dark mode (for example).

Having declarative rules about dark mode (for instance) lets you fix that flash in most cases.

Is this work progressing? Do you need engineering / standards support?

@mgiuca Awesome news! I would love to see this land for ImageResource and imagine we may want to do some work in the Manifest as well to offer alternate theme colors too. It would be great to see this land in Chromium across the board. Out of curiosity, have y’all looked at supporting color-scheme media queries within SVG icons as well?

I have been waiting for someone to be ready to move this forward, so I am more than happy to work to bring it to ImageResource first, since I feel it is relatively straightforward, and then craft a proposal for the Manifest as well.

Out of curiosity, have y’all looked at supporting color-scheme media queries within SVG icons as well?

We will support <link rel=icon media> (not your question, I know) (public announcement) and are also looking into supporting prefers-color-scheme in SVG (public-ish announcement) in the same work stream (so that's the connection to your question). No concrete timeline yet, but it's happening.

Just wanted to register my support for this proposal.

I work on PWABuilder.com, which packages PWAs for app stores like Google Play and Microsoft Store.

We are very interested in supporting different icons for different OS color themes. Aaron's proposal for color_scheme on the icon looks good to us. 👍

Hmm, I feel like doing it for ImageResources is a bit the wrong way around. Like wouldn't it be much easier (and more impactful) to do this for theme_color in the manifest?

That's what I had in mind. I'm happy for you to add it for ImageResources too, but I think we'll be putting our eng resources (on Chrome) towards implementing this in the theme color, to avoid that flash of light mode colour and switching into dark mode once the page loads.

@mgiuca Not sure specifically what "it" is in your comment, but this is to enable specific ImageResources to apply in specific user-preferred color schemes. We are looking at overall theme-ing in the Manifest spec as well, but this is specifically targeted at things like icons which don’t always look great against different backgrounds (see examples in the Explainer).

Ideally, if an icon (for a PWA or a Push Notification) could be a color-scheme aware SVG you wouldn’t need to use this member of the ImageResource at all, but it is still valuable for things like screenshots and other places.

Instead of "color_scheme", how about "media" instead. Reworking the example from the explainer:

"icons": [
  {
    "src": "/icons/play-later.svg",
    "type": "image/svg+xml",
    "purpose": "any",
    "media": "(prefers-color-scheme: light)"
  },
  {
    "src": "/icons/play-later-reverse.svg",
    "type": "image/svg+xml",
    "purpose": "any",
    "media": "(prefers-color-scheme: dark)"
  }
]

Agree about media. That will align with w3c/manifest#975 🥳

Let’s see where that conversation goes… I do agree this could be helpful though. One use case that jumps out is being able to pick up screenshots that are portrait or landscape based on the MQ rather than having to (potentially) consult image dimensions.

@marcoscaceres @loubrett @mgiuca @tomayac Given how close we are on user_preferences, do we think this still makes sense to introduce in ImageResource? Is there enough utility in offering both approaches?

I’d vouch for abandoning the proposal in favor of user_preferences.

Yeah, let's go the user_preferences route.

The only thing that gives me pause is that Notifications and Payment Request API both use this construct as well, right? How will they handle user preferences?

Also, reflecting on @marcoscaceres’ comments on user_preferences in the Manifest, keeping this might allow for a simpler approach to handling theme icons + translations.

Thoughts?

The only thing that gives me pause is that Notifications and Payment Request API both use this construct as well, right? How will they handle user preferences?

Sorry, can you clarify what you mean here by "use this construct"?

Don't both of those specs make use of ImageResource too? That was the impetus behind extracting this to its own spec as I recall.

Yeh this could be a good way to handle user preferences and translations. I think icons is the only field that has crossover here?

If we went with this approach would we also allow icons to be redefined in user_preferences?

@aarongustafson,

Don't both of those specs make use of ImageResource too?

Ah, sorry - now remembering. Thanks for the additional context! It was going to be Payment Handler to replace the ImageObject... but I think that spec may have stalled.

About Notifications, it uses a URL. But there may have been some other spec...

That was the impetus behind extracting this to its own spec as I recall.

Ah, that's right. We wanted a generalized means of representing an image resource in contexts where where HTMLImageElement don't make sense.

@loubrett wrote:

Yeh this could be a good way to handle user preferences and translations. I think icons is the only field that has crossover here?
If we went with this approach would we also allow icons to be redefined in user_preferences?

Yes, basically we would allow redefining everything.