Solving the Problem with Sticky Headers

If you know me, you may know I don’t like sticky headers. They deny content much-needed room to flourish, and more often than not they’re blaring brands and social call-to-actions. But this isn’t the main reason I don’t like them.

The main reason: readability. Sticky headers make it harder to read by effectively changing the height of the viewport without telling the browser. Browsers use their internal measurement of the viewport’s height to determine how tall a “page” is, which it uses to determine how far to scroll when a user hits the space or page down keys.

Here’s a diagram of a normal pagination event:

how browsers handle pagination by default

The box is the viewport, and the red line is the last thing a reader sees before triggering a “paginate down” event. The browsers’ pagination logic is designed so the red line is also the first thing the reader sees after their eyes scan back up.

Now look what happens when a sticky header enters the picture:

the effect of sticky headers on native pagination behavior

Because the effective height of the viewport is being altered by the sticky header, it means not only is our red line totally obscured but so are two other lines we haven’t even seen yet. The reader now has to scroll back up to see what they missed (if they even notice).

Take over pagination from the browser and do it yourself.

I’ve released a little script on GitHub that does that just that.

Originally published at

A List Apart (ISSN: 1534–0295) explores the design, development, and meaning of web content, with a special focus on web standards and best practices.