How often do you really need to access the header and navigation "instantly"? In comparison, how often do you need to reread or verify information from a previous paragraph, or review a chart or graph you viewed earlier?

It's fairly obvious which one is actually more important in the majority of cases and it's going to be the actual information you're currently reading through. Obscuring the actual content in any form is a direct reduction to page usability.

I can access the header and navigation instantly by pressing the home key on my keyboard, or near-instantly by flicking my phone's screen downward a few times. Having a navigation header appear is like reading a book that covers half my eyesight with a hologram of the index every time I look at the previous sentence.

I read from the top of the screen and scroll the page so that I'm always reading at the same position without much vertical eye movement, and occasionally flick back a sentence or two for context, which is why it's annoying for me. For a reader who read down the page and occasionally scrolled it would be much less annoying.

It would be ok if the header was kept just above the viewport edge and kept there (ie. slowly getting into view) when scrolling up. You still have near-instant access to the header, but it doesn't jump out at you at the tiniest hint of scroll up. The problem with "scrolling back down to re-hide" is that most of the time, scrolling down enough to hide the header also scrolls the start of the content out of view. That means you need to scroll up enough to account for both the header height and the underlying, obscured content to stay within the viewport once the header disappears. I never once in my life got it on my first try, and it often takes 3 or even 4 tries to put the first line of the paragraph at the beginning of the viewport without it getting obscured.

To me, the idea itself is not that bad and there are some usability gains to be had, but the implementations are just horrible, lazy, and user hostile.

>I don't understand the hate?

Why is scrolling tied to changing the visible state of an interface element anyway? Scrolling down to hide and up to reveal /makes no sense/ to anyone other than the guy who wrote it (read: you).

Interface elements that pop in and out are /bad/, especially for people who aren't completely familiar with computers. Elements that change, especially ones that do so seemingly at random, are very disruptive, distracting, and hard to grasp.

An interface that is easy to understand and use has as few changing interface elements as possible, the more static the interface the better.

This method is just bad and annoying aff, even if that header makes sense to appear. Program in a hysteresis at least and only pop it up after 20-30% of upscroll.

Most implementations do the inverse: you overscroll a little, want to fix it, but the header appears. You want to scroll it away, but it persists for a while, so you lose track of where to start to make the line you needed to the top. Because user humiliation is a MUST for a modern site, I guess.

iOS Safari does it much better than a simple hysteresis for its URL bar, but I’m not sure web has enough event detail to implement its way: pull down does nothing, only “kick” down shows the bar.

I neither need nor want animated headers for anything ever. On mobile I can top the top of the screen to scroll to the top, and on PC I can use ctrl+home (on OSX Cmd+Home) or hold down middle mouse and speed scroll to the top.

The only thing that auto-hiding header does is cover up something I was trying to see.