window.scrollTo() or: When to Stay Clear of User Agents
Post from January 24, 2012 (↻ August 16, 2013), reflecting Jens the Web Developer.
If you were to ask me whether you as a web designer or developer should tackle user agent issues, my answer was “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 for 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.
Due to the fact that you’re not working on user agents, you’re likely to base any attempt to change user agent matters on mere 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 hide 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 does a user benefit from such different behavior? Do you know with absolute certainty he does?
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, otherwise very 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 really is a problem, learn about any history behind it, and then reach out to 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 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 !