Back in November I started complicated research into measuring the widths and heights of various interesting elements in mobile browsers. This research kept me occupied for months and months; and frankly I became a bit afraid of it because the subject is so complicated.
Besides, when I re-did some tests in March I pretty quickly figured out I’d made some nasty mistakes in my original tests. Back to the drawing board.
However, after a review round by some browser vendors and some rewriting it’s done now.
Today I present
A tale of two viewports — part one.
and the media queries
This piece is about the desktop browsers, because the mobile story is much easier to follow if you know exactly what happens on desktop. Later on I’ll publish part two, which is exclusively about mobile.
I decided to leave out several topics that also have to do with these issues, but that are either very complicated or rather obscure — or both. I may do additional research later on.
One of those topics is logical pixels. I’ll say a few words about them here. If you don’t already know the difference between CSS and device pixels I advise you to read my piece first and return to this entry after.
The problem with logical pixels is that I don’t really understand them. Well, I do, in a vaguish conceptual sort of way, but not enough for a formal explanation.
Basically logical pixels are an intermediate layer between CSS and device pixels that was added in order to hide the difference in pixel density between devices that have roughly the same physical dimensions. One phone of 4cm wide may have less pixels per cm than the other, and logical pixels provide an abstraction layer to work around that fact — or something.
When one of my reviewers brought the concept to my attention I sighed, tried to study it, found I didn’t really understand the spec, and despaired.
Then I considered the question again and found to my surprise (and delight) that the difference between logical and device pixels doesn’t matter. Any CSS layout uses CSS pixels, and we web developers work with those pixels 99% of the time and can forget about all the rest.
The remaining 1% of the time we want to know what the pixel layer “underneath” CSS pixels says about the device, but it doesn’t matter whether those pixels are of the logical or the device variant. They give their information and we use it. Device and browser vendors have already (mostly) made sure that the information is useful to us.
Besides, even if we wanted to distinguish between device and logical pixels, the information we need is simply not available. We get our measurements (say, the screen width) either in logical or in device pixels, and we cannot know which of the two the browser uses, and we certainly can’t read out the information in the other kind of pixels: it’s just not there.
Unfortunately there’s a single exception to this rule: media query
on Android 2.1 . Usually
device-width mirrors the values given by
and whether these values use logical or device pixels doesn’t matter.
In the specific case of Android 2.1 (tested on Nexus One), however,
returns 480px, while the media query
device-width works as if the screen is 320px wide. Right
now I assume the 480px are device pixels and the 320px logical ones.
The point here is that, although formally the screen of the Nexus One is 480px wide, using this value in media queries would result in a page that is too wide (and fonts that are too small) to be easily read by users. That’s why the Android team decided to insert an intermediate layer of pixels. (I expect the iPhone team to do something similar in the upcoming iPhone OS 4.)
I devoutly hope this aberration is going to go away; probably by making
320px, too. After all, if 480px results in a too tiny page, we web developers don’t need to know
about this value.
Maybe I’ll study logical pixels later on, and maybe I’ll even start to understand them enough in order to explain them. Not now, though. I first want to finish publishing my research.
I’m speaking at the following conferences:
Comments are closed.