Jens Oliver Meiert

“window.scrollTo()” or: When to Stay Clear of User Agents

Published on Jan 24, 2012 (updated Feb 5, 2024), filed under (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.

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

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

  3. 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?

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

Jens Oliver Meiert, on November 9, 2024.

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve worked as a technical lead and engineering manager for small and large enterprises, 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.)