Hacker News Reader

Comment by mortenjorck | Hacker News Reader

Number five is the rule that’s being broken by an increasing percentage of the web without any custom scrolling at all: Every site with a sticky top bar breaks spacebar / pgdn scrolling by covering up the top few lines of text after a full-page scroll, requiring the user to back up a few lines to see what was hidden.

There should be a fairly straightforward Javascript workaround for this, intercepting the spacebar or pgdn keys to scroll the height of the unobstructed viewport instead of the full viewport, but I haven’t seen anyone implement it (I’ve been considering creating my own open-source library for it but I have no experience managing an OSS project).

Still, I wouldn’t consider that ideal, and maybe it’s time for some standards action. Here’s my proposal:

  body {
  	scroll-offset: 72px; // body will page-scroll 72px less than the window height to compensate for the sticky header
  }

View on HN

> There should be a fairly straightforward Javascript workaround for this

There is. Sort of.

It's a javascript bookmarklet I named "FIXEDFIXER" that lives on my bookmark toolbar:

    javascript:(function()%20{%20var%20s,e,i,ee=document.getElementsByTagName('*');%20for(i=0;%20e=ee[i];%20i++)%20{%20s=getComputedStyle(e);%20if%20(s%20&&%20s.position%20==%20'fixed')%20e.style.position='static';%20}%20})();

Changes all elements with "position:fixed" into "position:static". Works like a charm.

In my experience this little line of code fixes at least 90% of all my scrolling/coverup/screen estate problems. Sometimes the "position:fixed" element actually disappears, but I've been using this tool for over a year, and I have never had anything disappear that I actually wanted to see, read or use. (funny how that's a lot like the popup-windows on the web of old)

Curious to see how this works out.

Let me know! I use and tested it for Firefox, but I guess it should work the same in Chrome. Also if there aren't any copy/paste errors from my bookmarks toolbars to the code here. I use it myself at least a couple times per day (otherwise I'd probably have my bookmarks toolbar hidden per default).

I noticed a couple weeks ago that the New York Times website does this. Maybe not a coincidence that the article's author works there. :)

Yeah, the space up up combo is common. As long as we're fixing the problem, I've only got one small pet peeve. It's when you hit the bottom, and scroll back up, but the page was like N+.4 viewports tall, so now I'm between pages, until I scroll all the way up to reset the view. I wish it would scroll up just .4 viewports initially, just lift it off the bottom first.

I don't know if this problem is worth solving, but I've thought about it.

I have a more radical proposal, just hide all elements with position:fixed. I've never seen such elements contain anything useful anyway.

I've used a position:fixed form to create the input field for a downward-scrolling, bottom-affixed chat view (think Slack). I don't think they have any real use in web "documents", though.

This isn't even a problem though. Try pressing pgdn on any page with a fixed header. Modern browsers only scroll by 80% or so.

EDIT: why the downvotes? Try it yourself on http://legitmix.com

Browsers have scrolled less than 100% since forever, but there are differences. Most noticeably, Firefox scrolls (or used to scroll) more than Chromium, and has problems with content hiding more often.

I've found the best way to avoid downvotes on HN is to pose your assertion as a question (as sincerely as possible) :)

"This isn't even a problem though." -> "Is this really a problem? I thought that... correct me if I'm wrong!"

Your karma will move in the positive direction almost every time.

Yeah, it's generally a good tip for interaction in general, where constantly making assertions comes across as argumentative and annoys people who realise that not everything they say is a fact.

Downvotes are likely because one's brain learns, "After you hit the space bar, look at the top of the text you were reading, except 15% lower. That's where the next line will be." Sites screw with this assumption and become very hard to read - even if the text is all visible after a scroll.

Hear, hear! I've made this same complaint on this site many times, but less eloquently. I frequently use spacebar to scroll down one page. More and more I have to hit space, then up arrow a few times. :(

Space-scrolling doesn't work anyway, because when you're about to hit the bottom of the document, you don't know where to continue reading. If space-scrolling were smooth, this problem probably didn't exist. But still, in its current state, I'm not using it.

If it "were" smooth? It's smooth here... what browser/OS are you running?

Chrome on Mac, not smooth.

What site and what browser? My Chrome and Firefox understand position:fixed and it influences the amount the page is scrolled by.

Going back to my last complaint on this site: https://krrb.com/craigslist

Both IE and Chrome show the same behavior. My expectation on sites when I hit space or pagedown is to scroll down mostly one full page, leaving enough to get context of where I left off.This site scrolls past that point so I can't tell where I was.

Odd. I don't get the behaviour: http://imgur.com/a/zbZGE

Firefox on Linux

What version of Chrome/IE are you using? I see the correct behavior on both (Chrome 38 / IE 11 on Win 8.1).

Interesting. Chrome 38, IE 11 here as well.

>Number five is the rule that’s being broken by an increasing percentage of the web without any custom scrolling at all: Every site with a sticky top bar breaks spacebar / pgdn scrolling by covering up the top few lines of text after a full-page scroll, requiring the user to back up a few lines to see what was hidden.

I just find out that medium.com does it the right way!

Even better would be a way to set a meta attribute that defines this (visible-width) or something like that, so that browsers could handle it. This would be easier for developers, avoid breaking things in JS, and could keep any browser animations that happen on scroll, etc.

I can't reproduce this problem on chrome or firefox. Pgdn/spacebar do not scroll the entire page - they leave some room, and the top bar doesn't cover up any content. Are you sure you aren't thinking of browsers from years ago?

Chrome, for example, works as you describe on Windows, but scrolls an entire page on a Mac.

This explains a lot. Thank you. Do you happen to know why there is a difference?

I often see this problem manifest when clicking links to sections in the same document, e.g. from a table of contents on a long single-page article or documentation page.

Reply on news.ycombinator.com