On Friday, I posted about some test cases and detailed how Mobile Safari handles redeclared assets in three situations on iOS. I did this to try to clear up the concern that using media queries led to compounding or unnecessary file downloads. There are specific cases, in older versions of the Mobile Safari, that raise valid concerns, but in most practical cases Mobile Safari’s behavior complements responsive web design (?) well. Mobile browsers have come a long way over the last few years.
Here are a few things to keep in mind:
Hiding Image Tags
You can hide an HTML tag, but you can’t prevent the asset from being requested. If you thought you’d just set that entire column of banner ads to display:none within your media query (or, simply, further down the cascade) to make a better experience for your mobile visitors, just know that, as of Mobile Safari 5.1, your audience still has to download each of the assets (e.g., images sourced in tags) that you’ve just hidden, and your advertisers might be paying for impressions you aren’t delivering.
Hiding Background Images
You can hide a CSS background image and prevent the asset from being downloaded by setting the element’s parent to display:none. Just remember, this doesn’t work if you hide the element itself. Setting the parent to display:none is an easy way to hide images without forcing pointless downloads. Mobile Safari exhibits this behavior as far back as I’ve been able to test (Mobile Safari 3).
Replacing Background Images
Another way to hide a background image is to set the background-image to ‘none’ on the element itself. Maybe you’d like to remove a background-image from your document’s, for instance. The initial asset will not be downloaded by iOS 5 Mobile Safari. This same behavior works if you’d like to declare an alternate background-image within your media query (e.g., replacing
You should be aware, however, that prior versions of the browser actually will download the initial asset as well as the one you declare further down the cascade. The only documentation I can find regarding this bug suggests all versions of Mobile Safari prior to 5 are affected, but I’ve seen conflicting results.
Declaring for Orientation
You can target an orientation (e.g., landscape), and the browser will only request that asset only if you start in or change to that orientation. This might be a rare situation, but it’s nice to know that, as of Mobile Safari 5, the browser will not request orientation-specific file(s) at initial page load if they aren’t needed. Being able to target iPhone orientation is new to iOS 5, so I haven’t tried testing anything other than Mobile Safari 5.
I’m being careful to specify Mobile Safari on iOS. I’ve tested WebKit on Android with similar results, but everything you see above has been confirmed by a small army of independent tests over time. On that note, I should formally thank Jason Grigsby, Tim Kadlec and Michael Lehmkuhl for confirming each of these test cases over the weekend and Ethan Marcotte for helping me focus the test cases in the first place.
Clearly, there are more devices and browsers to test against, but I’ll never get through them all. I plan to follow up with results from Android’s WebKit and Opera Mobile once I’ve had chance to further verify. If you’d like to check on your own, I’ve posted the files I used to test four of the scenarios. You’ll just need access to your log files (access_log in my case) to confirm which files are being requested by the browser. It probably goes without saying that you’ll need to clear data / cache between each test, but I’ve noticed that even that is sometimes not enough on older devices. If you do find further results, I’d love it if you’d ping me on twitter.
Just don’t let all these caveats bury how far mobile browsers have come and how ably they handle assets today. I hear mobile is going to be a big thing.