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

Hi Aaron,

> I feel like you’re arguing two sides here, but maybe I’m misunderstanding.

I'm not arguing two sides. I'm acknowledging that there is merit to your philosophy of ensuring that everything works without JS, and always using JS to set up JS-dependent features so if JS is disabled, the site still falls back gracefully. However, this is one philosophy; there are merits to both. We, as the web platform, have no right to **force** that philosophy on web designers.

I do understand that JS doesn't always load when a website loads. However, to be realistic, modern "web apps" (as opposed to web pages) are basically going to be non-functional without JS. It's up to each individual developer to decide whether to "noscript-proof" their site if they think they can get sufficient functionality when JS is disabled, or just assume JS as a basic requirement. The former approach will require more resources, more careful design, more testing, etc, so this is not a trivial decision. **We should not be forcing this decision on developers by deliberately designing the platform to require JavaScript for things that don't strictly need JavaScript.**

To add to what @dominickn is saying about the situations where this can change dynamically (without a page reload):

> 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).

This isn't true. The Web App Manifest is only [applied](https://www.w3.org/TR/appmanifest/#dfn-apply) when the app is installed and running in a stand-alone window, but the Web App Manifest spec is still relevant in a normal browsing context. The [`beforeinstallprompt`](https://www.w3.org/TR/appmanifest/#dfn-steps-to-notify-that-an-install-prompt-is-available) event and the [`display-mode`](https://www.w3.org/TR/appmanifest/#dfn-display-mode-0) media feature are two such examples.

> As in watching a fullscreen video or something? Based on my experience, it’s incumbent on the developer ...

That's not what I mean. I mean that shifting into and out of full screen mode may change whether the user agent or operating system is showing a back button. The developer may accordingly wish to have their in-client back button appear at the same time as the external back button disappears due to full screen. (Of course, you can't just query for full screen mode changing, because that doesn't *guarantee* the OS hides the back button.)

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

That's an assumption about user-agent-specific UI. Edge PWAs on Windows physically show and hide the back button as the history stack becomes empty/non-empty.

A non-comprehensive list of actual cases **that exist in some browser today** where the non-client back button visibility can change without a page load:

* Entering and exiting full screen (all browsers).
* Installing an app (on Chrome OS — automatically reparents the web contents into an app window without a back button without reloading).
* "Pop out" / "Pop in" UI (on Chrome OS — a menu item allows the user to manually move the web contents into an app window and back into a browser tab without reloading).
* History stack changing (on Edge — the back button is shown/hidden depending on the contents of history).

Some hypothetical other cases:

* An OS like Android might show a back button in portrait but not landscape mode, so changing the device orientation may affect this flag.
* A desktop browser might show a back button unless the window is too small, so resizing the window may affect this flag.

User agents are allowed to dynamically show or hide the back button, so we (the web platform, and web developers) need to allow for that.

Now I want to point out that you made an assumption (that the back button state doesn't change without a page load) that's provably false. Many web developers far less thoughtful than you will make this same assumption, which, if they just query using JS on page load, would result in buggy sites that don't dynamically change their back button visibility as the non-client button visibility changes. The JS approach requires site developers to think about this scenario and write correct logic to deal with it. The CSS approach does not — it's declarative and will always be correct without complex logic.

Aaron, I see you have an impressive track record in arguing to developers that they should build "noscript-proof" websites. I'm all for you continuing that fight, but this is not the right arena. It's good advice for developers, but it isn't a "one size fits all" solution that should be baked into the web platform, and it just doesn't make sense to me to start by carving out a little exception in the ability to detect a back button.

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