
Headroom.js – hide your header on scroll - WickyNilliams
http://wicky.nillia.ms/headroom.js
======
bbx
FYI, this UI pattern is called _" Quick Return"_:
[http://www.androiduipatterns.com/2012/08/an-emerging-ui-
patt...](http://www.androiduipatterns.com/2012/08/an-emerging-ui-pattern-
quick-return.html)

I had been looking for this pattern's name after having seen Chrome on Android
implementing it for their navbar. I find it useful on mobile where scrolling a
long distance can be laborious.

~~~
diminish
I guess "quick return" is a remedy for "infinite scroll" making you lose top
and bottom navigational elements, too.

~~~
k__
I liked the ExtJS4 implementation most.

They kept the data in a div with hidden overflow so you could alway see header
and footer (not that useful for mobile).

But they also deleted old nodes when they were far enough away from the
visible space in the div.

------
jblow
Just get rid of the damn headers. Users don't want them. They are just
misguided ways of trying to raise retention, but really what they do is make
your site less pleasant to use, which then makes me not want to come back
later.

~~~
chrismonsanto
I absolutely loathe fixed headers, but I think this script is pretty cool. The
headers stay out of your way when you are reading, and when you actually want
to use the navigation you don't have to scroll all the way to the top. I
really see no downside, except "more JavaScript." (People who are complaining
about JavaScript: you really aren't going to like the Web in 5 years)

~~~
goblin89
There are two kind of significant problems with headers that hide as you
scroll, in my experience. 1) You can't easily get to the navigation when you
_do_ need it—have to scroll up some uncertain amount that varies by site (this
unknown makes simply using scrollbars more reliable)—and 2) you get it when
you _don 't_ need it, as in you're simply scrolling back to reread a portion
of the text above.

In short, this element feels always somewhat out of user's control.

Much more usable on mobile would be putting such navigation in a kind of
sidebar that many apps already employ (often accessible by swiping from the
left edge of the screen), while on desktop a great solution is simple “top”
links, strategically placed.

Plain fixed headers, possibly somewhat collapsing in height as you scroll,
also seem better than vanishing headers from the point of control.

Unless there comes out some positive research on usability of this particular
UI element, I personally am not convinced.

~~~
WickyNilliams

        > Plain fixed headers, possibly somewhat collapsing in height as you scroll, also seem better than vanishing headers from the point of control.
    

That's doable with this library btw. What happens in response to scrolling is
entirely dependent on your CSS. So when scrolling down, have it apply a class
which reduces the height, and when scrolling up, restore the height.

Also, it's worth noting, that whilst the obvious use-case for the lib is
headers; it can be used on any element, to have it react to scroll direction
and distance. For instance, I've used it to make a sidebar fixed after
scrolling past a certain point on the page (classic sticky sidebar pattern).
Also, I've used it to only show a "back to top" link when a user is > 50% down
the page and scrolling up quickly - so unless you're deep in a page and
scrolling towards the top, the link will never be visible/distracting.

It works well for these scenarios too!

------
veesahni
From the tagline, I thought this was a joke.. since "hide your header on
scroll" implies default browser behaviour (i.e. position:static)

------
AlexanderZ
Great job! How about adding an option of showing the header when the users
moves the cursor to the top of the window? Just like
[http://lyst.com](http://lyst.com) are doing it.

~~~
cmpb
Ah, thanks for pointing us there. That's pretty slick

------
WickyNilliams
I've previously submitted this link, but given the interest in the pattern
with yesterday's article [0] I thought it appropriate to post again. Hopefully
someone finds it useful. Happy to answer any and all questions

[0]
[https://news.ycombinator.com/item?id=7799687](https://news.ycombinator.com/item?id=7799687)

~~~
eduardordm
It's pretty nice. In my ipad the header only shows/hides if I scroll up/down
AND stop touching the screen. Maybe that needs to be changed.

~~~
WickyNilliams
Unfortunately, this is a limitation of the scroll event on iOS. It does not
given intermediate results - like it's debounced - only firing the scroll
event when scrolling has stopped. This is a well-documented shortcoming of
iOS. As Apple puts it [0], "One-finger panning doesn’t generate any events
until the user stops panning—an onscroll event is generated when the page
stops moving". There is no workaround at the moment.

[0]
[https://developer.apple.com/library/safari/documentation/app...](https://developer.apple.com/library/safari/documentation/appleapplications/reference/SafariWebContent/HandlingEvents/HandlingEvents.html)

~~~
WickyNilliams
wiresurfer, don't understand why you were down voted into oblivion, but now I
can't reply to you. Anyway, massive thanks for that, really helpful starting
point

~~~
wiresurfer
Till the time its seen by the right pair of eyes :) Will try and see if I can
fork a version and add the "inferred " touchend hack to it. Have a good day.

------
dhawalhs
I haven't tried it out, but this is how you make it work with bootstrap 3

[http://stackoverflow.com/questions/20648451/how-do-you-
use-h...](http://stackoverflow.com/questions/20648451/how-do-you-use-headroom-
js-with-bootstrap-3-navbar)

~~~
Theodores
Thankyou so much for that.

I had got as far as including animate.css in trying to get things working and
I was just about to write here about how it didn't bl00%y work!!! All is
working now, thanks for your well-spotted tip.

------
keeran
When I scroll away from the top of the page it makes the header disappear,
then reappear when I scroll back up to the top of the page.

Isn't that what scrolling does? :)

~~~
Zarkonnen
This is what scrolling does. But this option is fancier and IMHO pointlessly
visually distracting.

~~~
sredmond
I really enjoy this feature because it gives users who read long posts
(especially on mobile) quick access to the navigation bar when they need it,
but without the screen-hogging characteristic of older position:absolute nav-
bars. With regards to the visual distraction, I find that I almost never
scroll up unless I'm done reading. Continuously scrolling down feels natural,
and in this case, the header will stay hidden regardless.

------
pyrocat
Kind of odd that if you scroll slowly the header never disappears.

~~~
WickyNilliams
That's intentional actually :) The library allows you to supply a tolerance
value, to reduce sensitivity of the effect. On the project site, I have it set
to 5px (i.e. you must scroll > 5px for the effect to trigger). You can try out
the various options in the interactive playground [0]

[0]
[http://wicky.nillia.ms/headroom.js/playroom/](http://wicky.nillia.ms/headroom.js/playroom/)

------
hiphopyo
See [http://ux.stackexchange.com/questions/57990/how-usable-
are-b...](http://ux.stackexchange.com/questions/57990/how-usable-are-bars-
that-disappear-reappear-on-scroll) for more.

> I admit, it's quite genius. And I bet that if Apple could, they would have
> patented it.

------
callinyouin
I really, really like this behavior on mobile, especially on sites that
dynamically load new content as I scroll down. I honestly don't understand the
harsh criticism I'm seeing in the comments here, because this really is a
super functional way of giving the user easy access to navigation controls
without having to scroll all the way to the top of a page. That said, I
suppose I can understand criticism if this were being used in cases where
there generally wasn't a lot of content to scroll through. I guess my point
is, like all design decisions, it completely depends on the use case as to
whether or not this is useful or functional.

------
benaston
Great, so having previously suffered a rash of sites that permanently took up
valuable vertical screen space with fixed headers, they now will all have
headers that disappear whenever you scroll down and appear when you scroll up,
with slightly buggy behavior on iOS. Has anyone considered what non-technical
users will think of this UX idiom?

The effect is exacerbated on mobile devices whose browser chrome follows this
very same idiom (for arguably better reasons - at least it's not buggy). So
you now have two "competing" user interface effects.

------
filearts
Whether or not you are a fan of disappearing/reappearing headers, this is
clearly a well-thought-out bit of code that will be useful to someone. The
docs also appear clear and concise.

I like that it is not a jQuery plugin by default, but does provide the option.
Even better (for me) is an Angular directive ready for immediate integration.

Well done and keep up the good work!

~~~
WickyNilliams
This is my preferred way of developing JS stuff. Build an object that you can
use in pure JS, then integrations with other frameworks are nothing more than
simple wrappers around that object. Check the code for the jQuery plugin [0],
it's tiny!

By the way, I'm not an angular user, the directive was added through a PR. If
you hit any problems or have any suggestions to improve it, please get in
touch on github!

[0]
[https://github.com/WickyNilliams/headroom.js/blob/master/src...](https://github.com/WickyNilliams/headroom.js/blob/master/src/jQuery.headroom.js)

------
OutThisLife
What's the point of this?

~~~
sehr
To only engage the header when you're scrolling up? Identical to the way
Safari on iOS handles it.

~~~
mrweasel
And this is good because?

I don't get the point of this, you get pretty much the same thing by doing
nothing. Fix the menu to the top of the page, when you scroll down it goes
away, scroll back up and there it is. Almost no one is going to care that
they'll need to scroll back to the top, I'm sure of it.

~~~
wallawe
From HN front page yesterday: [http://usabilitypost.com/2014/05/24/the-scroll-
up-bar/](http://usabilitypost.com/2014/05/24/the-scroll-up-bar/)

------
automatthew
Once upon a time, there was a town that had a severe rat problem. They
imported a large number of cats, and soon the rats were gone.

Now the town had a cat problem. They imported a large number of dogs, and soon
the rats were gone. But now they had a dog problem.

The town imported a large number of lions...

------
yogo
It would be nice to have it where after scrolling up it can disappear after a
certain amount of time. Very useful for scrolling back up to re-read
something, versus scrolling up for navigational elements.

------
asadlionpk
Facebook should implement something like this for their mobile site. When I
have scrolled too deep into the newsfeed, I find that refreshing the page is a
better option than trying to scroll back up.

------
ottertown
I really like this but I wish the documentation included recommended DOM
structure / css styles... it's not as plug and play as the docs suggest

------
felipebueno
I don't like fixed headers at all and I dislike even more fixed headers that
hide on scroll... it's too distracting and useless.

A couple of years ago, when fixed headers became "cool", I'd write scripts for
Greasemonkey just to get rid of them. Today I'm too lazy for that :D.

But nice project.

------
thathonkey
Didn't work in iOS Chrome or Safari (the header remains fixed at the top
regardless of scroll behavior).

Cool effect for desktop but if you can get it working as a responsive solution
I think it would be a lot more useful to people!

~~~
WickyNilliams
See my other response
([https://news.ycombinator.com/item?id=7805748](https://news.ycombinator.com/item?id=7805748)).
This is a shortcoming of iOS, it works perfectly on other platforms.

IIRC, you reduce the tolerance value (an options you can pass to headroom) it
will work on iOS also, it just isn't quite as sensitive as it should be. I'm
waiting for my development iPhone to charge so I can confirm this. I'll report
back :)

~~~
thathonkey
Ah. I'm not super familiar with that "bug" \- is it that "touchmove" events
don't get fired for single-finger scrolling (panning)?

Perhaps you could make it work (albeit less gracefully) in iOS by reconciling
the header visibility state once "touchend" finally gets fired though?
Assuming "touchstart" gets fired as you'd expect, you can do a bit of manual
calculation to determine if the y-position changed enough to warrant header
hide/show.

~~~
WickyNilliams
To be honest, when i first developed the library I didn't have an iOS device I
could test with, so just went with the simplest solution (that is, not do
anything :D). Also, I'd always kind of viewed it as a progressive enhancement
- if it doesn't work, it's still a fully functional header.

However, now that I have an iOS device (which is still charging!), I should
spend some time seeing if I can get it to work better there. I'll look at
various touch events as you suggest. Currently it only listens to the scroll
event

------
cvrajeesh
Completely hiding the main navigation bar - is this a UX problem?. Now I have
to scroll back again to top just for seeing the navigation bar.

Minor tweak will be to allow swiping from top to show it or when user moves
mouse to top.

~~~
tomhschmidt
Did you even try it? The header reappears when you start scrolling up - no
need to scroll back to the top.

------
pwenzel
Disa-pp-pp-pp-ointed by the lack of Max Headroom references on the linked
site.

------
vitalus
Didn't test it as much in other browsers, but seemed to be buggy w/ Safari
7.0.1 on OS X - wasn't seeing the header appear again while scrolling up.

------
lukasm
Here is an example with bootstrap 3
[http://firestartr.co/](http://firestartr.co/)

------
druska
I hate the design of disappearing headers.

------
filipedeschamps
This is why I love open source. Amazing job, congratulations.

------
alttab
Why an entire js dependency for what can be accomplished with 10 lines of
jquery?

~~~
filipedeschamps
Isn't jQuery a huge dependency?

~~~
alttab
Sure, but it provides more features than headroom.js.

