Manifest: `display-mode` CSS media feature should include `"display_override"` values

[tomayac]

Now that the display_override Web App Manifest field is a thing (in Chromium at least), the possible values reported by the display-mode CSS media feature should also include the currently active display_override value, given it soon may be anything else than "fullscreen, "standalone", "minimal-ui", or "browser"; namely, for example, "tabbed" or "window-controls-overlay".

[kenchris]

it should include all values right. I assume "tabbed" is not restricted to display_override but can be used in display as well.

Maybe the wording needs to be changed a bit to expose all display mode and the manifest-incubations spec can then define additional modes

[kenchris]

display_override allows to set the fallback order manually, where as display does not and defines an order. If you add tabbed there today, it should fall back to browser

[kenchris]

The fallback chain today is browser for all these new values:

When the display member is missing, or if there is no valid display member, the user agent uses the browser display mode as the default display mode. As such, the user agent MUST support the browser display mode.

So we could easily allow them in display and just add browser as fallback value. Then say that any display mode value is exposed to the media query

[kenchris]

As far as I can see that would work automatically if new values were added to DisplayModeType

Actually display_override uses DisplayModeType so we are set. When you expose new incubation modes just add them to DisplayModeType and define the display fallback as "browser" and it's compatible with what we have today, and should be exposed to the media query

[dmurph]

I think our original intention is to have the 'new & advanced' display modes only be usable in display_override, but I'd be open to having them also be valid for display, given that this makes the spec dance easier to get them included in the media queries.

The main downside is that it makes the fallback chain a little less intuitive (right now, they resolve to a ordered list you can follow). The new ones would perhaps confuse that. But I could see us writing the spec in a way that distinguishes them separately.

[kenchris]

It's already written that way in the spec now. Not sure who made that change

Easy to add

1. maskable is <>

[dmurph]

I just did that 😄

[dmurph]

I think the difficulty here, the thing to keep in mind, is that these fallback chains are really tricky for these advanced use cases (maskable, tabbed, etc). What works for one developer might not work for another. This is why we slightly preferred having the new display modes only be supported by specifying in display_override, as this would make the fallback chain more obvious for the developer and they could actively make that choice, instead of having a 'default' fallback chain and then wonder whey

1. Why browsers that don't support tabbed don't support their webapp (say fallback for tabbed is just browser), or
2. Why their app, which requires maskable to operate correctly, shows up as standalone on certain browsers that don't support that display mode (say fallback for is defined as you mentioned above).

They can still get out of those problems by using display_override, but it's a little less obvious. Something to consider here before we jump to adding stuff to this list 😄

[kenchris]

I also think devs will find it weird if we are not supporting all values in display as it basically make display deprecated, while display_override doesn't sound like a replacement but more as a supplement, given the name

We can always show warning in DevTools if display_override is left out and tell devs to add it to decide the proper fallback chain when value is not supported