Honor media HTML attribute for link manifest

[beaufortfrancois]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: HTML spec
• Specification or proposal URL: https://html.spec.whatwg.org/multipage/links.html#link-type-manifest
• Discussion: Clarify that media and lang affect manifest selection whatwg/html#6444

Other information

Browsers don’t currently honor the media attribute for link[rel="manifest"] even though the updated HTML specification says they should.

When selecting a manifest, the user agent must select the most appropriate link element whose rel attribute contains the token manifest, while taking into consideration the media and lang attributes (if either is present). If there are multiple equally appropriate link elements, the user agent must use the last one declared in tree order.

Members of the Google Chrome team are thinking of honoring the link element’s "media" attribute for link[rel="manifest"] so that web developers can define multiple web app manifests based on a media query (dark and light modes for instance). The last one that matches will be picked at "install/use time".

Note that this intent is a first step as noted at whatwg/html#6444 (comment)

[annevk]

I should probably have thought about this sooner, but one thing that strikes me as odd here is that these manifests are for an application and the user needs might change over time. So while I might install application during light mode time, when I want to use it at dark mode time it would seem somewhat annoying if I was somehow stuck with a light mode entry point. Similarly, if I use a tiny browser window that doesn't mean I want to be stuck with a tiny variant of the application.

@yoavweiss raised this in whatwg/html#6444 (comment), but the response to that by @marcoscaceres was contrary to what I expected. As in, I would have expected that you want to make these kind of presentation decisions later, at time of use.

[beaufortfrancois]

Note that this proposal fixes a current problem where users who use dark mode always get the light splash screen color when they open their web app.

I wonder if in the future, the browser may fetch multiple web app manifests and apply the appropriate one at time of use based on media queries as a way to fix this problem.

[annevk]

Can't the splash color be made to vary on a query? It seems some things in the manifest should be able to vary on this, but not all.

[marcoscaceres]

@beaufortfrancois wrote:

I wonder if in the future, the browser may fetch multiple web app manifests and apply the appropriate one at time of use based on media queries as a way to fix this problem.

It's probably best to just put that directly in the same manifest... similar to CSS's media rule does the various overrides. Fetching multiple manifests is going to get quite messy.

@annevk wrote:

As in, I would have expected that you want to make these kind of presentation decisions later, at time of use.

That would be ideal, but I'm worried that by then it's too late, because by then the browser has handed everything to the OS (and the browser might have been closed, device restarted, etc.).

In any case, at a minimum, consistent handling of all <link rel> things should be a good start. We can simultaneously work on adding the ability to adapt manifest properties based on media within the manifest itself.

[annevk]

I'm not sure what you mean with consistent handling, but not all attributes make sense for all HTML link types. I don't think media makes sense for manifest. (Similar to how it does not apply to canonical, for instance.)

[marcoscaceres]

I'm not sure what you mean with consistent handling, but not all attributes make sense for all HTML link types.

Sorry, what I mean is that we define what those behaviors are consistently in one place - then, for example, have specific types opt-out of the affects of various attributes. So, whatever the outcome of whatwg/html#6450 might be.

I don't think media makes sense for manifest. (Similar to how it does not apply to canonical, for instance.)

I don't have a strong opinion if it does or not, tbh - but I think we should discuss that and come to some agreement across all the engines.

[beaufortfrancois]

It's probably best to just put that directly in the same manifest... similar to CSS's media rule does the various overrides. Fetching multiple manifests is going to get quite messy.

The thing I worry is that we'll have to define/update manifest properties each time a new CSS media feature is added/updated.

[annevk]

@beaufortfrancois I'm not sure this is the place to get into web manifest specifics, but you could make a subset of features vary on a media query (and potentially other things), no?

[beaufortfrancois]

Ideas like as w3c/manifest#186 (comment) and w3c/manifest#955 (comment) are indeed some interesting ways of addressing this, but I do think using the strong power of established patterns of the web platform is also valuable here. Web developers are already familiar with them and it is more extensible and future-proof.

[annevk]

Sure, but patterns should only be adopted when they are applicable. As discussed in 186 they do not apply here.

[beaufortfrancois]

I do think this pattern applies as said before: a media query for light/dark mode applies for instance to web app manifests. Currently users who install the Twitter Web App for instance always get the light version, even if when they use the OS dark mode. That results in a bad user experience. This proposal addresses this issue.

[annevk]

Sure, at a high-level it does, but it doesn't address it well. You shouldn't have to generate N manifests when only a couple of fields end up being different. I think the idea in 186 that each app should have a single manifest is still valid. This could also lead to massive user confusion if app names and such end up changing based on the environment.

[beaufortfrancois]

This could also lead to massive user confusion if app names and such end up changing based on the environment.

The manifest data is used at install time. So I'm not sure about which confusion you're talking about.

[annevk]

Fair, but then you still have the time-of-installation vs time-of-use problem and the fact that developers have to generate a bunch of manifests with nearly identical contents.

[tomayac]

As the person who initially requested this in the Chrome bug blindly assuming it worked that way already, let me chime in:

I think @annevk is operating under the thinking model of “whenever the media attribute changes, the manifest will be re-evaluated”, whereas my (and presumably @beaufortfrancois’) thinking model is how things currently work (that is, the manifest being re-evaluated according to https://web.dev/manifest-updates/).

I guess no browser would ever re-evaluate manifests immediately on change, but to be honest assuming they did is probably closer to user expectations, so Anne’s point. Maybe the spec should (does already?) contain non-normative text on the to-be-expected UA re-evaluation frequency.

Also, I want to (re-)emphasize that we are not opposed to making the manifest fields media-aware as an alternative way to achieve the same with just one manifest.

As a side note, some developers probably would not actually create physical different manifests, but dynamically create them based on query parameters for example.

[annevk]

Again, even if you pick a single one and stick with it, you still have the two problems I pointed out in the comment above you. I think that's more than enough reason to not pursue this.

[marcoscaceres]

I don't think this is right place to have this discussion. We should pick this up in whatwg/html#6450.

[kenchris]

Translations is generally a big issue we should solve.

From quick testing, I can change my language and dark mode on my Android phone, and it is reflected in apps immediately (my Twitter PWA reloaded on interaction). I guess the only way to properly support that would be to support embedded translations and maybe "media" inside the manifest file itself. But users would also need to make sure that their Service Worker cached files have meta data like language associated.

I believe @aarongustafson looked into this.

On the other hand, users are using accept-language and custom url's (say add ?lang=da) today to serve different manifests depending on language (or location).

Installing Twitter here (Denmark) installs a Danish manifest, thought I am using my system in English:

[kenchris]

Also related:

• The manifest has a lang, but what if multiple languages are supported? w3c/manifest-app-info#10
• Add optional translations member w3c/manifest#676 (comment)
• https://docs.google.com/document/d/1Vwi_u7RP-HrzCz389Qp4EPKrWhanetu8ivcJmGbhwFc/edit

[kenchris]

FYI @diekus @mgiuca

[annevk]

I'm not sure how the media attribute relates to languages? In any effect, I tend to agree that localization support should be possible with a single manifest as well, if you in fact have a single application across those locales.

[marcoscaceres]

I tend to agree that localization support should be possible with a single manifest as well, if you in fact have a single application across those locales.

Agree. I'll work to refine the proposal for localization.

[bgrins]

Closing this as per #630 (comment)