“window.scrollTo()” or: When to Stay Clear of User Agents
This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.
If you were to ask me whether you as a web designer or developer should do anything about user agent issues, my answer was a clear “no.” It’s not your responsibility. You may lack important insight into decisions made on the user agent side. You’re going to inherit technical debt. You’re wasting your time.
An example of this can be found in the mobile realm where web developers use
window.scrollTo() to gently nudge away browser address bars on iOS and Android in order to free up screen real estate. “24 Ways” attracted attention promoting this approach.
Let’s use the
window.scrollTo() case as an example why web developers shouldn’t take on user agent duties.
You’re a web designer or developer. You’re working on websites, not user agents. The browser address bar is not part of a website, it’s part of the user agent. User agents play a crucial role in your work but they’re nonetheless not your concern.
Unless you’re working on user agents, you’re likely to base any attempt to change user agent matters on assumptions, not insight into why decisions have been made. In the address bar case, one motivation for manufacturers to show it persistently has been security. Security is then also a factor that needs to be weighed against any improvements you suspect, here: usability. Then, user agent manufacturers may already be working on the very problem, which has happened precisely with Android 4.0, which switched over to automatically hiding the address bar.
You may not be seeing the complete picture. Tackling a user agent issue on the website or app level can introduce inconsistencies that may be detrimental for the user experience. Why should something as fundamental as an address bar behave differently on different sites? How do users benefit from such different behavior? Do you know with absolute certainty they do?
You’re inheriting, in fact asking for, technical debt. Writing code is never a one-off thing. Writing the code itself has a cost (time you spend coming up with a solution or snatching it from a random site). Having the code sit in a code base has a cost (direct cost by its impact on performance, indirect cost by its impact on understandability and maintainability). Removing the code has a cost (once you don’t need it anymore or simply redo everything). In the address bar case there’s evidence that manufacturers are working on improvements (see Android 4.0). Add the speed in which the mobile landscape changes to this and it’s not a stretch to see you not needing your user agent issue “patch” anymore relatively shortly.
Taking all of this together it’s unnecessary, and costly, for a web developer to try to solve user agent issues. The best way to address user agent issues is on the user agent side. Someone identifying a problem should best confirm it is a problem, learn about the history behind it, and then reach out to the respective owners, for example filing bug reports or submitting fixes.
It always seems so simple: Identify a problem and solve it. We’re used to doing this. You have to know when a problem is yours though and when it’s not.
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
I really agree with you even though it’s hard sometimes to accept a user agent behavior with your website that’s not the way you want. And indeed, to change the behavior of each of the user agents or some of them would be too much costly. Instead of waiting for user agents changes, we have to suggest improvements or report bugs : that is the best thing to do.
“Instead of waiting for user agents changes, we have to suggest improvements or report bugs : that is the best thing to do.” Totally agree with you !
Maybe this is interesting to you, too:
- Next: Maintainability: One Story and Three Concerns
- Previous: My Year in Activities, 2011
- More under Web Development, or from 2012
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.