@Mike Morici

1] setTimeout(fn, 0); sets up a timer. Timers fire as soon as they can. In this case, if the JavaScript engine is busy working on something, the timer is queued to fire as as soon as it becomes available. It’s like saying, “Let everything else finish, and then do this”. It’s a neat technique for waiting for other event handlers do what they have to do, before running your function.

2] It isn’t.

I would disagree with anyone about the ‘40px isn’t worth the effort’ response, especially if trying to type into a dialogue box while horizontal on a web page. That gives you a half inch of space to work with, and if you are reading any text, if there is a permanent footer as part of the design then that takes up space too.

It always seems like cautionary responses like these are to make ‘your’ life easier rather than your ‘users’ life easier. User testing on my own site, watching someone unfamiliar with the concept of full-page-scrolling and sliding, I often see them touch the address bar and inadvertently end up with a keyboard or other browser-ui action. I agree removing the bar permanently is bad, but sliding it out of the way to allow access to a full-featured site, and it’s there if you tap the time bar, is best for the users.

Users are smarter than we think, and they are smart enough to be annoyed at the things that annoy us, too.

Very interesting!
But I thought the Safari toolbar was hiding automatically at page load.

That’s quite a bit of code when a little redundancy will actually accomplish the same result:

<script charset=“utf-8”>
if (!window.location.hash && window.addEventListener) {
window.addEventListener(‘load’, function() {
window.scrollTo( 0, 1 );
window.scrollTo( 0, 0 );
}, false);
}
</script>

In Android it’s already hidden the address bar due to the first scrollTo call, and resetting to 0, 0 does not reshow the address bar, but in iOS, it is reset to 0, 0 as desired.

However, that being said, I agree that should probably only be used in rare cases.

Hey, everybody.

Thanks for chiming in! Sorry for the delay, I’m currently traveling and connectivity is spotty.

There are some good points made here. As I mentioned at the end of the article, the complexity of the code may convince you that it’s not worth the effort. Perhaps the caveats I highlighted in the article reinforced that decision. That’s all very well; at the least, I hope this article offers a slightly more defensive method for those already trying to implement the technique (which is very commonly done today with a simple unconditional scrollTo).

The comments about whether or not this technique is disorienting to users are certainly interesting. I’m just as eager to hear some user research on the topic as anyone! As a smartphone user myself, I’m not sure I’d agree. To my taste, this can add a nice – albeit minor – finishing touch to a web app that’s already optimized for use on my touch device. My opinions aside, the trends seem to be going in the direction of making web apps feel more like app-apps, so we’ll likely see more of this merging going on – if so, I’d prefer seeing standardization for a less hackish approach!

Anyway, I’ll try and address some of the unique points above.

- The meta tag “apple-mobile-web-app-capable” kicks in once a web[site|app] is bookmarked to the homescreen on an iOS device, so from a browser perspective, it doesn’t do much.

- @RUDIE: That’s a fair point. For what it’s worth, in jQuery Mobile we do keep track of scroll distance before changing pages, and always return to that spot when the user returns to that page. Unfortunately, this article was long enough already :)

- Matt: Yep, this purely just scrolls the chrome out of view. Try the demo page and you’ll see it’s all there when you need it. As you mentioned, there are more aggressive approaches out there to keep the address bar hard to access – I agree, they make no sense at all. Comparing this to disabling right-click, or “disabling” any feature for that matter, seems a little strong to me. ;)

- DAVID: heh, well, I guess you could make that argument. Nothing is being disabled or broken here though, and you can just scroll up the page to get the address bar again. I think there’s a fine line though: we commonly make enhancements on top of default browser behavior, such as handling a link via Ajax instead of a full page refresh.

- Dustin: Fair point! Though you’ll still need the other checks in there anyway (hash, scroll distance before load, etc)

For those only concerned with filesize, here’s a minified version. It’ll come across the tubes at around 200 bytes (not kb): https://gist.github.com/1504263

Whew sorry – that’s what I get for signing offline for a whole day! :)
Thanks!

@Scott very good point! The very same site I opted to remove this technique I am also hijacking links for modal/ajax content ;)

Which reminds me, experimentation leads to innovation far more often than conforming to boring “UX” norms. I’d much rather see articles like this than ones that say “users expect/prefer X” when they’ve never seen the wonders of Y. So I stand somewhat corrected! Though I’m not convinced on this specific technique, Im glad you’ve shared it!

ps. All of this “I think..” is largely pointless. Bring some data to an argument. Personal opinions don’t hold much water when talking/guessing about user behavior or preferences.

Thanks everyone. Great stuff, once again.

In reading these comments, I think my article probably argues too hard for this technique as a space-saver (40px or however much), when its potentially more interesting benefit is that it makes a web app feel more like a native app, with less browser chrome in your way. We all know the “fold” is not something we should ever dwell on, especially in the mobile world, and I didn’t mean to draw so much focus to getting your content above it (whatever “it” might be). :)

ART makes a valid point: this behavior is already commonplace in the browser’s default behavior, such as when a hash is present in the URL. It just doesn’t happen every time.

STEPHEN: thanks for answering Mike’s questions.

MIKE: The load event question is a confusing one, I’m not sure why the device prefers that the scroll occurs after the load event’s other-and-default scripting has completed, but I think it’s because load is the earliest the browser can reliably jump to a location in the document on its own (if a hash or previous scroll distance is remembered), since the height of the page is reliable at that point. Anyway, Stephen’s explanation of why the timeout helps there sounds good to me; the timeout of zero defers the scripting to execute asynchronously, which will be as soon as the other current synchronous scripting is finished. At one point, I tried removing the timeout and using event.preventDefault() just for kicks, but it didn’t seem to do anything.

MATT: no problem at all, I understand what you meant now :)

I really appreciate this article even though I’m not totally able to comprehend all of it. I’m not a programmer but I am responsible for a lot of sites. I seem to get a lot of different opinions on the matter and it is really hard to sort out.

Allow me to suggest that you guys do everything you can to explain the tech stuff to us not so tech savy in order to help us make the right decisions.

Thanks for sharing!

Great explanation and great code!
Thank you, I was going crazy trying to find something that would do that.

What about this in iOS?

<meta name=“apple-mobile-web-app-capable” content=“yes” />

(I know, that is lying a little, but probably better than another javascript shower?)

Maybe it’s just because I got my Galaxy Nexus running ICS less than 2 hours ago and I’m not even used to the browser yet, but I can say that the Boston Globe’s site does hide the address bar, but the “final demo” link does not appear to hide it like it does my iPod touch running iOS 4.2.

Thanks for sharing writing this article. Hiding the address bar is something I’ve always used this for –

window.addEventListener(“load”,function() {

setTimeout(function(){

window.scrollTo(0, 1);

}, 0);

});

Thinking that it’d be a ‘catch all’ but wasn’t aware of the caveats that you found whilst creating the Boston Globe site.

I think I’ll need to re-digest this article again as it’s full of so much code.

@24ways that’s another fine article you given us :o)

A very good article on a seemingly simple problem but quickly becomes complicated by the fact that each platform runs in its own way the controls of the browser. When will a unified interface, a kind of standard Firefox or Chrome?

This is definitely a dangerous script to put on a mobile website, you have to check every new mobile OS version released. This can be a real pain as you mentioned, confirmed by Peter-Paul Koch (quirksmode) tweets when testing mobile phone browsers.
Great tips anyway for giving a client what he wants ;)

Thanks for sharing, good to see such a comprehensive implementation.

Personally I’m not a fan of this technique. Its a whole load of effort with a lot of side effects (like the hash issue) and the outcome is not even flawless, visually I’ve found it rather annoying!

But more importantly you mentioned “don’t break the browser’s default behaviour”, surely this script is doing exactly that?

@Rudie perhaps check to see the current scroll offset and only fire the scrollTo event if the offset is less than the height of a typical menu bar? This should keep you in the same place on refresh unless you are very close to the top of the page already.

Although this is a smart piece of coding, I would never use it.

This presumptuous behaviour is exactly why I stopped using FaceBook’s mobile site – it’s so heavy on JS that it causes my iPhone 3G to lag, freeze, and crash. But because there’s no browser UI available I can’t do anything when it freezes. It makes the entire FB website unusable on my iPhone and means that when FB screws up I have to exit the entire application and start again in a new tab.

Hiding the toolbar on first load is fine, but there should always be a way of accessing it by simply scrolling back up.

We don’t mess with right-click menu’s for usability’s sake, and we shouldn’t mess with expected UI chrome either.

To clarify:

if this permanently gets rid of the UI then it’s bad. Facebook does this.

If you can still scroll up and get the UI then this is fine (although I’d question the value of it, and note that it smells a lot like a return to “The Fold” way of thinking).

I can’t quite figure out from the article which this would do.

@Matt Wilcox — This technique doesn’t permanently remove the address bar it attempts to scroll past it, but even that isn’t good practice for all the same reasons you’ve highlighted. I’d prefer not to make the expected/default browsing experience differ across websites with what is essentially a “hack”, even if it appears fairly harmless.

Mobile Safari does have a meta tag that hides the address bar entirely but only for websites that have been added to the home screen (as @Daan highlighted above). That allows “web apps” to be more app-like.

Having done some (admittedly very little) research into users expectations for this, we’ve actually found that most users are very unsure of what’s happened when the address bar is hidden.

It’s certainly confusing, they’re expecting a “web experience” when they browse to a site, even in their mobile browser, which means being able to easily move onto the next site. By hiding the address bar, we make this difficult for them…

I suspect the reason that there isn’t a direct API for manipulating the toolbar is that the OS developers don’t want this sort of technique to be achievable…

While I understand the desire to have greater screen real estate to utilise, does it outweigh the need for users to feel confident in what is happening with their device? And are we not bringing back to live stories of “the fold” if we answer that with a yes?

Just what we’ve found after deploying a few mobile sites and testing, but perhaps useful to know?

Changing a user experience for the sake of your site looking slightly better doesn’t seem a positive thing to do at all. Remember the days when it was the norm to create a popup for your site, make it full screen and remove the address bar so people couldn’t move away from the site? This is the mobile equivalent of doing that. I know you can still <em>access</em> the scroll bar, but anything that changes an experience away from the norm is a negative user experience.

Keep in mind that there will be such a low percentage of sites that will use this, so mobile users will be used to hitting a site and scrolling-down immediately without waiting for the whole page to load, they’re also used to seeing the address bar.

When I follow a link I could just as easily end up in the middle of a page (with hidden address bar) via location hashes as I could at the top (with address bar visible).

Is leaving someone at the top of the page with the address bar hidden really doing something the user doesn’t expect/know how to address? Users know how to get back to the address bar if they’ve scrolled down a page themselves (scroll back up), and they have to deal with this behavior from links that contain location hashes already.

As long as the JavaScript is robust enough to not break behaviors like scrolling to the top when a location hash is present, or after a user has manually scrolled beyond a certain distance, should it matter whether the experience is top of the page or middle of the page?

@Scott – thanks for the clarification :)

I wasn’t intending to compare this particular implementation with hiding right-click nav, though I see how it will read that way. My apologies. I meant permanent hiding is the same sort of thing.

Thanks Scott for going through this torturous experience for us and sharing your experience. The inconsistencies between browsers for something as simple as getting the scroll distance makes me want to pull my hair out.

I have two questions, and they might be simple to some but please chime in and enlighten me if you can thanks!

1] I’m confused on why setTimeout is needed on the window.load event.

2] If this script is inside the body tag why the need to check document.body?

Thanks Scott for this timely article. I’m just finishing a mobile version of a new website (mea culpa, not mobile-first approach, not responsive either) and I’ve implemented it that way.

If one’s heading for iOS and Android support, the following is enough:

/* Hides mobile browser’s address bar… */
function hideAddressBar()
{ if(!window.location.hash && !window.pageYOffset) setTimeout( function(){ window.scrollTo(0, 1); }, 50 );
}

/* when page is done loading… */
window.addEventListener(‘load’, hideAddressBar);
/* … or rotating */
window.addEventListener(‘orientationchange’, hideAddressBar);

Your code is way more complete, especially to support other platforms.

ABDELAZIZ: sure thing! Looks alright to me, assuming you’re okay with the 1px scroll in non-Android browsers. Good catch with the orientationchange addition – not a bad idea since it’s concise. One thing that caught my eye: window.pageYOffset will be undefined in some older browsers, like IE8 and older, pre-mango Windows Phone 7, and maybe others. In those cases, I think your check will return a false negative for scroll distance, and jump an already-scrolling user back to top.

Not sure if those browsers are on your radar, but worth thinking about. Thanks!

@Scott

If you view: http://help.apple.com/iphone/5/interface/ on your iPhone you will see that the address bar actually disappears which is much better than the technique you’re employing here. Thoughts?

As a user and developer I implore you, don’t use scrollTo. After refreshing a page, the user expects the page to end up where it was before (the browser remembers that), which is not necessarily at 0, 0. Definitely on a desktop (and how would a website know the difference). A decent browser hides the toolbar if there’s not excessive space. Otherwise the user can scroll. He’ll have to anyway.

Btw I never see the toolbar on my HTC Android unless the page is shorter than the viewport.

Honestly, I think this is way more effort than it’s worth.

First of all, most ‘normal’ users simply couldn’t care less about the 40px or so that the address bar takes up.

Secondly, most users won’t wait for the page to finish loading before they start browsing it. The number of times I’ve scrolled down half a long web page before it’s finished loading, only to be zipwired back to the top after a few seconds. It’s infuriating. I can understand the desire to make the site more immersive and content-focused, but is all this effort really going to pay off? You’ve got a lot of JavaScript to work around 40px of OS chrome, as well as some tricky UA sniffing for Droids etc.

In my opinion, it’s certainly not worth the effort.

Wait for Apple to set the bar as hidden as the default…I suspect some opinions may change then

Nifty & reliable technique; and I’d expect nothing else from you, Scott ;-)

To other commentators: whether one agrees with the purpose of not, I’d suggest the biggest lesson to take away from this article is the amount of pain required to make something (even as simple as this!) across multiple mobile browsers

What about Blackberry? I’ve been able to get Blackberry OS 6 with window.scrollTo(0,1000) — but OS 7 seems impossible. Its very relevant with the BlackBerry Bold too, since it has a tiny touchscreen.. touch-based web apps could use the extra 20-odd pixels killing the address bar would get.

Well – thanks for a super article….but why don’t the phone companies make the screen bigger within same phone size and use the screen as a touch screen instead of the buttons?
This would for certain give some more space for the screen.

Quite brilliant (and short) script for this behaviour – which I have never even noticed :-)

Two questions:
Since Android’s using the window.scrollTo(0,1) couldn’t you just add 1 unused pixels at the very top? I know it’s technically a waste of space, but 1px versus extra JS seems to me to be a fair exchange?

Also: How can this particular script be rewritten to take into account the user’s last position on the page? Rudie mentions it and you refer to jQuery Mobile UI – but what about those of us that do not use jQuery Mobile UI for development?

I’m no expert at javascript – I’m not even a beginner – so I hope that you’ll update this script accordingly :-)

/michael