Fixed navigation / title and scrolling keyboard

Scrolling a page using the keyboard (PgUp / PgDown, Space) sometimes becomes difficult if there are elements with fixed positions at the top of the page, for example. navigation bars: content that was not visible at the bottom of the viewport can be hidden by fixed elements after scrolling.

How to solve this problem? Do browsers calculate how far they should scroll? I observed different types of behavior for different browsers, as well as for the same browsers on different pages (for example, Firefox leaves about 80 pixels of old content at http://www.sueddeutsche.de/ , but much less http: //www.taz .de . Chrome leaves much more content.).

This is generally a problem, i.e. Does anyone near me use the keyboard to scroll a webpage? Do you know any statistics?

To illustrate the problem, I created a script: https://jsfiddle.net/x7hj8c4m/ Try scrolling through the contents using Space in Firefox. A fixed item will span text that was not yet visible before scrolling. If you add left: 0 , it will work.

+7
javascript html css browser
source share
2 answers

Very interesting observation.

Firstly, pressing space is equivalent to pressing PgDn . And when the PgDn button is pressed, the page should scroll vertically about one page equal to px. As shown in the OP script, Firefox, in particular, computes this value differently, depending on whether it detects a fixed header.

From my own tests in IE, Chrome, Firefox, I realized that:

  • Without the position: fixed element, Chrome and IE scroll down ~ 87.5% of the height of the document; Firefox scrolls around the height of the document - the height of the scroll bar is ~ 20 pixels.

  • In the position: fixed; width: 100% element position: fixed; width: 100% position: fixed; width: 100% in the upper left corner of the screen, Firefox reasonably understands that the element perceives the height of the document, and therefore it applies: document height - scroll bar height - fixed element height - ~ 20 pixels. The condition looks very specific: the element must be fixed exactly in the upper left corner of the model of the document window with full width for it to work. Other browsers (Chrome, IE) do not perform such compensation and perform a standard scroll of 87.5% .

I do not know if this is relevant, but may have something to do with position: sticky support.

+4
source share

Scrolling through the keyboard is a fairly common behavior that probably doesn't interact too much (if at all) with the DOM, so expecting it to take into account fixed elements is probably too much. It seems like certain predefined browser increments (I have no idea if and how to configure them), but note that when using the up / down arrow keys, the increments are usually less (presumably small enough).

+3
source share

All Articles