window.outerWidth in mobile browsers

╰+哭是因爲堅強的太久メ 2022-08-24 05:23 166阅读 0赞

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.

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.outerWidth`exactly 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 what`window.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.

[research]: http://tripleodeon.com/2011/12/first-understand-your-screen
[test page]: http://www.quirksmode.org/m/tests/widthtest.html