[Title Bar Customization] Should "caption_controls_overlay" be swapped for a new "display" mode?

[amandabaker]

Originally discussed in #202, but breaking it out into it's own issue.

@kenchris:

Have you considered making it another display mode? Like "standalone-captions-controls" or similar? Now there is this big overlap with display

I know that might make it turn into display: "browser" in UAs that don't understand it, but if there is agreement, adding support to existing browsers to map "standalone-captions-controls" to "standalone" is just a few lines or code - so they don't need to commit to actually implement the whole feature

Description

Add a new "display" mode: "standalone-controls-overlay".

The new fallback display mode order could be either:

Option 1	Option 2
fullscreen or standalone-controls-overlay	fullscreen
standalone	standalone-controls-overlay
minimal-ui	standalone
browser	minimal-ui
	browser

Option 1: prevents an unexpected fallback from fullscreen to standalone-caption-controls when developing a web app targeted at both mobile (supports fullscreen) and desktop (does not surpport fullscreen)

Option 2: linear fallback pattern starting from the least UA-controlled UI and flowing down to most UA-controlled UI

Pros/Cons

Pros:

• Cleaner than adding a new member to the manifest that has overlap with "display" and is only ever enabled for one display mode.

Cons:

• The possible fallback order is either confusing (solution 1), or may have unexpected consequences (solution 2)

Alternatives

One alternative approach would be to add a new "display_modifiers" member which accepts a list of modifiers which work in conjunction with specific "display" modes.

In the example below, if the PWA were installed on a mobile device that supports fullscreen mode, then the PWA would also enable the fictional "fullscreen-sample-modifier". If it were instead installed on a desktop device, then it would be installed in "standalone" mode, and the "standalone-controls-overlay" modifier would be enabled, which here implies that there would be a small caption controls overlay in the top corner in lieu of a full-width title bar.

{
  "display": "fullscreen",
  "display_modifiers": [
    "standalone-controls-overlay",
    "fullscreen-sample-modifier"
  ]
}

This approach is extensible and allows new modifications to be added to each of the display modes without having to alter the fallback order.

[amandabaker]

@aarongustafson It would be great to get your thoughts on the fallback order and the alternative "display-modifiers" option

[aarongustafson]

I’m kind of intrigued by the display modifiers concept, to be honest. Although I would prefer to see something like this:

{
  "display": "standalone",
  "display_modifiers": {
    "titlebar": false
  }
}

I could see this allowing devs to (potentially) make other modest UI tweaks as well. Like removing the refresh button from Minimal UI:

{
  "display": "minimal-ui",
  "display_modifiers": {
    "refresh-button": false
  }
}

Or explicitly removing the back button from standalone:

{
  "display": "standalone",
  "display_modifiers": {
    "back-button": false
  }
}

You could also use it to (potentially) customize the browser instance:

{
  "display": "browser",
  "display_modifiers": {
    "home-button": false,
    "refresh-button": false,
    "favorites-bar": false
  }
}

If we decided to go down this path, it would require an additional explainer that defines the various keys and the matrix of when & where they would be applicable (as well as which controls should never be disabled, probably on a per-display mode basis).

[marcoscaceres]

This seems very desktop specific... I wonder how it will translate to mobile; although I get the modifiers would just be hints. I don't think we want the ability to take things away from users though (as it's the user's UI, not the websites) - the Web app should maybe be able to request things:

"ui_controls": ["nav-buttons"],

[amandabaker]

This seems very desktop specific... I wonder how it will translate to mobile; although I get the modifiers would just be hints.

Those examples are pretty desktop-focused, but this could be used for any platform. E.g. maybe developers want to be able to use fullscreen on phones without notches, but standalone on phones with notches. Then they don't have to set safe-area-insets on each of the pages in their app, and normal system icons (battery, signal, etc.) can fill that top area. For this we can add a "fallback-to-standalone-if-notch" display modifier (the name isn't great, but it's just an example).

---

I don't think we want the ability to take things away from users though (as it's the user's UI, not the websites) - the Web app should maybe be able to request things

When a developer sets the display mode of their app, they're already choosing to take controls away from the user. By setting "display": standalone" on desktop, you "take away" the back and refresh buttons from the user relative to "minimal-ui".

However, we could achieve the same result using your "request" approach by requesting to add UI components instead of disabling them. So instead of disabling the back button on minimal-ui

"display": "minimal-ui",
"display-modifiers": {
  "back-button": "false"
}

you could enable the refresh button with standalone

"display": "standalone",
"display-modifiers": [ "refresh-button" ]

[amandabaker]

I've updated the explainer to use the "request things" approach:

"display": "standalone",
"display-modifiers": [ "caption-controls-overlay" ]

I'll leave this issue open for a bit to leave room for more discussion/feedback

[marcoscaceres]

Thanks @amandabaker. We probably want to abstract out a general set of controls that are a bit abstract. We've heard that navigation control is pretty important, obviously (but it may be that UAs just start providing those by default... or we modify the Manifest spec to suggest always including those for standalone + minimal UI).

Sorry for being thick, but I'm still not sure what "caption_controls_overlay" are? 🙈 Could someone provide a screenshot with an arrow or something so I can understand what those are?

[amandabaker]

@marcoscaceres The "caption-controls-overlay" is the black overlay in the top right corner which includes the caption controls. It's similar to standalone, except it cuts off the page title so that the developer can draw in that space instead (hence the display modifier that builds upon standalone). You can read more in this section the explainer.

Like Aaron said above, this will need its own explainer, so I'll get that out in a bit. But for the scope of this Title Bar Customization explainer, I'm just going to leave the one use case we have defined here.

[marcoscaceres]

Thanks for the clarification. I'm trying to think if there is an equivalent of this on MacOS or other OS... trying to figure out if it's a generalizable thing.

[aarongustafson]

@marcoscaceres The nomenclature doesn't match, but the concept is the same. MacOS calls them “window controls.” The titlebar concept is the same. I couldn't find details about a backplate, but there is a transparent titlebar option (plus textured & shadowed). We might need to render in a backplate.

[mgiuca]

Hello, I've been meaning to reply on this for a long time. I think this conversation should move over to Manifest because it's a much wider issue than just title bar customization. This is something we've had numerous discussions on over the years, but for some reason, I don't think there's actually a Manifest issue dedicated to it. So, I just made one: w3c/manifest#856

I really don't want us to add more display modes. This is very similar to my tabbed application mode proposal, where I also initially proposed your Option 1 (inserting a new display mode that falls back to standalone, which makes the fallback list into a DAG). This isn't really workable as we add more of these features, because they are unable to be mixed and matched.

What if I want a tabbed application mode where I can also control the caption controls? What if I want caption controls with minimal_ui? The linear, or even DAG, fallback chain, makes it very inflexible. This is not the extensible web.

So I am very much in favour of more flexible individual controls. The display_modifiers concept seems good to me and is similar to what I've proposed in the past (but with a bit of a different angle, which is that it's changing the existing semantics of display; the problem being they have no well-defined semantics). I've mentioned @aarongustafson 's display_modifiers in my big post on w3c/manifest#856. Let's continue this discussion there.

I was coincidentally talking to @dmurph about this today and I think it's something he wants to look into (we kind of need to resolve this before we spec title bar customization or tabbed application mode).

[amandabaker]

Transferring discussion to the new WICG repo: WICG/window-controls-overlay#4