I'm curious what led to the design of the fallback ordering. It seems a little strange for the existing display value to be the last in the priority order since it's the only one that existing implementations would handle. It's also possible that this could be fixed by changing the recommended authoring practices (relative to what's used in the current examples) rather than by changing the processing model.

@dbaron do you mine elaborating what you mean by recommended authoring practices (is this authoring of the manifest?), current examples (my examples, or ones given for using a manifest currently?), and processing model?

@mgiuca might be able to provide context on why the current fallback chain was chosen.

I found this bug conversation: https://github.com/w3c/manifest/issues/169

It doesn't look like any of the problems that Matt [1] or I [2] outline are considered. It was probably too early in the development to see them.

[1] https://github.com/w3c/manifest/issues/856 [2] https://github.com/WICG/display-override/blob/master/explainer.md#introduction

By recommended authoring practices, I meant for people authoring a manifest. For example, using the example at the start of this issue, perhaps the recommended usage (given the current spec) should be:

{
  "display": "standalone",
  "display-override": ["standalone", "minimal-ui"],
}

so that it's more likely to produce the same results in implementations that do versus don't support display_override. On the other hand, maybe that's an argument that the ordering should be switched (and probably the new field renamed to indicate that it's now a fallback rather than an override).

I think that example should probably just be

{
  "display": "standalone"
}

No need for the override, right? All user agents must support display, and display has a defined fallback chain that is expected. What do you expect the fallback behavior to be for your example?

How do you imagine it to work if the new field was a fallback? Would that mean we are redefining the display fallback chain? I'd like to avoid that for backwards compatibility (I don't want old/unsupporting browsers to behave differently).

I feel like I failed to describe something here. Another way to think about display-override is that it is the 'advanced' mode. If a developer wants a special display mode or if they want extra control over exactly what their fallback chain is, then they use display-override (with display). Otherwise, they can just use display.

OK, I permuted the example the wrong way. Why should it not be (given the current spec):

{
  "display": "minimal-ui",
  "display-override": ["minimal-ui", "standalone"],
}

which seems to have the advantage that it would use minimal-ui in all implementations that support it. Or if the developer doesn't want that because they feel it's really critical to avoid browser at all costs, then the example ought to say that that's the reason for writing it the way it's written. (All the explainer says about the example is "The developer prefers minimal-ui but can settle for standalone.")

This concern feels true with a number of the other examples in the explainer; it's not clear to me why these examples are the recommended ways of achieving the results, at least in the presence of some implementations that support the feature and some that don't. (I guess that's not a permanent situation, but it's one that probably matters for a while and for the period when the explainer is likely to be relevant.)

Ah! Ok, so this is a case where I don't think I'm explaining things well enough.

For the minimal-ui example:

• Browser A support:
  • display
  • display-override
  • standalone
  • minimal-ui
• Browser B support:
  • display
  • display-override
  • standalone
  • minimal-ui
• Browser C support:
  • display
  • display-override
  • standalone
  • minimal-ui

The developer wants to use minimal-ui. If they set:

{
  "display": "minimal-ui"
}

A: WebApp supported, with minimal-ui B: WebApp NOT supported. minimal-ui is not supported, so it falls back to browser, which means it is not a webapp. C: WebApp supported, with minimal-ui

The developer says "Hey - Browser B supports WebApps, why can't I just be standalone there?" The answer is because the spec defines minimal-ui AFTER standalone, so a developer either has to:

• Not use that display mode at all, or
• Not support browser B.

with display_override:

{
  "display": "standalone",
  "display_override": ["minimal-ui"]
}

A: WebApp supported, with standalone B: WebApp supported. with standalone C: WebApp supported, with minimal-ui

In this case, now the WebApp is possible with all browsers.

The other examples highlight other problems - for example, the new Tabbed mode proposal. Without display_override, where would this fall in the fallback chain? What if the browser doesn't support it? That could mean either the developer:

• is forced to support other display modes they don't want, if it's high on the fallback chain, or
• is forced to not have a webapp if it is low on the fallback chain & tabbed mode isn't supported. Basically, the defined-by-spec fallback chain is the difficulty here, and it would be better if the developer could customize it. The override nature is to help with backwards compatibility.

If I have some time I'll try to update the explainer with a more thorough explanation of what various browsers would do for various display settings. I'm also happy to do a quick VC here to have higher bandwidth - I might not be understanding something you're saying.

Thanks for elaborating, Daniel.

I think it's also important to note that basically every example using display-override is an edge case (that's exactly the point: it's for when the "usual" ordering of display isn't good enough for you). So even though these examples look awkward because the developer is having to think through the effects both with and without support for the new member, they are awkward because they are edge cases. In the normal case, that we continue telling developers to use in our public guides, which 99% of sites can use, you won't even know about display-override, and continue to say display: standalone.

I think that's important to keep in mind, since we've had a lot of feedback saying "why not design it so that developers set display for legacy browsers and display-override for new browsers?" The problem with that is that 100% of developers now need to consider the distinction between the two, and consider how legacy and new browsers will react (display + display-override is the new normal, not an edge case). Whereas with the current proposal, display-override is only something that 1% of developers need to be concerned with.

So even though these examples look awkward because the developer is having to think through the effects both with and without support for the new member

Having the explainer explain that "thinking through", at least for some of the examples, would be helpful. (And making sure that the examples make sense in that context.)

Whereas with the current proposal, display-override is only something that 1% of developers need to be concerned with.

This is very helpful -- and also something that would be helpful if it were in the explainer.

Thanks - great suggestions, I'll add this info to the explainer soon. Sorry that this wasn't communicated better!

I just updated the explainer to have more information about the context & background, as well as having more information in the use cases. Hopefully that is more helpful! :)

Those explainer updates are helpful; thanks.

The TAG discussed this just now in our teleconference (and a little in Breakout C about 36 hours ago), and we're happy closing this. We'd encourage you to continue the standardization process for this (presumably bringing it to the Web Apps WG which maintains Manifest) and to address other feedback that comes up in that process, and also to do so for the related features that you reference in the explainer.

Thanks!