Add a new field to the web manifest, "display-override", where a developer can specify an explicit display fallback chain they would like applied. Example of a website that wants "minimal-ui" to fall back to "standalone". { "display": "standalone", "display-override": ["minimal-ui"], } The way the "display" field works is inflexible and has the following problems: 1: The fallback chain is inflexible. For example, a developer cannot request "minimal-ui" without being forced to fall back to "browser" if that display mode is not supported. This basically means that it is no longer a PWA. 2: Forces display modes on developers that they don't want. For example, if a developer does NOT want a specific display mode, especially if new modes are added, there is no way to have the browser NOT fallback to it if the requested mode is not supported. This is especially applicable for new display mode - if a developer want fullscreen, and tabbed is introduced after fullscreen in the display mode list, they must support a tabbed display mode, even if they don't want it. 3: As mentioned in 2, new APIs proposals like tabbed mode [1] and Window Control Overlay [2] [3] don't fit well in the existing list, and are thus blocked on us improving the API functionality here. Please see the explainer for more information here. [1]: https://github.com/w3c/manifest/issues/737 [2]: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/TitleBarCustomization/explainer.md [3]: https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/206The API is designed to be fully backwards compatible, where unsupporting browsers will fall back to the "display" field. Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals
None. None. None.None. No This will only be supported on platforms that have WebApps: Windows, Mac, Linux, Chrome OS, Android No Because you cannot install a WebApp in web platform tests, this will need to be tested using browser tests. https://chromestatus.com/feature/5728570678706176This intent message was generated by Chrome Platform Status.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B4qT30oSEy%2Bto92bmZUEEcZUYTYKhEGi%2BMFSU70ze3NBM1Ziw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B4qT31arcbBeVdAnz-ceaODB8jUU8HDyxp9kkAwdBAFKZRNJQ%40mail.gmail.com.
Did you consider having only one array list (display_list, supported_display, ...) that would be used to select the display type? It feels a bit unclear to have a list of display preferences but then if none of the ones in the list are available, the UA will fallback to another property that will then have its own fallback mechanism. Having that fallback entry at the end of the display list may achieve the same role? I guess the only difference is we would have to not use the fallback order that was set for `display` but maybe if the Manifest already contains the list of supported displays, a fallback done by the UA wouldn't be that useful, would it?
Sorry for duplicate display-override emails (I didn't think my google address was in the group, ended up sending from both). I'm consolidating comment from +Mounir Lamouri here:Did you consider having only one array list (display_list, supported_display, ...) that would be used to select the display type? It feels a bit unclear to have a list of display preferences but then if none of the ones in the list are available, the UA will fallback to another property that will then have its own fallback mechanism. Having that fallback entry at the end of the display list may achieve the same role? I guess the only difference is we would have to not use the fallback order that was set for `display` but maybe if the Manifest already contains the list of supported displays, a fallback done by the UA wouldn't be that useful, would it?The main reason here is backwards compatibility. If browsers don't support the new manifest field (/ if the browser is old), they will be expecting the 'display' field to be set. So to support that it seemed easy to have this new property effectively provide an 'override' mechanism for the display (hence the name). Websites that don't set the display field are considered not installable currently.
-- Mounir
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B-LeH-rBYp6PPudBMncB6yuAcXG6hoKxNG-PEj-NDUK%3DAvZAA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B4qT31arcbBeVdAnz-ceaODB8jUU8HDyxp9kkAwdBAFKZRNJQ%40mail.gmail.com.
On Wed, 17 Jun 2020 at 08:25, 'Mounir Lamouri' via blink-dev <blin...@chromium.org> wrote:On Tue, 16 Jun 2020 at 15:09, Daniel Murphy <dmu...@chromium.org> wrote:Sorry for duplicate display-override emails (I didn't think my google address was in the group, ended up sending from both). I'm consolidating comment from +Mounir Lamouri here:Did you consider having only one array list (display_list, supported_display, ...) that would be used to select the display type? It feels a bit unclear to have a list of display preferences but then if none of the ones in the list are available, the UA will fallback to another property that will then have its own fallback mechanism. Having that fallback entry at the end of the display list may achieve the same role? I guess the only difference is we would have to not use the fallback order that was set for `display` but maybe if the Manifest already contains the list of supported displays, a fallback done by the UA wouldn't be that useful, would it?The main reason here is backwards compatibility. If browsers don't support the new manifest field (/ if the browser is old), they will be expecting the 'display' field to be set. So to support that it seemed easy to have this new property effectively provide an 'override' mechanism for the display (hence the name). Websites that don't set the display field are considered not installable currently.But if I understand correctly, `display_override` is used first so technically `display` isn't really needed, is it? Could we instead imagine something like `display` being still used but then have a `display_fallback_override` that is now used instead of the default fallback list from the UA? This way `display` is still front and foremost but only the websites that need to change the fallback list would set it and the override without the main property would make not much sense. Basically, it's the same idea as having a new array for display but the first element is `display` instead of the last one. WDYT?The main point of this is to enable new features that aren't part of the current display hierarchy, but allow them to fall back to the legacy display modes if not recognised by an older browser.If "display" was checked first, then fall back to a newly specified fallback chain, it would allow you to customize the existing fallback chain, but you couldn't say "The first priority is to use this new feature; failing that, fall back to standalone." Because the only way to say that would be to put the new feature in "display", which would then render your site non-installable on older browsers.So display_override is specifically all about being able to put new modes in front of the legacy display field.
To further elaborate / give context:Every web app today MUST have a 'display' property set to 'standalone' (or 'minimal-ui'). All browsers that support webapps check this field, and use it to set the display mode of the web app. There is a spec-defined fallback for browsers:
- Fullscreen
- Standalone
- Minimal-ui
- Browser
(example current problem: Browsers that do NOT support minimal-ui force websites to fall back to 'browser', even though the website might want to still be in 'standalone' mode if 'minimal' isn't supported)We want to avoid the following breakages:
- A WebApp is no longer considered 'eligible' to be a webapp where it sets a 'display' value like supported before
- An updated/new WebApp cannot work on a legacy browser (or modern browser that doesn't implement this yet) because it has set 'display' to an unsupported value (e.g. an array) OR 'display' is missing.