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

> Won't this be true for just about every element on the page? A modern webpage is bound to have dozens to hundreds of buttons on it that don't do anything if JavaScript is disabled or broken. In practice, it's essentially a requirement of the modern web that JS is working properly, so having an entire page of non-functional UI is a big problem, but it's rare or indicative of a bigger issue.

@mgiuca Sadly, many sites do assume JavaScript is a given. [It’s not](https://kryogenix.org/code/browser/everyonehasjs.html). There have been [numerous instances where](https://www.theguardian.com/technology/2014/jan/28/sky-broadband-blocks-jquery-web-critical-plugin) [a 100% reliance on/assumption of JavaScript has caused](https://www.google.com/search?num=30&ei=BG0-W6aiEvTi9AOpmaKIBA&q=jquery+cdn+https+certificate+expired&oq=jquery+cdn+https+certificate+expired&gs_l=psy-ab.3...11185.12372.0.12479.8.8.0.0.0.0.91.514.8.8.0....0...1c.1.64.psy-ab..0.7.463...33i160k1j33i21k1.0.S2SpntK7CKQ) [disastrous consequences for companies and their customers](https://blogs.wsj.com/digits/2011/02/07/gawker-outage-causing-twitter-stir/). As developers, we often [live in a bubble of high cost, high-speed, constantly-connected devices and we are often lulled into a false sense of security, thinking everyone is so privileged](https://www.smashingmagazine.com/2017/03/world-wide-web-not-wealthy-western-web-part-1/). But [that’s](https://www.reddit.com/r/webdev/comments/48z7jz/do_you_take_into_account_those_who_disable/d0nxftd/) [not the](https://twitter.com/philhawksworth/status/990890920672456707) [reality on the web](https://blockmetry.com/blog/javascript-disabled). And so it’s important to consider how our API design choices shape the way people build things for the web.

> but there are major downsides to this (UI loading in sporadically, not part of the initial page load). I'd say this is a fairly niche/extreme philosophy in an era where JavaScript is expected to always work. Most sites are just going to include UI elements in the base HTML. We should give developers this affordance for conditional UI like the back button.

I feel like you’re arguing two sides here, but maybe I’m misunderstanding. You’re saying that for many sites JavaScript is a requirement. To me, that seems to imply reliance on a front-end framework of some kind (without which the UI does not work). If that’s the case, most (or all) of the UI is already being rendered by JavaScript on the client side. Which means the JS API makes a lot of sense because the framework (keeper of the application logic) can make the determination as to whether or not the UI control is needed.

If, on the other hand, you are using a framework like Vue (which takes a more progressive enhancement-style approach), the markup does exist in the DOM, but the philosophy of Vue is to supplement the core, non-Vue experience with enhancements (which the Back button would be, since it is not needed on a normal website, only in an installed PWA context).

That last bit bears repeating: **the button(s) in question is only necessary in an installed PWA context**.

Regardless, even in situations where you aren’t relying on a frontend framework to generate (and maintain) the DOM, there are absolutely ways to render new controls into the page very quickly without causing weird experiences for our users. It also stands to reason that if you were planning to possibly render a back button (or similar) into your website’s UI, you would probably have already reserved the space for it in your design, meaning a late injection/render would not affect layout, only paint. It could even be faded in to further reduce the "pop in" effect.

CSS is great for doing a lot of things (including showing and hiding things), but this is one instance where I think JavaScript is the more appropriate venue.

> This isn't a feature detection (which implies a static feature that a browser either supports or doesn't). It's a dynamic property that can change, e.g., as the user installs the app and we pop out the browser tab into a window, as the user moves from normal to fullscreen, as the user pushes or pops history, etc. The same applies to the display CSS media query.
> 
> So this can't be as simple as if (navigator.features.installed) or if (navigator.features.backbutton). You'll need a) a method you can call to check whether it is currently visible (navigator.features.backbutton.isVisible()), and b) an event you can register to listen for updates to that state (navigator.features.backbutton.addEventListener(...)), then you'll need to implement an event listener to show/hide the button when the state changes.
> 
> Basically, CSS media query is perfect for this because firstly, all of the above machinery is already implemented and standardized (no need to invent new conventions for notifying when the state changes), and secondly, if all you want is a simple show/hide or enable/disable of a button, you can do it declaratively in CSS without writing any JavaScript (and maybe forgetting the event handler if the state changes).

Is it a dynamic property though? For @comp615’s scenario (`navigator.features.installed`), you either exist in an installed state or you don’t. That’s not going to change over the course of a browsing session. It’s also not going to change when you return to the PWA the next time.

As for the existence of a back button (or multiple kinds, to @comp615’s point), unless I’m missing something, that is also likely to be a static feature of the browsing context. If you’re in a browser or in an installed PWA rendered as "browser" or "minimal-ui," there’s going to be a back button (though it may be disabled on the `start_url`). In "standalone" and "fullscreen" it would not exist. In the PWA context, those rendering properties are statically-defined in the Manifest and are not dynamic. In most Android devices (and others), there’s also a hardware back button. That’s not dynamic either.

>  as the user installs the app and we pop out the browser tab into a window

Two different browsing contexts. The JS would be re-intepreted. No event necessary. Also worth noting: the web app manifest (which defines the display behavior of your app) currently only comes into play when the app is installed (the latter scenario).

> as the user moves from normal to fullscreen

As in watching a fullscreen video or something? Based on my experience, it’s incumbent on the developer to enable exiting fullscreen mode, usually by checking for the Escape key or supplying a "close" button (though I have occasionally seen a "window blinds" style control from the browser).

> as the user pushes or pops history, etc. 

The back button either exists or it doesn’t. It may shift from disabled to enabled, but only if it’s in the "browser" or "minimal-ui" context.

Can you provide any other examples where information like this might be dynamic? I’m having a hard time imagining a scenario.

-- 
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-402837565