We expect streams of text to scroll down in our browsers. But almost all of them scroll incorrectly.
Figure 1 shows a column of text; the grey bars represent the lines. The blue rectangle shows the area currently visible in your browser. The red line is the last one visible in the current screen, the green one the next one that would be visible were the window a little longer.
Figure 1: Before scrolling
Figure 2 shows what you expect to happen when you’re in this situation and you hit next-page or the space-bar; either option is acceptable. The top line visible in your browser window should be either the red or green line from the previous figure. Browsers do this well, and the eye knows where to go.
Figure 2: Alternatives after scrolling
But there’s a problem, illustrated in Figure 3, when you’re near the bottom of the page, so there’s not much left to display after the last line in the current window.
Figure 3: The problem case, before scrolling
When you’re in this situation and hit space-bar or page down, what you’d like to see is the exact same behavior, as shown in Figure 4; zero or one lines of overlap between screens.
Figure 4: How browsers should scroll near end of page
For some reason, browsers are reluctant to leave white space showing at the bottom of the window, so they refuse to scroll all the way up, as shown in Figure 5, leaving the last line you were reading stranded at some random location in the middle of the page.
Figure 5: How browsers do scroll near end of page.
When this happens, my flow of reading is disrupted because my eye doesn’t know where to go to pick up where I left off.
There’s another problem. If you link to a particular sub-heading in an article, using hash-fragments properly (unlike, for example, Twitter), the point you link to should show up at the top of the window. This same bug — the browsers’ refusal to leave room at the bottom of the window — means that it’s really hard to link effectively to an article’s conclusion.
To illustrate, here are two links into this an article on this blog. The first, to a section entitled The Index, works just fine. The second, to a comment about text browsers, fails miserably.
In many pages on the Web, this bug has become invisible because the actual content is much shorter than the sidebar and footer apparatus with which it is festooned, which carries on ad infinitum. On this subject, please read Brent Simmons’ The Readable Future.
Could this be fixed, please? It’s really OK to have some white space at the bottom of the browser window.
Comment feed for ongoing:
From: Ray Baxter (Nov 28 2011, at 08:49)
This problem has been around forever, but there is a new problem that makes scrolling even worse than before. Sites which have headers or footers that have a fixed position with respect to the browser viewport completely break scrolling because when you scroll, neither the red nor the green line are visible. The green line is under the navigation junk at the top of the page.
[link]
From: David Powell (Nov 28 2011, at 08:58)
If I have a page with fragment links in, I tend to add an @media screen style rule to add loads of padding to the bottom of the page to avoid that issue.
(Remembering to make it @media screen to avoid spitting blank pages out of the printer if someone tries to print it.)
[link]
From: Ciaran (Nov 28 2011, at 08:58)
I've never even noticed the first issue, so I can't see how it's a problem at all. Just me, maybe?
The second, linking problem, though - yeah, I've been hit by that many a time.
(As an aside, that's the second time you've had me click through to a Brent Simmons article recently. I mentally retitled this one "The Unreadable Future" and immediately hit the back button. See http://ciarang.com/posts/design-for-reading for the previous example, but this one was much worse.)
[link]
From: Julian Reschke (Nov 28 2011, at 09:00)
I prefer the current behavior over having whitespace where it doesn't belong.
[link]
From: Nelson (Nov 28 2011, at 09:01)
This drives me crazy too. Would a fix be as simple as a userscript / addon / extension that adds a bunch of whitespace at the very bottom of the page? May be a timing issue to fix the #anchor navigation, but it'd probably work for ordinary pages.
[link]
From: William V. (Nov 28 2011, at 09:13)
It's one of these things that have always bothered me but I never thought about it long enough to formulate the problem. Thanks.
Though I would argue that the display of hash-fragment links would still be insufficient, even if your fix was implemented. The browser should provide a clearer marker of the fragment you've linked to. Having that fragment consistently be on top of the page would be good, but not sufficient.
[link]
From: Jacek Kopecky (Nov 28 2011, at 09:22)
I first saw the way of scrolling you advocate when I started using VIM many years ago. It's a feature that still keeps bugging me.
For scrolling in a browser, I find myself almost never using page scrolling any more — a big touchpad or a smartphone screen let me scroll smoothly as I'm reading — I guess I'm reading scrolls rather than books. This way, I don't miss the empty space at the end, and I'd find it confusing.
I do agree, though, with the issue with linking to anchors near the bottom of the page.
Maybe the browser could only add the necessary extra space when scrolling by a whole page, and when scrolling to a low-lying anchor, but not when scrolling by line or smoothly with a trackpad, what do you think? For me, that would be a good middle ground implementation that would avoid the kind of annoyance I have with VIM.
[link]
From: Kevin H (Nov 28 2011, at 09:30)
I don't think it is fair to call this a browser bug. There are dozens of scenarios that come to mind where scrolling beyond the bottom of the page just doesn't make sense, and would "break the web". Not all websites are text on a field of white, with a top-image and a bit of sidebar content. Many good websites make good use of a footer at the bottom of the page...Should this footer float in space as you scroll beyond it?
And why aren't you practicing what you preach? A little CSS like body {margin-bottom:1000px} should ungracefully accomplish the type of scrolling you are proposing, and then that can be enhanced to exactly one screen worth of bottom margin with a bit of JavaScript.
[link]
From: Nelson (Nov 28 2011, at 10:10)
Someone called out this exact issue on Readability in July. It'd be pretty straightforward for them to add a blank page to their views, I suggested it.
http://readability.bonfireapp.com/ideas/view/253/the_last_page_is_too_hard_to_read
[link]
From: Chris Dary (Nov 28 2011, at 11:43)
Nelson, we at Readability tried to solve this with a little bit of a different approach - we fade in a bullet to the left side of the text and then animate the scroll (in all browsers except Safari, since it already animates its scroll).
The goal here being that it's a subtle placeholder, so that if you hit the bottom of the screen, you can quickly scan for the bullet and continue on. It's still a little jarring, but hopefully a bit better of an experience.
We love hearing feedback like this though. We'll consider other options.
[link]
From: Manuel Strehl (Nov 28 2011, at 11:56)
I’d like to second Kevin H. This isn’t a browser bug (anymore) but an annoyance introduced by careless web designers. If you create your pages in Photoshop only, you’re fast in missing simple usability.
The bottom margin can be easily extended with
body { margin-bottom: 90%; }
and all modern browsers support the CSS :target selector, so that we can highlight the current anchor, like the Python docs do it.
You just have to do it. And that is not the job of the browser vendors but of the web designers and “UI Experts” out there.
[link]
From: Kevin H (Nov 28 2011, at 12:05)
Also, for dealing with the fragment identifier issue: Within your own website you could apply some CSS styling using the :target CSS3 pseudoclass.
[link]
From: Nick (Nov 28 2011, at 12:20)
Lol....why don't you get it fixed in Android first Tim?
What you are describing is exactly the behavior when you call setSelection(position) on one of the last rows in a ListView being populated by a SimpleCursorAdapter.
In fact I was looking at it last night wondering why I should have to pad my database table with blank rows in order to get around the problem!
[link]
From: room34 (Nov 28 2011, at 13:48)
This is an interesting look at the problem of paged scrolling in web browsers. I've never perceived this as much of a problem because I don't read web pages this way; I NEVER hit the spacebar in a web browser, except by accident. I scroll continuously as I read, using the mouse, so the lines I'm reading are always in the top 1/3 or so of the page.
Why? I'm not quite sure how I acquired this habit, though I wonder if keyboard-centered Windows users favor the spacebar while mouse-centered Mac users favor the mouse. (The fact that Windows mice had scrollwheels long before Mac mice did would seem to undermine this theory.)
Anyway… it's just now occurred to me that part of the reason why I prefer to scroll with the mouse instead of reading a page at a time is precisely because the way browsers scroll pages is broken, just as you've described.
[link]
From: Bob (Nov 28 2011, at 14:01)
Tim, the problem is a little more complicated that you describe.
If we attempt to use your solution (add white space to the bottom of every page in HTML), then the natural question is: How much white space?
See, this varies based on the window size and other user selections (such as zoom level). The amount that you'd want to add is probably no more than one screen of whitespace. But how much is that?
Seems like this needs to be fixed in the browser, not at the server.
[link]
From: Mark Ransom (Nov 28 2011, at 14:04)
The problem is caused by the design of scroll bars. The scroll bar is meant to represent the entirety of a document, and when the handle is at the bottom of the bar the page should be at the bottom of the document. The scroll bar doesn't have any provision for extra white space at the bottom of the document, so it constrains the behavior.
[link]
From: Jan! (Nov 28 2011, at 14:12)
I remember old versions of IE (we're talking 4.0 or so) doing this, and everyone (including me) being upset because this broke designs. Of course, it could just be my memory playing tricks on me.
[link]
From: porneL (Nov 28 2011, at 15:02)
Here, I fixed it for you:
http://geekhood.net/linktargetwhitespace.html
(:target CSS selector + tall pseudo-element + optional tiny bit of JS to make it more precise)
Though I agree it would be better if browsers had that out of the box.
[link]
From: Edward Anderson (Nov 28 2011, at 15:20)
Chrome 15 solved / worked around this problem by smooth scrolling whenever you page up/down. Without the instant jump, the eye can easy tell where the page is compared to where it was before.
[link]
From: Homer (Nov 28 2011, at 15:34)
The new google plus "header" also ruins things, because it blocks the top text when you go a page down - which the browser dont know about, so the next line you're about to read is actually hidden.
[link]
From: Ben Kennedy (Nov 28 2011, at 16:12)
Speaking of usability problems due to bad design, none of your links is obvious, because:
- they are rendered with the same text decoration as the body text (i.e., no underline);
- they are rendered in a colour of similar intensity to the body text (red vs. black) that makes them blend in, particularly for colour-blind users.
In the absence of the stylesheet you created that expresses these choices, every browser would have displayed them in an obvious and usable way, by default.
b
[link]
From: David (Nov 28 2011, at 19:41)
Chrome extension to draw green line at last edge when paginating with space bar:
https://chrome.google.com/webstore/detail/bbohkppjclbafgnkekedkbaddggaefjh?utm_campaign=en&utm_source=ha-en-na-us-extensions-categories-google&utm_medium=ha
[link]
From: Sumo (Nov 29 2011, at 04:21)
This can be solved by:
1. Scroll animation. Firefox does this. Even though the animation is very fast you will most of the times see that only half a page was scrolled.
2. Overscrolling with some kind of spring that returns to the original viewport. Like iPhone does it. You can scroll beyond the visible area but as soon as you release your finger it will return.
3. Other visual indicators, i really like the dot in readability.
[link]
From: elv (Nov 29 2011, at 05:37)
If I remember correctly, web browsers around 96/98 did this. Possibly until Netscape 4 and IE4. At that time this behavior seemed weird and clients complained about the "big blank" at the end of some pages.
[link]
From: Jason Kostempski (Nov 29 2011, at 07:33)
As a web programmer, I for one am glad the browser doesn't make this choice for me. You can and should add the exact amount of white space you want to the end of a page where it makes sense to do so. The developer should be in complete control of what happens between the toolbar and status bar.
[link]
From: Charlie Harvey (Nov 29 2011, at 09:29)
I guess that does happen, I think I've used the body{ padding-bottom:100%; } trick before.
[link]
From: Jim d. (Dec 02 2011, at 10:24)
I disagree w/ Jason K.: the web developer should have no control over this behavior whatsoever. Scrolling behavior should be predictable and consistent, and you won't get that with fickle developers' varying opinions on how the their site should scroll on your browser.
[link]
From: Bill Eccles (Dec 02 2011, at 10:36)
As I pointed out last year here
http://www.bill.eccles.net/bills_words/2010/07/a-complaint-safari-reader-need.html
I don't particularly care what the behavior is for a webpage so long as Safari's Reader gets it right. It doesn't.
I, too, find the "Where the hell should my eyes go now?" to be frickin' annoying. Google Reader also gets it wrong, and there's no excuse there—that's entirely under their own control.
[link]
From: Andy Lee (Dec 02 2011, at 10:37)
Is it possible to use different CSS when printing than when displaying? If so, and you use the bottom-padding approach, make sure to remove the padding when printing to avoid unnecessary blank last pages.
[link]
From: Matt (Dec 02 2011, at 10:42)
This behavior used to annoy me quite a bit, but I found that once smooth scrolling became more mainstream it no longer bothered me. Since smooth scrolling provides continuity through motion, I find it easier to keep track of my position on the page, regardless of when scrolling finishes.
I'm with you on following links to anchor tags, however.
[link]
From: Allen Gainsford (Dec 02 2011, at 11:49)
Interesting. You're advocating a type of scrolling behaviour that I've always loathed. When I see the text ending, and a lot of white space below, my first thought is not, "that's handy"; it's, "oh, there must be even more that I haven't scrolled down to yet." Then I get mad because I can't scroll down any further, meaning that the application has lied to me.
Personally, when I find an application that adds fake white space at the bottom of a document, I scrap that application and get one that shows just the content that's actually there. The bottom of the text belongs at the bottom of the window.
[link]
From: Nera (Dec 02 2011, at 11:59)
Well, I know that problem although I most oftne scroll with my mouse wheel, so my eyes follow the last line. Actually I believe smooth, animated scrolling when hitting page down is the correct answer, id does not break the eye tracking.
That is a general rule in User interfaces: to have things move instead of magically pop. It may seem useless eye candy for some people, it may slow some things down if not done properly, but to me it is essential to maintain continuity of attention. After all in real life nothing ever "pops" from one place to another.
Now, that does not solve the hashtag problem. Although it is not so big a problem when it is used to jump to a h1 or h2 section title that is big and bold with the same text as the link.
For notes however it often happens, in particular since the only indication of where you wanted to go is a note number, who memorizes the note numbre before clicking ?
But I think putting them at the bottom and making the page scroll to look at them is absurd anyway, this is not paper anymore, notes should appear where they are called (through browser supported, user configurable "note" tags or something in an ideal world, since javascript in-page windows completely lack standards and configuration), not make you loose your page status by scrolling down.
Even thoses that have a link back to the text are bad, it will put the line originating the note on the top, often hidding the beginning of the sentence forcing you to scroll up again to resume your reading.
But I digress.
And you know what is bad too ? A web site where you comment on another page, making it complicated to go back to the text you comment on while you are commenting. :p
[link]
From: James Katt (Dec 02 2011, at 12:59)
I would not call this a bug.
This is a choice made by web browser developers on how to render web pages. From their point of view, there is a bottom to a web page, below which you can't scroll. This emulates paper pages.
You see the same effect on some word processors, particularly those which render the page how it will be printed. There is no white space because there is no more page past the bottom of a sheet of paper.
In designing web pages, I like having a bottom. Since I expect this, I can read just fine.
If you expect web pages to be able to scroll down forever, then yes you will have problems reading at the bottom since your expectations are different.
[link]
From: Michael A. Lowry (Dec 02 2011, at 15:57)
I thought of a solution to this problem a few years ago, and I’ve seen an e-book reader that implements something similar: after scrolling, the browser should just draw a line at the point that was the bottom of the page before scrolling.
http://blog.michael-lowry.com/2011/12/simple-solution-to-misscrolling.html
[link]
From: David Liu (Dec 02 2011, at 16:01)
James Katt: Except you can bring the bottom of the page physically up.
And not all essays end at the bottom of the page, so a page may have a completely blank space at the bottom after the last sentence.
[link]
From: Christian (Dec 06 2011, at 08:19)
I think the problem becomes relevant only in case of anchors. Now that browsers support animation while page scrolling, your reading experience shouldn't be so compromised.
There could probably be a rubber band effect in case of anchors so that they can be shown initially on top of the page and then animate gracefully where they usually are.
[link]
From: Steve Fink (Dec 07 2011, at 13:08)
I agree with the problem, but I'm not crazy about your solution. It breaks a different use of pagedown -- I'll sometimes press and hold pagedown to get to the bottom of a page (eg a bug tracker entry with tons of comments). In that case, I want the last full page, not the page height modulo display height.
I could use the 'end' key, but I don't much like using keys that wander around on different keyboards (page up/down are necessary, so I learn to deal with those.) Plus, home/end are too ambiguous in my brain -- do they mean horizontal begin/end? Vertical? Global? Scope-restricted (one wrapped around command-line, for example)?
Seems like you might be able to stick a temporary indicator into the scrollbar, though that overloads the meaning of its vertical dimension.
I think I like the horizontal line or bullet marker approaches best, personally.
[link]
From: choonkeat (Dec 14 2011, at 10:40)
Agreed, though bottom padding would be a tad too intrusive to page design.
Try shading instead http://vimeo.com/984913
(which you've actually inadvertently done in your illustration of the problem)
[link]
From: Benedikt Koeppel (Jan 02 2012, at 05:47)
Hi there
I wrote a little JavaScript library called "overleap.js" today. Please check it out on https://github.com/bekoeppel/overleap.js.
overleap.js adds a spacer div at the bottom of the page, with a dynamic height. On scrolling, the spacer is expanded and shrinked so that a full length page jump is always possible.
Regards,
Benedikt
[link]