Csswg-drafts: [css-mediaqueries] Proposal: "navigation-controls"

[fallaciousreasoning]

Overview

This API is being proposed as a way to eliminate the "double back button" problem (seen here, on Twitters PWA in the Microsoft store). This problem arises because developers of "standalone" , "fullscreen" , and "minimal-ui" apps have no way of determining whether a back button will be provided by the user agent (the browser, OS, or hardware), and so, are forced to implement their own, to ensure that their app is functional without the browser's UI.

This will allow apps to avoid the "double back button" problem by letting them conditionally display a back button depending on whether the user agent is already displaying one. Adding a standard way to detect this means that we can avoid user-agent and viewport-size workarounds, which are not ideal for web compatibility.

Example Usage

/* Hide the back button if the browser provides any navigation controls. */
@media (navigation-controls) {
    #back-button {
        display: none;
    }
}

/* 
 * Make the back button green if the browser is not showing any navigation controls.
 * Note: This will not match unless the user agent understands the media query, even
 * if no controls are being shown.
 */
@media (navigation-controls: none) {
    #back-button {
        background: green;
    }
}

/*
 * Make the back button red if the browser is showing one too.
 * Note: If this query matches then @media (navigation-controls)
 * will too.
 */
@media (navigation-controls: back) {
    #back-button {
        background: red;
    }
}

Relevant Links:

Initial Issue (from @mgiuca)
Explainer
Discourse Thread

CC

@mustjab

[tabatkins]

Sounds good to me.

The explainer's note about a positive value always assuming the presence of a back button is interesting, tho. I suppose it's reasonable that the Back button is the primary control that must always be offered; everything else is secondary and will never show up without the back button being there as well.

I probably wouldn't name a future value testing for the Forward button "back-and-forward", tho; that implies we'd need "back-and-reload"/etc too. At that point I'd just make a note in the feature that it's expected that, if the MQ is positive at all, 'back' will always match in addition to whatever other button keywords match.

[mgiuca]

I probably wouldn't name a future value testing for the Forward button "back-and-forward", tho; that implies we'd need "back-and-reload"/etc too. At that point I'd just make a note in the feature that it's expected that, if the MQ is positive at all, 'back' will always match in addition to whatever other button keywords match.

Sounds reasonable. Or, for more future-proofing, we could just drop the whole idea of it being used in a Boolean context, and say "you must explicitly check for "back"."

[fallaciousreasoning]

Or, for more future-proofing, we could just drop the whole idea of it being used in a Boolean context, and say "you must explicitly check for "back"

This seems pretty reasonable to me.

[ewilligers]

There is interest in implementing this behind a flag.

[fantasai]

Seems reasonable to me. If we add the ability to check for more buttons, they should be additional values that can be combined by the user, not new keywords representing each possible combination.

Also, question: should this be nav-controls to match the naming scheme in https://drafts.csswg.org/css-ui-4/#keyboard ?

[grorg]

While technically that counts as interest, it only seems to be one person :)

I have some comments I just made on the CSS call.

• I don't like the idea of "button". You're really talking about navigation functionality. That could be a swipe, glance, keyboard command, etc. To some level of exposure, which might not be obvious.

• The embedded web view may not know what the hosting application/environment does. In that case we'll have to default to things pretending to be there.

• It should not be restricted to back button. Knowing if a share button is present is also valuable (and would potentially avoid a lot of content embedded in the page).

[css-meeting-bot]

The CSS Working Group just discussed Proposal for Navigation Controls, and agreed to the following:

• RESOLUTION: Add navigation controls media query to MQ 5
• RESOLVED: Add navigation controls media query to MQ 5

The full IRC log of that discussion

<AmeliaBR> Topic: Proposal for Navigation Controls

<AmeliaBR> github: https://github.com/w3c/csswg-drafts/issues/4187

<AmeliaBR> TabAtkins: Request for a way to tell if there is a back button or similar (e.g., PWA shells don't always have this), as a media query. Normal browser it would be true. PWA may be false, so you might want to add a back button in your page UI.

<florian> q+

<AmeliaBR> … For now, the request is only for back button, but the proposal is designed in an extensible way.

<AmeliaBR> dino: I don't understand the scope of "back button". Would a back-swipe gesture count? Generally support the idea, but we need to define it.

<AmeliaBR> … I can also see other use cases, like is there a share button?

<myles> Q+

<AmeliaBR> TabAtkins: Question on back swipe is interesting. Not all UI options are equal. Keyboard controls might not be well known. But depends on the platform.

<jensimmons> +1 to being generic... not too focused on How People Do Things in 2019.

<AmeliaBR> dino: That's just an example. My concern is that the query should focus on the functionality rather than the "button" nature.

<astearns> ack florian

<Rossen_> q+

<dino> oops. forgot about queuing :) sorry.

<dino> i just bullied my way in

<AmeliaBR> florian: Individual parts of the media query are useful. But how would it be collapsed to a boolean level, without breaking extensibility?

<astearns> ack myles

<AmeliaBR> TabAtkins: Current proposal is boolean means any navigation control, of which back button is the simplest. If we can't make that assumption, that the boolean mode is probably meaningless.

<AmeliaBR> myles: Some browsers are designed as standalone apps; other browsers integrate with a system, like an iOS webview. Whether there's a backbutton or not depends on the embedding app. Webview doesn't know, may be difficult to implement.

<AmeliaBR> TabAtkins: In that case, if the rendering agent doesn't know, they should probably be conservative & assume there isn't anything.

<AmeliaBR> florian: And maybe embedded web views could add an API for the environment to tell them if they're handling navigation.

<AmeliaBR> myles: that doesn't help with existing apps

<astearns> ack Rossen_

<AmeliaBR> florian: But it could help in combination with sensible defaults.

<AmeliaBR> TabAtkins: And the default wouldn't be any worse than today.

<AmeliaBR> Rossen_: Is there a reason we're only talking about back button right now & not navigation controls as a group?

<AmeliaBR> TabAtkins: No reason to avoid other features. It's just that back-button has the strongest use case & is the one that is most commonly available.

<AmeliaBR> … But I made sure syntax would work with other buttons, too.

<AmeliaBR> q+

<AmeliaBR> … If we find anything that is really important we can add them too.

<drousso> q+

<AmeliaBR> Rossen_: If we are only doing back-button for now, why not just use that in a boolean sense?

<AmeliaBR> … I didn't want "any"/"none" because that could be more complicated for adding things.

<fantasai> ScribeNick: fantasai

<fantasai> AmeliaBR: Would a URL bar be included inside this general concept of navigation controls?

<fantasai> TabAtkins: If people think that's a useful thing to expose, sure

<fantasai> TabAtkins: number of possibilities we could

<fantasai> AmeliaBR: URL bar allows copy/paste of current URL and also allows navigation

<fantasai> AmeliaBR: also can be used to share

<drousso> dino i am too

<fantasai> TabAtkins: Interesting question of whether that should be distinct from share button

<astearns> ack AmeliaBR

<fantasai> florian: Wrt URL bar, I could imagine a UI which has URL bar only but not back button

<AmeliaBR> ScribeNick: AmeliaBR

<fantasai> florian: so assumption of always having a back button might not be correct

<AmeliaBR> TabAtkins: Theoretically, but I don't think that will happen

<AmeliaBR> florian: without a time machine

<astearns> ack drousso

<AmeliaBR> drousso: One clarification: Are we talking about the presence of these buttons, or whether they are enabled? E.g., in a new tab, back button is disabled.

<AmeliaBR> TabAtkins: I could be convinced either way, I think it's best to say "is it present", regardless of whether currently disabled. Probably don't want to toggle this on and off a lot. Might be used via JS to download extra scripts.

<AmeliaBR> AmeliaBR: What is the request at this time?

<AmeliaBR> TabAtkins: To add to draft. Can discuss specifics later.

<AmeliaBR> astearns: Any objections to adding to a media queries draft?

<AmeliaBR> (silence)

<AmeliaBR> RESOLUTION: Add navigation controls media query to MQ 5

<tantek> tries to catch up

<fantasai> RESOLVED: Add navigation controls media query to MQ 5

<AmeliaBR> astearns: We should also get in touch with the original proposer (fallaciousreasoning) for giving credit.

[mgiuca]

Thanks CSSWG for discussing it.

A few comments on this:

@grorg :

I don't like the idea of "button". You're really talking about navigation functionality. That could be a swipe, glance, keyboard command, etc. To some level of exposure, which might not be obvious.

Actually, I think this is more useful if it does focus on the presence of an actual visible button, or to generalize that slightly, an "obvious user-agent-supplied control for navigating back", as opposed to a "hidden" control such as a swipe gesture or keyboard shortcut. Because the intention of this query is that it's used to show or hide a highly-visible in-page control for navigation, you want to show the in-app control if there is no other obvious mechanism for navigation (even if there is a hidden one), but hide it if there is another obvious mechanism already present.

To make this concrete: in Chrome PWA windows, we currently do not show the back button anywhere in the window controls, but we _do_ allow back navigation using the Alt+Left keyboard shortcut. Since Alt+Left is fairly undiscoverable, we often receive reports that there is no way to navigate back (even though, technically there is). In these cases, we want sites to be given the signal _to show_ their in-app navigation control, to provide an obvious mechanism to the user.

Basically, the spec language doesn't need to explicitly mention a "button", but it should distinguish between obvious vs non-obvious mechanisms.

@grorg :

It should not be restricted to back button. Knowing if a share button is present is also valuable (and would potentially avoid a lot of content embedded in the page).

Similarly, this would be good but only if it was an obvious mechanism. On Chrome, we currently have user-agent-supplied Share functionality but it's hidden in an overflow menu. Arguably the entire utility of the Web Share API is giving sites the ability to put an easily discoverable Share button in their site, as opposed to being hidden away on an overflow menu.

But if a PWA window had a big share button right in the title bar, arguably you wouldn't need to put a Web Share button in your site; just rely on the discoverability of the obvious share button. So ideally, the media query would return "true" if there's an obvious share button in the title bar, but "false" if there's only a share button hidden away in a menu.

Ultimately, it would be at the discretion of the user agent to determine what "obvious" and "non-obvious" means, but the spec should give some examples (gestures, keyboard shortcuts and functionality inside drop-down menus would be "non-obvious").

astearns: We should also get in touch with the original proposer (fallaciousreasoning) for giving credit.

Please credit me (mgiuca@ / Matt Giuca) too :) Since I was the original original proposer; @fallaciousreasoning converted it into a formal proposal to the CSSWG.

[tabatkins]

Actually, I think this is more useful if it does focus on the presence of an actual visible button, or to generalize that slightly, an "obvious user-agent-supplied control for navigating back", as opposed to a "hidden" control such as a swipe gesture or keyboard shortcut.

As I elaborated a bit, I think if the gesture is a natural, widely-known thing that you can expect users to know exists and use, then it would suffice for the purpose of this MQ - you don't need to provide your own in-app Back functionality.

But that's definitely not true on Android devices, and I'm not familiar enough with iOS ones to know if their swiping does indeed meet those (rather stringent) requirements. But yeah, I agree that things like keyboard shortcuts do not meet this bar. (I personally use Alt+Left as my primary Back mechanism when on a keyboard, but I know I'm a tiny minority.)

Ultimately, it would be at the discretion of the user agent to determine what "obvious" and "non-obvious" means, but the spec should give some examples (gestures, keyboard shortcuts and functionality inside drop-down menus would be "non-obvious").

Yes, sounds good.

Please credit me (mgiuca@ / Matt Giuca) too :) Since I was the original original proposer; @fallaciousreasoning converted it into a formal proposal to the CSSWG.

Will do. ^_^