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

Hi Charlie, thanks for stepping in.

> I would like to go one step further in this proposal and point out **it's important to us to differentiate the TYPE of back button provided**. For instance, the back windows provides in the nav bar is not useful. But if Android indicates it provides back as a hardware button, that may be more noteworthy.

Thanks for clarifying the difference between what you expect out of back buttons on Android vs other systems.

It sounds like, though, you don't _really_ want to know the "type" of back button (i.e., "hardware" vs "system" vs "browser") or something like that. What you want to know is: "is this the Android back button, which has special conventions attached to it, or is it like a normal browser back button?"

The scenario I'm afraid of is: We provide additional details like Chrome-on-Android returns "system" while Edge-on-Windows returns "browser", and developers start attaching Android-specific semantics to "system" (because it's currently the only OS that returns "system"). Then, in the future, "system" basically means "has the semantics of the Android back button". This is what I meant in the section "The Android Quirk" at the top of this page.

>From the cross-platform perspective, there is no meaningful difference between a "hardware", "system" and "browser" back button, even though those things might have specific meanings on specific platforms. So it isn't right for us to expose those differences to the site. What you really want to know is not "is this a system back button?", but "is this Android?" And you can do that by explicit user-agent detection.

> For CSS vs JS, I get that it can be exposed in either. I don't think doing feature detection via CSS is as common place as has been argued yet, even `display: standalone` CSS detection is tedious at best. We use it only to try and figure out if the user currently has Twitter "installed". I'd much prefer to have `navigator.features.installed` or something like that which is direct and to the point. Roundabout way of saying, ultimately we'll follow whatever, but **JS for long-term consistency** with other feature detections?

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

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