I agree it would be great in theory... but in practice there's a HUGE problem that the author doesn't seem to have considered: many webpages have footers. I'm talking about normally-positioned footers, not fixed-position ones. You're not supposed to scroll beyond a footer. It would look terrible. And you don't want to put extra space between the content and the footer either, or have that space vary. (How would you e…
> You're not supposed to scroll beyond a footer. It would look terrible. Like this? http://i.imgur.com/kFZSo.png
> You're not supposed to scroll beyond a footer. It would look terrible. Like this? http://i.imgur.com/kFZSo.png
I think he means like this: http://i.imgur.com/lWzkl.png
I was sort of making an implicit suggestion there—that maybe the over-scroll region, if implemented as Safari does it, doesn't look all that bad at all.
Safari in iOS handles this nicely. You can scroll below the bottom of the page and the default grey background _behind_ the page becomes visible. Desktop browsers could also do this.
This is the behavior in Lion as well for Chrome and Safari, not FireFox though.
One of the things I like about Readability is that space bar scrolling puts a blip on the side where my eyes can see where I should continue reading. I've never used the space bar to scroll elsewhere because the behaviour's too inconsistent.
Not directly on their own usability. It was more that they broke the web, since bookmarks, shared URLs, and search engines couldn't navigate them correctly to get the user back to the content that was supposed to display correctly. The static positioned content we get with CSS and JS hacks I've seen to replicate it a start but not always correct on it's own.
You're also forgetting links to external sites that didn't properly have a target, so they opened within one of the frames.
From the comments: 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.
Maybe I'm just getting old but I find any fixed elements on a scrolling page distracting. My brain expects the whole page to move when scrolling yet my eyes are drawn to this bit that is stuck in place. Also these fixed elements tend to be horizontal bars across the top or bottom of the page, reducing my reading area. That also sucks, especially since all laptop manufacturers decided we all should have super-widescre…
I think he means like this: http://i.imgur.com/lWzkl.png
I was sort of making an implicit suggestion there—that maybe the over-scroll region, if implemented as Safari does it, doesn't look all that bad at all.
It looks good! And the user won't mistakenly think that the web developer messed up on his footer design. The distinction between the website and what the browser is doing is clear by the relative depth positioning.
In the early years of the web I actually threw in a raft of tags at the bottom of my webpages just to counteract this problem---I've been complaining about it for upwards of fifteen years. My current solution is to put a "padding-bottom: 5in" in my #footer element, which is marginally cleaner, but of course it's specific to websites that I control....
I've had a similar gripe with scrolling, although I encountered with text editors instead of browsers. Having used Sublime Text for a while (which does what the article suggests and shows you as much white space as is needed to keep the display consistent), it is really jarring using many of the other editors which refuse to do this, especially as I often tend to write new code at the bottom of the page. Being forced…
Emacs does this, and so does Vim (I think). The main difference, I suspect, is that people who use Emacs and the like don't use their scroll-bars nearly as often as using a keyboard to get around; people using some of the other text editors, on the other hand, probably navigate with the mouse more. I think the behavior proposed here is oriented towards the former more than the latter, which would also explain the dif…
IIRC, Visual Studio does it too in some cases. You can't scroll past the end of the code, but if you jump to a point in the code, it will always put it at the top of the screen, and provide an overscroll area if necessary.
This seems like a piddling thing that belongs no where in the realm of the browser. This seems to be just about hitting page down. Which 99% of users don't do. They swipe, mouse wheel, my mom even clicks and drags the scroll bar. And for the 1% of you that this drives insane make a plugin that adds something like this to all your pages. As for anchor links you could easily add extra padding dynamically. body{ padding…
This actually works really well... I'm thinking there must be a way for Javascript to add some dynamic padding onto the body element based on viewport size and the position of the footer element.
