Re: [w3c/manifest] Add a way to query whether there is a UA-provided back button (#693)

> You can match media queries in JavaScript with matchMedia. Note that you can also be notified through a MediaQueryList listener when changes happen.

@tomayac I know; it’s totally possible to control the display from CSS and to read that info from JavaScript. What I am arguing is that I don’t think CSS is the right place to define this. Looping in @mgiuca here too because I’ve not done a good job explaining the issue. I’ll try again.

If we implement the media query, designers/developers are encouraged to add the button into the markup and then toggle its visibility using CSS. The button itself requires JavaScript to function. In other words, **without JavaScript, the HTML-based button will not be able navigate the user backwards** (`onclick="history.back(-1)"`, etc.). JavaScript _is_ a prerequisite here; there’s no way to avoid using it.

There are a number of reasons JavaScript may fail to run or why CSS may fail to load. If either of those things happen, the presented document contains a button that either a) appears when it shouldn’t (CSS not loaded or this syntax is unsupported) or b) appears when it should but is non-functional (JavaScript not loaded or error experienced).

This thread began with a simple use case: Let’s find a way to make it easier for developers to determine whether the OS or hardware is presenting a back button so we can decide whether we should show one ourselves. Given that use case, this is a _programatic_ decision, the application logic—whether that’s in some front end framework or just plain old JavaScript—seems like the most appropriate place for it. And, if it were a JavaScript API, we can eliminate the [dependency issues](https://www.smashingmagazine.com/2016/05/developing-dependency-awareness/) that can cause a breakdown in the interface and a poor user experience.

Consider this hypothetical example:

```javascript
if ( "features" in navigator &&
     ! navigator.features.backButton ) {
  // add your back button to the DOM
}
```

With something like this in place, you can add whatever buttons you need to the interface based on querying for the existence of the hardware/os/browser feature first. That makes it possible to **avoid**:

1. Adding a button when it’s not needed
2. Having a button displayed when it shouldn’t be (and there’s a CSS issue)
3. Having a non-functional button displayed (and there’s a JS issue)

This also keeps the logic neatly in one place and could even lead to our ability to look at other potentially interesting things:

* `navigator.features.forwardButton`
* `navigator.features.shareButton`
* `navigator.features.urlBar`
* `navigator.features.tooltips`

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/693#issuecomment-402262114