Honor media attribute

[beaufortfrancois]

With media queries such as prefers-color-scheme (dark or light mode) nowadays, it seems like it would be beneficial to honor the media attribute for the manifest link as raised by web developers at https://bugs.chromium.org/p/chromium/issues/detail?id=970159.

What do you folks think about it?

History shows at #186 that it wasn't an hard decision and I'd love if we could revisit this today.

CC @tomayac

[aarongustafson]

We are working to make ImageResource color scheme aware, which would solve part of this challenge.

I think one of the challenges with having multiple manifests is that you then have to maintain those separate manifests, which makes it more likely they will get out of sync. Your use case is light/dark mode, but there are all high contrast media queries and the potential for exponential manifests as different media queries for screen size, etc. get applied (e.g., a different manifest for small screens vs. large ones).

Setting aside the potential maintenance headache for the developer when it comes to maintenance, there’s also the complexity this creates for implementors (having to track which manifest should apply in which scenario) and there’s also the possibility users could get wildly different app experiences based on which manifest is loaded (e.g., different manifests get applied based on whether DevTools is open or not).

I think the use case outlined (color modes) is worth addressing (which is why I am pursuing it for ImageResource) but I am not sure adding media query-aware manifest loading is the answer.

Would love to hear thoughts from @marcoscaceres @kenchris @mgiuca and @christianliebel on this as well.

[marcoscaceres]

The behavior of <link rel="manifest"> is governed by HTML, which is an "external resource link". The HTML spec says (my emphasis):

if the link is an external resource link, then the media attribute is prescriptive. The user agent must apply the external resource when the media attribute's value matches the environment and the other relevant conditions apply, and must not apply it otherwise.

So, looks like we get dark mode support for free 🎉

[aarongustafson]

I noticed that as well @marcoscaceres. It does seem a bit like a house of cards, however.

Related:

<link rel="manifest" lang="es">
<link rel="manifest" lang="en-us">
<link rel="manifest" lang="en-uk">
<link rel="manifest" lang="de">
…

Now matrix that by color modes, different screen res, etc. and I guess I just feel like there should be a better solution for developers that would allow them to simplify their approach. In terms of the manifest (and assuming color_scheme gets adopted in ImageResource), the keys affected are:

• theme_color
• background_color

It feels like replicating every other key in the manifest to achieve a consistent dark mode is problematic. I think it’d be worth brainstorming another approach, either by modifying the manifest or by allowing CSS to "pierce the veil" into app representation via standardized custom properties or something.

[marcoscaceres]

Re: using lang="", we face an uphill battle trying to get bare minimum cross-browser support of any <link> attributes, including media="", lang="", etc. so it's best to be super conservative here and take whatever we can get from HTML. At the same time, I want to be cautious about adding new mechanisms to do things the web already does (even if it does them in less than ideal ways, which we should perhaps address at the HTML level).

the keys affected are:

• theme_color
• background_color

No sure I follow. Can you help me understand how they are affected? It would seem color_scheme should only really apply to a particular image resource.

As an aside, I wonder if an SVG icon would declare a prefers-color-scheme rule inside itself? Obviously, that wouldn't help PNG, JPG, etc. But it may be indicative that perhaps the icon file format itself should support the color scheme selection.

[kenchris]

I agree with Aaron, serving different manifest due to color theme seems a bit developer hostile and it won't cover all use-cases either.

I might set the global theme color, say in Windows, to dark and still use my app in light mode. But this means that the shortcuts would need to use dark versions of the image resources - so it is not just always just one of the other.

[tomayac]

For <link media> specifically, I see it as one but not the only way to realize different preference-dependent manifests. I think making link respect the media attribute can be orthogonal to other ways of making icons in Web App Manifest aware of the user's preferences. We can just have both…

The <link media> discussion affects rel="icon", rel="preload", and others. It doesn't meet my personal developer expectations if it's only supported in some circumstances but not others.

[tomayac]

The <link media> discussion affects rel="icon", rel="preload", and others. It doesn't meet my personal developer expectations if it's only supported in some circumstances but not others.

More evidence that it's not just me: whatwg/html#6408 (comment) and stars on https://crbug.com/970159.

[aarongustafson]

@marcoscaceres wrote:

No sure I follow. Can you help me understand how they are affected? It would seem color_scheme should only really apply to a particular image resource.

I was saying that those two keys are the only color references (currently) in the manifest spec. Those are the areas that would need to be adjustable to meet the use case as the referenced ImageResources should be able to handle this in a few ways:

• SVG - can adapt via their own media queries
• Bitmapped icons could be swapped on the server side
• ImageResource will (hopefully) become color_scheme adaptable

So what I am saying, in a nutshell, is that the surface we’d need to make adaptive is fairly small. In terms of how to solve this, I’m not sure, but a simple proposal might be something like:

"color_schemes": {
  "dark": {
    "theme_color": "#fff",
    "background_color": "#000"
  },
  "light": {
    "theme_color": "#000",
    "background_color": "#fff"
  }
}

where the color_schemes member supports named objects that map directly to CSS’s supported keywords for prefers-color-scheme and it’s eventual evolution to account for high contrast color modes. That way we take the dependency on CSS and can hand the colors off to the browser to make the decision (and don’t have to come up with or maintain our own logic). I’m not wedded to this idea, just throwing it out as a possibility.

Note: I would see this sitting alongside the existing theme_color & background_color members just like display_override.

@tomayac said:

We can just have both…

Agreed. I’m not averse to offering alternative approaches, I’m just wary of forcing devs to go down a path that could eventually become a manageability problem. If we can come up with a solution that allows them to manage it in one place, I think we should. I feel the same way about translations.

[marcoscaceres]

So, I definitely don't disagree: there is room for improvement as far as supporting the use cases as far as media=, lang=, etc.

However, I think at an absolute minimum, we should aim for media= and lang= support in browsers (which we don't have). As per @domenic's comments re: icons: whatwg/html#6408 (comment) and whatwg/html#6408 (comment)

We might want to start by adding some more text to HTML, like:

If multiple manifests are provided, the user agent must select the most appropriate manifest according to the media and lang attribute.

We can then either look at fixing this issue more globally at a HTML level, or deal specifically in the manifest.

[christianliebel]

@marcoscaceres I agree that the media & lang attributes should be honored—as it would indeed solve the problem and it would be a quick win.

But I also agree with @aarongustafson that providing an own manifest per "cartesian product" option (light/dark/high contrast/… * x languages) doesn't scale well. This reminds me of what you need to do in order to specify a pixel-perfect splash screen for iOS Home Screen web apps—not very nice:

<!-- iPhone X (1125px x 2436px) -->
<link rel="apple-touch-startup-image" media="(device-width: 375px) and (device-height: 812px) and (-webkit-device-pixel-ratio: 3)" href="/apple-launch-1125x2436.png">
<!-- iPhone 8, 7, 6s, 6 (750px x 1334px) -->
<link rel="apple-touch-startup-image" media="(device-width: 375px) and (device-height: 667px) and (-webkit-device-pixel-ratio: 2)" href="/apple-launch-750x1334.png">
<!-- iPhone 8 Plus, 7 Plus, 6s Plus, 6 Plus (1242px x 2208px) -->
<link rel="apple-touch-startup-image" media="(device-width: 414px) and (device-height: 736px) and (-webkit-device-pixel-ratio: 3)" href="/apple-launch-1242x2208.png">
<!-- … -->

Source: https://appsco.pe/developer/splash-screens

We’re handling things like this in the manifest already by providing a list of icons where the user agent can pick the ones that match based on size, purpose, etc. I feel handling dark/light mode, or high contrast would also fit in there (as an additional property for ImageResources).

@aarongustafson I'm not sure about the color_schemes property though, to me it sounds a bit too specific. Looks like a more general approach was discussed in the past: #186 (comment)

Long story short, I agree with @tomayac that we could have both. We should aim for media/lang support (does this require changes in the spec?) as a part of bringing manifest to CR and discuss adding color scheme awareness for ImageResources and/or the manifest as a whole later or in parallel.

[marcoscaceres]

@christianliebel wrote:

We should aim for media/lang support (does this require changes in the spec?)

No spec changes needed in Web Manifest. But I think we should add the clarification to HTML. I'll send a PR now.

as a part of bringing manifest to CR and discuss adding color scheme awareness for ImageResources and/or the manifest as a whole later or in parallel.

Agree.

[marcoscaceres]

Sent whatwg/html#6444 to HTML.

Closing as the original question was answered. Let's spin up a new bug to discuss alternative/manifest or image-resource solutions for this.