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

> Just because a button requires JS to run doesn't mean detection or rendering needs to happen in JS?

You’re correct; it doesn’t necessitate that you inject it via DOM APIs, but it is a best practice to not include JS-dependent buttons (or other interactive elements) *before* you know they can actually be used.

When dependencies are not met, you introduce both UX and accessibility issues. Enabling this feature in CSS is not, in and of itself, an issue. People could still code defensively and avoid these issues. _But_ it does make it far easier to do the wrong thing, encouraging designers to include the button in their markup by default, relying on CSS to sort out whether it should be displayed, ignorant of the fact that the JavaScript dependencies the button relies on may not be met *and* that some user agents visiting the page without support for the CSS feature would display the button by default. Sure, you could set the default `display` state to "none" in CSS and then show it only when you know there is no native back implementation shown, but a quick survey of what developers actually do (and tell others to do on Stack Overflow) shows this more defensive, user-friendly approach is more the exception than the rule.

So why not approach this in such a way that encourages developers to do the right thing™ from the start rather than crossing our fingers and hoping for the best?

FWIW, I gotta imagine the CSS-in-JS folks would probably dig this approach too.


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