Re: [w3c/manifest] Adding field `display_override` to the manifest (#932)

FYI this was discussed at TPAC 2020, minuted here:

https://www.w3.org/2020/10/26-webapps-minutes.html#t07

(I wasn't present.)

Just wanted to address:

> @slightlyoff : to @NotWoods point, supporting a valid value in _either_ location seems like a good "v2" solution

There is a detailed discussion on this [here](https://github.com/dmurph/display-mode/issues/10).

We explicitly didn't want to support non-legacy values in `display`, because that would not be backwards compatible with older browsers. Two options we considered:

- Allow `display` to have the new modes as an option. e.g., `"display": "window_controls_overlay"`. But if you're a browser that doesn't know about "tabbed", you have to interpret this as "browser", which means developers may _accidentally_ create an experience that has a fancy overlay on supported browsers, and literally doesn't show any window at all on browsers that don't support WCO.
- Allow `display` to have _either_ a string _or_ an array, allowing you to specify the fallback chain directly in there. Again, a legacy browser won't know what to do with the array, so it will just fall back to browser.

If we let developers put the new values in either `display` or `display_override`, then they can work around this backwards compatibility problem by always putting the new values in `display_override`, and never in `display`. But we're providing a footgun by letting them put new values in `display`: if you ever use it, you will see the correct behaviour on your shiny new browser, but incorrect behaviour on the older browser you forgot to test in.

That is why we're proposing to only allow the new values in `display_override`, and not allow any new values to be allowed in `display`.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/932#issuecomment-719185149