Intent to Prototype: display-override

186 views
Skip to first unread message

Daniel Murphy

unread,
Jun 8, 2020, 6:31:03 PM6/8/20
to blink-dev
dmu...@chromium.org https://github.com/dmurph/display-mode/blob/master/explainer.md N/A 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/206
The 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/5728570678706176
This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
Jun 9, 2020, 7:53:33 AM6/9/20
to Daniel Murphy, blink-dev
On Tue, Jun 9, 2020 at 12:30 AM Daniel Murphy <dmu...@chromium.org> wrote:

Would be good to kick off a TAG review. (if nothing else, to make sure learnings from "display"'s design are documented and incorporated in future designs)
 
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/206
The 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

Would be good to get such 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/5728570678706176
This 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.

Daniel Murphy

unread,
Jun 16, 2020, 12:02:40 PM6/16/20
to blink-dev
dmu...@google.com https://github.com/dmurph/display-mode/blob/master/explainer.md N/A 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/206
The 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.

Mounir Lamouri

unread,
Jun 16, 2020, 5:59:07 PM6/16/20
to Daniel Murphy, blink-dev
Hi Daniel,

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?

-- 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%2B4qT31arcbBeVdAnz-ceaODB8jUU8HDyxp9kkAwdBAFKZRNJQ%40mail.gmail.com.

Daniel Murphy

unread,
Jun 16, 2020, 6:09:28 PM6/16/20
to Yoav Weiss, Mounir Lamouri, blink-dev
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 Lamouri

unread,
Jun 16, 2020, 6:25:23 PM6/16/20
to Daniel Murphy, Yoav Weiss, blink-dev
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?

-- Mounir

Matt Giuca

unread,
Jun 17, 2020, 1:23:00 AM6/17/20
to Mounir Lamouri, Daniel Murphy, Yoav Weiss, blink-dev
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.
 

-- 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.

Yoav Weiss

unread,
Jun 17, 2020, 2:45:45 AM6/17/20
to Daniel Murphy, blink-dev
On Tue, Jun 16, 2020 at 6:02 PM 'Daniel Murphy' via blink-dev <blin...@chromium.org> wrote:

TAG review? It seems like this might be a smaller scope review, but they may have guidance on the design of such a fallback.
 
--
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.

Mounir Lamouri

unread,
Jun 19, 2020, 1:51:09 AM6/19/20
to Matt Giuca, Daniel Murphy, Yoav Weiss, blink-dev
On Tue, 16 Jun 2020 at 22:22, Matt Giuca <mgi...@chromium.org> wrote:
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.

Just to make sure I understand, I'm going to recap. With `display_override` the UA will have a list of preferred display starting with `display_override` then adding `display` at the very end.
What I'm suggesting is to have the UA have a list of preferred `display` and have a fallback list that will be added after in the list. The only reason I was suggesting this is that it felt simpler to understand than the override that applies before the main property which sounds confusing to me.

Though, from the backward compat issue, I guess a not clearly mentioned goal from the summary section is to allow to create new types of displays? If that's as much a goal as offering the fallback override, would it make sense to simply deprecate `display` and add a `display_list` that will list all the supported displays? `display` could be used for backward compat reasons but would be ignored by browsers supporting `display_list`. Wouldn't this solve both problems?

-- Mounir

Matt Giuca

unread,
Jun 19, 2020, 2:25:34 AM6/19/20
to Mounir Lamouri, Daniel Murphy, Yoav Weiss, blink-dev
Well, you can't have a new browser that totally ignores display, only looking at display_list, because then all the existing sites break until they support both. So I assume what you mean here is that the new browser, if seeing display_list, will totally ignore display, but if display_list is omitted, it will still read display.

That makes sense to me, but I think a flaw in that is that it creates a system of two separate browser classes. "Class A" (legacy) browsers only understand display and "Class B" (new) browsers only understand display_list. When you have this schism, it's too easy for developers to only support new browsers (by only providing display_list), and only test in browsers that support display_list, breaking legacy browsers. The reason it would be so easy to break is that there are two ways to express the same thing: the "new way" and the "old way", and you would be relying on developers to supply both.

I'm more comfortable adding things incrementally, such that there's only one way to express a thing, and in doing so, legacy browsers handle it in the most sensible way. Under Daniel's proposal, the current advice of only providing "display: standalone" would continue to be the normal way to write things. You would only use display_override if you want custom logic, and you would always have your lowest-common-denominator display mode in "display". For example, display_override: "tabbed"; display: "standalone". New browsers show tabbed mode, legacy browsers standalone. I think that's much harder to break legacy browsers in that structure. Yes, it isn't the way we'd design it if building from scratch, but that's the price for backwards compat.

Also, I think this discussion should be moved to the issue tracker. We shouldn't have API debates on a semi-private I2P thread:

Daniel Murphy

unread,
Jun 22, 2020, 5:05:37 PM6/22/20
to Matt Giuca, Mounir Lamouri, Yoav Weiss, blink-dev
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:
  1. Fullscreen
  2. Standalone
  3. Minimal-ui
  4. 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.

Mounir Lamouri

unread,
Jun 22, 2020, 6:58:15 PM6/22/20
to Daniel Murphy, Matt Giuca, Yoav Weiss, blink-dev
On Mon, 22 Jun 2020 at 14:05, Daniel Murphy <dmu...@chromium.org> wrote:
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:
  1. Fullscreen
  2. Standalone
  3. Minimal-ui
  4. 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.
I think that the opinion to keep using `display` makes the API shape very odd and even if it makes sense today will seem very confusing soon enough and sound like a weird relic of the past. Keeping `display` as mandatory for ever will also require it to be set to a value that will have to be backward compatible which on top of an odd API makes the end result not as flexible as it was intended. The benefit of a new attribute and a deprecated attribute is that when everyone has moved on to the new attribute, all UAs can just stop supporting the other one and no one will ever hear about it. Education via tooling, articles, console warnings can reduce the chances of websites simply dropping `display` in favour of the new attribute. A stronger solution would even be for Chrome to require `display` to be set even if there is the new attribute for a while to make sure that other UAs are not penalised.

My point here is that we should aim for the ideal end result and figure out how to transition there. In other words, what would be the ideal API? Maybe `display` as an array? We can't probably do that but using a different name should be doable? The transition period may be a bit painful but will be always shorter than the lifetime of the new API itself (hopefully). We, as the UA, can take on a bit of work to make sure the transition is smooth. 

This said, as Matt pointed out, this discussion is more detailed than it needs to be on blink-dev@. You heard my feedback and I'm happy to continue the discussion on the repository if you think it can be productive.

-- Mounir

Matt Giuca

unread,
Jun 23, 2020, 11:49:46 PM6/23/20
to Mounir Lamouri, Daniel Murphy, Yoav Weiss, blink-dev
I've made a GitHub issue for this (https://github.com/dmurph/display-mode/issues/10) and attempted to summarize Mounir's counter-proposal. Please continue the discussion there.

Daniel Murphy

unread,
Jun 25, 2020, 3:57:47 PM6/25/20
to blink-dev, Matt Giuca, Daniel Murphy, yo...@yoav.ws, blink-dev, Mounir Lamouri
Thanks for the feedback everyone. I created a TAG review request here: https://github.com/w3ctag/design-reviews/issues/530

Please let me know if you have more issues by filing them on the github repo.

Mounir, I like your suggestion - please double check that the issue Matt filed matches what you expect.

Reply all
Reply to author
Forward
0 new messages