Widths table

Vodafone

This series of compatibility tests is sponsored by Vodafone.

Blah

browser pixels -> CSS pixels system pixels -> device pixels
Property IE7 IE8 FF 3.5 Saf 4 Chr 3 Op 10 desktop Op 10 S60 Op 9.7 WinMob Op 9.6 Samsung H1 Op Mini 5 BlB Op Mini 4 S60 iPhone 3.1 Android 1.5 mob Android 1.5 desk Android 2 S60v3 S60v5 Iris Ozone Fennec b5 MicroB IE Mob 6 Black Berry NetFront 3.5 Samsung WM WebKit Obigo
screen.width and screen.height
 Yes brpx Yes sometimes Yes Yes Yes Yes

Gives the width and height of the screen in “system pixels.” These values should not change with zoom;

  • IE 8 uses browser pixels instead of system pixels; the value depends on the zooming. Note that IE8-as-IE7 behaves as IE8, and not as IE7.
  • Opera Mini does something weird whereby screen.width/height and window.innerWidth/Height sometimes contain the correct values, sometimes each other’s values, and sometimes weird values.
MQ device-width and -height
 No Incorrect Yes Yes No Yes Yes No Yes No

Uses the values in screen.width/height.

  • Firefox Desktop uses the values screen.width/height would have gotten if they’d used “browser pixels.”
window. innerWidth and -Height
 No Yes Incorrect Buggy sometimes Yes canvas Incorrect Yes Buggy screen Yes No Yes Almost Yes

Gives the width and height of the viewport in “browser pixels.” Should react to basically all kinds of resizes, including zooming.

  • All Operas use system pixels.
  • Opera Mobile 10 always uses the landscape values.
  • Opera Mobile 9.7 basically gives screen.availWidth/Height values (screen.width/height minus toolbars and such).
  • I don’t understand where Op Mobile 9.6 Samsung gets its values.
  • Opera Mini does something weird whereby screen.width/height and window.innerWidth/Height sometimes contain the correct values, sometimes each other’s values, and sometimes weird values.
  • All Androids except 1.5 in mobile mode give a huge height. This is the height of the canvas
  • S60v3 WebKit uses screen.height and HTML.offsetWidth.
  • I cannot interpret Ozone’s results. The height of 800px is clearly wrong.
  • Fennec gives back screen.width/height
  • I have my doubts about the H1’s innerHeight. The M1’s seems to be fine.
MQ width and height
 No Yes Incorrect Yes offset screen offset Yes offset Yes No Yes Buggy screen Yes No Almost No

Uses the values in window.innerWidth/Height.

offset
The browser uses the values of HTML.offsetWidth/Height to calculate the media query AND stretches up the height to improbable lengths.
screen
The browser uses the values of screen.width/height to calculate the media query.
  • Safari and Chrome Desktop use the values as if no zoom occurs. Thus the values will be wrong after a zoom.
  • Note that Opera Desktop, while giving window.innerWidth/Height the wrong values, nonetheless uses the correct, zoomed ones in order to calculate this media query.
  • I cannot interpret Ozone’s results.
  • The M1’s height is wrong. The H1’s is correct (although the window.innerHeight source data might not).
HTML. offsetWidth and -Height
 fixed Yes Yes 850 910 980 Yes 980 Yes 1008 800 Almost Yes Yes 800 innerWidth 345 Yes

Gives the width and height of the HTML element in “browser pixels.” Should either become smaller with zooming (desktop), or stay the same, if the minimum viewport is fixed (some mobile browsers).

  • IE 7 does react at all to zooming.
  • S60v3 WebKit leaves 6px for scrollbar.
  • IE Mobile 6 uses the width and height of the viewport in “browser pixels,” which the other browsers store in window.innerWidth/Height
Stretching
No No max. 1024 No Yes max. 850 No Untestable No body No max. 850 No

If we add a 1500px width to one of the elements, does the browser stretch up the HTML element or not?

  • Ozone doesn’t stretch anything, not even the element to be stretched.
  • IE Mobile 6 stretches the body, not the HTML. This is consistent with IE6 Desktop.
  • Samsung WebKit doesn’t unstretch the HTML element when I remove the width. Stays at 850.
  • Although the element itself is stretched in Obigo, you can’t scroll right (and thus you can’t see most of the element).
Viewport meta fixed
No Yes No Yes Alternative To be tested No Yes No Yes No Yes 
<meta name="viewport" content="width=380">

The HTML element is constrained to 380 pixels.

On the iPhone it’s not possible to zoom out beyond a width of 380px. On Opera it is.

  • Android treats this as the minimum width of the HTML element. Zooming out makes the HTML element larger.
Viewport meta device
No Yes Incomplete No Incomplete Alternative To be tested No Not sure No Not sure No Not sure 
<meta name="viewport" content="width=device-width">

The HTML element is constrained to the screen.width.

On the iPhone it’s not possible to zoom out beyond the device width. On Opera it is.

Incomplete
Browser always takes the portrait width, even when it’s in landscape mode.
  • Android treats this as the maximum width of the HTML element. Zooming in makes the HTML element smaller.
Default layout viewport width
 n/a 850 device? To be tested device 980 device 1008 To be tested device To be tested device 974 device

Is the layout viewport constrained by the device width, or does it take another width?
Property IE7 IE8 FF 3.5 Saf 4 Chr 3 Op 10 desktop Op 10 S60 Op 9.7 WinMob Op 9.6 Samsung H1 Op Mini 5 BlB Op Mini 4 S60 iPhone 3.1 Android 1.5 mob Android 1.5 desk Android 2 S60v3 S60v5 Iris Ozone Fennec b5 MicroB IE Mob 6 BlackBerry NetFront 3.5 Samsung WM WebKit Obigo