One of the primary challenges of designing for mobile devices is that screen real estate is often in limited supply. Through the advocacy of Luke W and others, we’ve drawn comfort from the idea that this constraint ends up benefiting users and designers alike, from obvious advantages like portability and reach, to influencing our content strategy decisions through focus and restraint. But that doesn’t mean we shouldn’t take advantage of every last pixel of that screen we can snag!
As anyone who has designed a website for use on a smartphone can attest, there’s an awful lot of space on mobile screens dedicated to browser functions that would be better off toggled out of view. Unfortunately, the visibility of some of these elements is beyond our control, such as the buttons fixed to the bottom of the viewport in iOS’s Safari and the WebOS browser. However, in many devices, the address bar at the top can be manually hidden, and its absence frees up enough pixel room for a large, impactful heading, a critical piece of navigation, or even just a little more white space to air things out.
So, as my humble contribution to this most festive of web publications, today I’ll dig into the approach I used to hide the address bar in a browser-agnostic fashion for sites like BostonGlobe.com, and the jQuery Mobile framework.
Surveying the land
First, let’s assess the chromes of some popular, current mobile browsers. For example purposes, the following screen-captures feature the homepage of the Boston Globe site, without any address-bar-hiding logic in place.
Note: these captures are just mockups – actual experience on these platforms may vary.
On the left is iOS5’s Safari (running on iPhone), and on the right is Windows Phone 7 (pre-Mango).
BlackBerry 7 (left), and Android 2.3 (right).
WebOS (left), Opera Mini (middle), and Opera Mobile (right).
Some browsers, such the default browsers on WebOS and BlackBerry 5, hide the bar automatically without any developer intervention, but many of them don’t. Of these, we can only manually hide the address bar on iOS Safari and Android (according to Opera Web Opener, Mike Taylor, some discussion is underway for support in Opera Mini and Mobile as well, which would be great!). This is unfortunate, but iOS and Android are incredibly popular, so let’s direct our focus there.
Great API, or greatest API?
As it turns out, iOS and Android not only allow you to hide the address bar, they use the same JavaScript method to do so, too (this shouldn’t be surprising, given that they are both WebKit browsers, but nothing expected happens in mobile). However, the method they use is not exactly intuitive. You might set out looking for a JavaScript API dedicated to this purpose, like, say, window.toolbar.hide(), but alas, to hide the address bar you need to use the window.scrollTo method!
window.scrollTo(0, 0);
The scrollTo method is not new, it’s just this particular use of it that is. For the uninitiated, scrollTo is designed to scroll a document to a particular set of coordinates, assuming the document is large enough to scroll to that spot. The method accepts two arguments: a left coordinate; and a top coordinate. It’s both simple and supported well pretty much everywhere. In iOS and Android, these coordinates are calculated from the top of the browser’s viewport, just below the address bar (interestingly, it seems that some platforms like BlackBerry 6 treat the top of the browser chrome as 0 instead, meaning the page content is closer to 20px from the top).
Anyway, by passing the coordinates 0, 0 to the scrollTo method, the browser will jump to the top of the page and pull the address bar out of view! Of course, if a quick call to scrollTo was all we need to do to hide the address bar in iOS and Android, this article would be pretty short, and nothing new. Unfortunately, the first issue we need to deal with is that this method alone will not usually do the trick: it must be called after the page has finished loading.
The browser gives us a load event for just that purpose, so we’ll wrap our scrollTo method in it and continue on our merry way! We’ll use the standard, addEventListener method to bind the the load event, passing arguments for event name load, and a callback function to execute when the event is triggered.
window.addEventListener("load",function() {
window.scrollTo(0, 0);
});
For the sake of preventing errors in those using browsers that don’t support addEventListener, such as Internet Explorer 8 and under, let’s make sure that method exists before we use it:
if( window.addEventListener ){
window.addEventListener("load",function() {
window.scrollTo(0, 0);
});
}
Now we’re getting somewhere, but we must also call the method after the load event’s default behavior has been applied. For this, we can use the setTimeout method, delaying its execution to after the load event has run its course.
if( window.addEventListener ){
window.addEventListener("load",function() {
setTimeout(function(){
window.scrollTo(0, 0);
}, 0);
});
}
Sweet sugar of Christmas! Hit this demo in iOS and watch that address bar drift up and away!
Not so fast…
We’ve got a little problem: the approach above does work in iOS but, in some cases, it works a little too well. In the process of applying this behavior, we’ve broken one of the primary tenets of responsible web development: don’t break the browser’s default behaviour. This usability rule of thumb is often violated by developers with even the best of intentions, from breaking the browser’s back button through unrecorded Ajax page refreshes, to fancy momentum touch scrolling scripts that can wreak havoc in all but the most sophisticated of devices. In this case, we’ve prevented the browser’s native support of deep-linking to sections of a page (a hash identifier in the URL matching a page element’s id attribute, for example, http://example.com#contact) from working properly, because our script always scrolls to the top.
To avoid this collision, we’ll need to detect whether a deep link, or hash, is present in the URL before applying our logic. We can do this by ensuring that the location.hash property is falsey:
if( !window.location.hash && window.addEventListener ){
window.addEventListener( "load",function() {
setTimeout(function(){
window.scrollTo(0, 0);
}, 0);
});
}
Still works great! And a quick test using a hash-based URL confirms that our script will not execute when a deep anchor is in play. Now iOS is looking sharp, and we’ve added our feature defensively to avoid conflicts.
Now, on to Android…
Wait. You didn’t expect that we could write code for one browser and be finished, right? Of course you didn’t. I mentioned earlier that Android uses the same method for getting rid of the scrollbar, but I left out the fact that the arguments it prefers vary slightly, but significantly, from iOS. Bah!
Differering from the earlier logic from iOS, to remove the address bar on Android’s default browser, you need to pass a Y coordinate of 1 instead of 0. Aside from being just plain odd, this is particularly unfortunate because to any other browser on the planet, 1px is a very real, however small, distance from the top of the page!
window.scrollTo( 0, 1 );
Looks like we’re going to need a fork…
R UA Android?
At this point, some developers might decide to simply not support this feature in Android, and more determined devs might decide that a quick check of the User Agent string would be a reliable way to determine the browser and tweak the scroll value accordingly. Neither of those decisions would be tragic, but in the spirit of cross-browser and future-friendly development, I’ll propose an alternative.
By this point, it should be clear that neither of the implementations above offer a particularly intuitive way to hide an address bar. As such, one might be skeptical that these approaches will stick around very long in their present state in either browser. Perhaps at some point, Android will decide to use 0 like iOS, making our lives a little easier, or maybe some new browser will decide to model their address bar hiding method after one of these implementations. In any case, detecting the User Agent only allows us to apply logic based on the known present, and in the world of mobile, let’s face it, the present is already the past.
Writing a check
In this next step of today’s technique, we’ll apply some logic to quickly determine the behavior model of the browser we’re using, then capitalize on that model – without caring which browser it happens to come from – by applying the appropriate scroll distance.
To do this, we’ll rely on a fortunate side effect of Android’s implementation, which is when you programatically scroll the page to 1 using scrollTo, Android will report that it’s still at 0 because oddly enough, it is! Of course, any other browser in this situation will report a scroll distance of 1. Thus, by scrolling the page to 1, then asking the browser its scroll distance, we can use this artifact of their wacky implementation to our advantage and scroll to the location that makes sense for the browser in play.
Getting the scroll distance
To pull off our test, we’ll need to ask the browser for its current scroll distance. The methods for getting scroll distance are not entirely standardized across popular browsers, so we’ll need to use some cross-browser logic. The following scroll distance function is similar to what you’d find in a library like jQuery. It checks the few common ways of getting scroll distance before eventually falling back to 0 for safety’s sake (that said, I’m unaware of any browsers that won’t return a numeric value from one of the first three properties).
// scrollTop getter
function getScrollTop(){
return scrollTop = window.pageYOffset ||
document.compatMode === "CSS1Compat" && document.documentElement.scrollTop ||
document.body.scrollTop || 0;
}
In order to execute that code above, the body object (referenced here as document.body) will need to be defined already, or we’ll risk an error. To determine that it’s defined, we can run a quick timer to execute code as soon as that object is defined and ready for use.
var bodycheck = setInterval(function(){
if( document.body ){
clearInterval( bodycheck );
//more logic can go here!!
}
}, 15 );
Above, we’ve defined a 15 millisecond interval called bodycheck that checks if document.body is defined and, if so, clears itself of running again. Within that if statement, we can extend our logic further to run other code, such as our check for the scroll distance, defined via the variable scrollTop below:
var scrollTop,
bodycheck = setInterval(function(){
if( document.body ){
clearInterval( bodycheck );
scrollTop = getScrollTop();
}
}, 15 );
With this working, we can immediately scroll to 1, then check the scroll distance when the body is defined. If the distance reports 1, we’re likely in a non-Android browser, so we’ll scroll back to 0 and clean up our mess.
window.scrollTo( 0, 1 );var scrollTop, bodycheck = setInterval(function(){ if( document.body ){ clearInterval( bodycheck ); scrollTop = getScrollTop(); window.scrollTo( 0, scrollTop === 1 ? 0 : 1 ); } }, 15 );
Cashing in
All of the pieces are written now, so all we need to do is combine them with our previous logic for scrolling when the window is loaded, and we’ll have a cross-browser solution of which John Resig would be proud. Here’s our combined code snippet, with some formatting updates rolled in as well:
And with that, we’ve got a bunch more room to play with on both iOS and Android.
Break out the eggnog
…because we’re not done yet! In the spirit of making our script act more defensively, there’s still another use case to consider. It was essential that we used the window’s load event to trigger our scripting, but on pages with a lot of content, its use can come at a cost. Often, a user will begin interacting with a page, scrolling down as they read, before the load event has fired. In those situations, our script will jump the user back to the top of the page, resulting in a jarring experience.
To prevent this problem from occurring, we’ll need to ensure that the page has not been scrolled beyond a certain amount. We can add a simple check using our getScrollTop function again, this time ensuring that its value is not greater than 20 pixels or so, accounting for a small tolerance.
if( getScrollTop() < 20 ){
//reset to hide addr bar at onload
window.scrollTo( 0, scrollTop === 1 ? 0 : 1 );
}
And with that, we’re pretty well protected! Here’s a final demo.
The completed script can be found on Github (full source: https://gist.github.com/1183357 ). It’s MIT licensed. Feel free to use it anywhere or any way you’d like!
Your thoughts?
I hope this article provides you with a browser-agnostic approach to hiding the address bar that you can use in your own projects today. Perhaps alternatively, the complications involved in this approach convinced you that doing this well is more trouble than it’s worth and, depending on the use case, that could be a fair decision. But at the very least, I hope this demonstrates that there’s a lot of work involved in pulling off this small task in only two major platforms, and that there’s a real need for standardization in this area.
Feel free to leave a comment or criticism and I’ll do my best to answer in a timely fashion.
Thanks, everyone!
Some parting notes
I scream, you scream…
At the time of writing, I was not able to test this method on the latest Android 4.0 (Ice Cream Sandwich) build. According to Sencha Touch’s browser scorecard, the browser in 4.0 may have a different way of managing the address bar, so I’ll post in the comments once I get a chance to dig into it further.
Short pages get no love
Today’s technique only works when the page is as tall, or taller than, the device’s available screen height, so that the address bar may be scrolled out of view. On a short page, you might work around this issue by applying a minimum height to the body element ( body { min-height: 460px; } ), but given the variety of screen sizes out there, not to mention changes in orientation, it’s tough to find a value that makes much sense (unless you manipulate it with JavaScript).
Comments
Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.
Got something to add? You can leave a comment below.
21/12/2011
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.
Vote Helpful or Unhelpful
20/12/2011
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?)
Vote Helpful or Unhelpful
20/12/2011
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.
Vote Helpful or Unhelpful
20/12/2011
Very interesting!
But I thought the Safari toolbar was hiding automatically at page load.
Vote Helpful or Unhelpful
20/12/2011
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.
Vote Helpful or Unhelpful
20/12/2011
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)
Vote Helpful or Unhelpful
20/12/2011
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?
Vote Helpful or Unhelpful
20/12/2011
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 ;)
Vote Helpful or Unhelpful
20/12/2011
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?
Vote Helpful or Unhelpful
20/12/2011
@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.
Vote Helpful or Unhelpful
20/12/2011
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.
Vote Helpful or Unhelpful
20/12/2011
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.
Vote Helpful or Unhelpful
20/12/2011
@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.
Vote Helpful or Unhelpful
20/12/2011
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.
Vote Helpful or Unhelpful
20/12/2011
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?
Vote Helpful or Unhelpful
21/12/2011
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!
Vote Helpful or Unhelpful
21/12/2011
@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!
Vote Helpful or Unhelpful
21/12/2011
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.
Vote Helpful or Unhelpful
21/12/2011
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.
Vote Helpful or Unhelpful
21/12/2011
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?
Vote Helpful or Unhelpful
21/12/2011
@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.
Vote Helpful or Unhelpful
21/12/2011
Wait for Apple to set the bar as hidden as the default…I suspect some opinions may change then
Vote Helpful or Unhelpful
21/12/2011
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?
Vote Helpful or Unhelpful
22/12/2011
@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.
Vote Helpful or Unhelpful
22/12/2011
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.
Vote Helpful or Unhelpful
22/12/2011
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 :)
Vote Helpful or Unhelpful
22/12/2011
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.
Vote Helpful or Unhelpful
22/12/2011
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!
Vote Helpful or Unhelpful
23/12/2011
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
Vote Helpful or Unhelpful
29/12/2011
@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?
Vote Helpful or Unhelpful
03/01/2012
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!
Vote Helpful or Unhelpful
07/01/2012
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.
Vote Helpful or Unhelpful
Impress us