I'm writing a CSS book

JavaScript archives Compatibility CSS coaching Thidrekssaga QuirksBlog Donations Politics Mobile About COH

sitemapcontact

Preliminary meta viewport research

Just now I released my preliminary meta viewport research that studies the various permutations of the <meta name="viewport"> tag.

It’s preliminary because I tested it in only eight browsers instead of the customary 40, I did not yet test the @viewport CSS rule, and I’ll probably need some extra tests to cover edge cases. Still, I now have a pretty good overview of where we stand with regard to the meta viewport.

Browser notes

Before presenting the results, some browser notes. I tested in a healthy mix of rendering engines and device sizes, just to get a feel of the lay of the land and things to watch out for. This, I think, succeeded.

Android WebKit and IE have rather terrible bugs in their meta viewport implementation, so it’s safest to assume that anything I say below does not go for these two browsers.

Safari has annoying bugs where it uses the portrait size of several properties also in landscape mode. This is well-known, but I found that I got fed up with its behaviour during this research.

Chrome, Opera Presto, and BlackBerry support the meta viewport well, though each of them has tiny bugs here and there.

Firefox is untested because it still does not give the dimensions of the visual viewport in window.innerWidth/Height. Therefore I cannot read out the zoom factor, and about half of the tests are useless.

The third viewport

Ages ago I introduced the visual viewport and the layout viewport. The layout viewport is the one relative to which CSS declarations such as width: 20% are resolved, and you have several options of setting its width. The visual viewport is the one that matches the current zoom level; in other words, the area that the user currently sees on his device screen.

It turns out there’s a third viewport, which I call the ideal viewport. It has the ideal size for displaying web pages on the device. So for an iPhone up to 4S it’s 320x480, for an iPad it’s 768x1024 etc.

As you might have guessed, it’s this viewport that you invoke when you use width=device-width. As you may not have guessed, you also invoke it when using initial-scale=1.

Zooming

initial-scale, minimum-scale, and maximum-scale all give zooming factor relative to the ideal viewport. So on an iPhone 4S portrait, specifying initial-scale=2 gives a visual viewport width of 160px (320 / 2).

Also, this directive sets the width of the layout viewport to 160px. Weird, eh? Not what one would expect when setting a zoom factor.

So essentially the initial-scale directive also allows you to set the layout viewport width, just as the width directive does.

min-width

Things get interesting when you combine the two:

<meta name="viewport" content="width=400,initial-scale=1">

width=400 tells the browser to set the layout viewport width to 400px. initial-scale=1 tells it to set the width to the ideal viewport width. What is an honest browser to do?

It turns out that they use the largest width; calculated independently for portrait and landscape. So on an iPhone 4S this meta viewport gives a 400px layout viewport in portrait (largest of 320 and 400), and a 480px one in landscape (largest of 480 and 400).

This essentially means that there is a min-width for the layout viewport. The layout viewport is always at least 400px wide, but the browser may stretch it up if that’s fitting for the device and orientation.

I’m not sure if there’s a practical implementation for this min-width, and it certainly does not work in Android WebKit, but it’s interesting all the same.

Read it

These were the main conclusions of my research. There’s plenty more detail on the main page, so I suggest you head over there for more.