Fixed navigation/header and keyboard scrolling

Question

Page scrolling using the keyboard (PgUp/PgDown, Space) sometimes gets difficult if there are elements with fixed positions at the top of the page, e.g. navigation bars: content that was not visible at the bottom of the viewport might be hidden by the fixed elements after scrolling.

How to address this problem? Do browsers calculate, how far they should scroll? I observed different behaviors for different browsers and also for the same browsers on different pages (for example, Firefox leaves about 80px of old content on http://www.sueddeutsche.de/, but far less on http://www.taz.de. Chromium leaves much more content.).

Is this a problem at all, i.e. does anybody beside me use the keyboard to scroll a web page? Do you know any statistics?

To illustrate the problem, I created a Fiddle: https://jsfiddle.net/x7hj8c4m/ Try to scroll the content using Space on Firefox. The fixed element will cover text that was not yet visible before scrolling. If you add left: 0, it works.

Answer 1

Very interesting observation.

Firstly, pressing space is equivalent to pressing PgDn. And when PgDn is pressed, the page should scroll vertically by roughly "one page's worth of px". As shown by the OP's fiddle, Firefox in particular calculates this value differently, depending on whether it detects a fixed header.

From my own tests on IE, Chrome, Firefox, I deduced that:

• Without a position: fixed element, Chrome and IE scroll down by ~87.5% of the document height; Firefox scrolls down by document height - scrollbar height - ~20px.

• With a position: fixed; width: 100% element at the top-left of the screen, Firefox intelligently understands that the element perceptually reduces the document height, and so applies: document height - scrollbar height - fixed element height - ~20px. The condition appears to be quite specific: the element must be fixed exactly at the top-left of the document's box model with full width in order for it to work. The other browsers (Chrome, IE) don't perform such compensation, and performs the standard 87.5% scroll.

I don't know if this is relevant, but it might have something to do with support for position: sticky.

Answer 2

Scrolling by keyboard is a pretty basic behaviour that probably doesn't interact too much (if at all) with the DOM, so expecting it to account for fixed elements is probably too much. There seem to be browser-specific predefined increments (I have no idea if or how they can be customized), but note that the increments are usually smaller (presumably small enough) when you use the up/down arrow keys.