window.outerWidth in mobile browsers

http://www.quirksmode.org/blog/archives/2012/03/windowouterwidt.html

Yesterday I finally researched window.outerWidth/Height in the mobile browsers, and here are my conclusions.

A few months back James Pearce published research that shows that the use of window.outerWidth on iOS devices allows you to read out the true orientation; something that screen.width does not.

Yesterday I came to the conclusion that this is far and away the most interesting use window.outerWidth has, and that James also missed a completely idiotic effect that Apple provides. The rest of the browsers are much more boring in their implementation.

Results

So what do browsers think window.outerWidth means? Nobody will be surprised that they come to different conclusions.

0

The Nokia browsers, Symbian and MeeGo WebKit, always give it value 0. This is not as odd as it may seem: they obviously don’t think that window.outerWidth has anything to add that web developers need; and I tend to agree with them.

Equal to screen.width/height

BlackBerry OS 7, Android 2.1 on HTC Legend, iOS (but see below), Samsung Dolfin, and webOS 3.0 all make  window.outerWidthexactly equal to  screen.width. This, too, is understandable.

Available width and height

BlackBerry OS 6 & PlayBook, Android 2.3 on Nexus One, Android 3 for tablets, Opera, and Firefox see  window.outerWidth as a sort of available width and height: the screen dimensions minus the space taken by browser toolbars. This, too, is defensible.

Gibberish

IE and UC (latest versions, both) return gibberish, as they do with all width-related properties.

I don’t know what to make of this, especially because I don’t know whatwindow.outerWidth is supposed to measure. As far as I can see web developers do not need the information it currently provides, and right now I also don’t have an obvious bit of information that it should provide. So I’m undecided and will not judge these results in terms of compatibility.

Apple weirdness

Then we come to iOS 5 on the iPad 2. In unzoomed pages,window.outerWidth gives screen.width. Nothing special here.

Now open the test page on your iPad (or iPhone), zoom in, and refresh the tests. You’ll see window.outerWidth report impossibly huge values; values that appear to have nothing to do with the page’s dimensions.

What I think is happening here is that Safari reports the total width and height of the page in device pixels. That is, when the user zooms in the total page gets “larger,” and Safari measures this larger page as if it’s using fixed, physical device pixels. Thus the width of the page easily reaches a few thousand pixels with a bit of zooming.

And no, this behaviour doesn’t make any sense whatsoever.

Don’t bother

In conclusion, I feel that web developers and browser vendors should not bother with window.outerWidth. It gives no useful information, and there is no useful information that it could give, either. So I suppose I side with Nokia: 0 is the best possible value for this property pair.

I’m open to arguments to the contrary, though. If anyone figures out what we should do with window.outerWidth I’ll give the proposal serious attention.