âwindow.scrollTo()â or: When to Stay Clear of User Agents
Published on Jan 24, 2012 (updated Feb 5, 2024), filed under development (feed). (Share this on Mastodon or Bluesky?)
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.
About Me
Iâm Jens (long: Jens Oliver Meiert), and Iâm a web developer, manager, and author. Iâve been working as a technical lead and engineering manager for companies youâve never heard of and companies you use every day, Iâm an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for OâReilly and Frontend Dogma.
I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)