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
"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.
More detail is available in the explainer
Note: Microsoft has expressed interest in experimenting with this API https://github.com/fallaciousreasoning/backbutton-mediaquery/issues/4
I’m not necessarily opposed to this, but couldn’t an alternative solution be some way to tell the user agent that it doesn’t need to render a back button if the app has its own?
I think this is part of a solution. Generally, we prefer not to tell browsers how their UI should look, so a spec for requesting buttons would probably say that a browser SHOULD show/hide a button, rather than that they MUST show/hide a button. In this case, I think the media query would still be useful to let sites know if the browser has respected their request.
We are considering an API like the one you describe (perhaps declaring buttons in the manifest) but we haven’t put together an explainer :).
This looks like a reasonable proposal to me. As a co-editor of Media Queries, I would encourage you to raise this as an issue against the specification, at https://github.com/w3c/csswg-drafts/issues.
(No strong opinion either way from me on the API)