Note: This techniques in this article are now out of date due to various changes to iOS Safari and Chrome becoming the default WebView for Android.
When building mobile web apps there is often a desire to try and make it look and feel as “native” as possible. Whether it is the styling of components, the use of transitions, or just general speed and performance, actually achieving these things can often be much more difficult than it first seems. This article explains some of the challenges we faced when trying to implement one of these “native” features - a fixed header.
Normally you would expect fixed headers to work by setting their css to
position: fixed; which works in most of the cases except for when you need to type something in a form element. Almost all mobile browsers push your page up to make room for the keyboard and your text element to be on the screen thus pushing your fixed header out of the way. This is a bad user experience because headers in mobile applications are the entrypoints for most user interactions.
When developing the chat page for our Hot or Not application for iOS we ran into the same problem. Here is an example of what it looks like:
Demo Make sure you are viewing the demo page in a mobile browser to actually see it work
Before we start to fix this problem there are two things we need to do first.
Hide the browser address bar
If a user is visiting your website from a mobile browser, you can hide the address bar in certain cases to give you more screen space. There are plenty of good solutions you can find on the internets that will help you do that. For the sake of our demo we will use the snippet below.
Remove the user interaction delay on mobile browsers
In short, the mobile browsers have a noticieable lag (~300 milliseconds) from when you tap on something to an action being taken for that tap. That’s because the browser is waiting to see if you wanted to do a double tap. This shouldn’t have been an issue if mobile browsers respected the
device-width property better. Chromium has a ticket and a patch for it already.
In the meanwhile we have to fix this because if you let the browser delay you for that long, it’s already too late and your page would have begun it’s scroll animation.
As well as removing the delay for click events, FastClick also speeds up focus events on form fields. The snippet below is a very simplified version of what’s going on inside FastClick.
Now to prevent the page from scrolling, we have to listen to the
window.onscroll event and set the scroll to 0 everytime it happens to prevent the browser from moving the page.
So on the focus of an input element we prevent any kind of page scrolling, and enable it back when the user has finished typing. Here is how it looks like now:
Well that wasn’t very helpful was it? The keyboard completely hides our input when it comes up because we didn’t let it scroll. To fix that problem we simply have to measure the amount by which our page scrolled when the user input came in focus, that will tell us the height of the keyboard so that we can move our input element into the view manually.
Let’s see how that looks now:
Great Success ! We now have a fixed header.