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.
I explain CSS vs. device pixels, the viewport, several interesting JavaScript properties,
and the media queries width
and device-width
.
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 device-width
on Android 2.1 . Usually device-width
mirrors the values given by screen.width/height
,
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, screen.width/height
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 screen.width
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.
This is the blog of Peter-Paul Koch, web developer, consultant, and trainer.
You can also follow
him on Twitter or Mastodon.
Atom
RSS
If you like this blog, why not donate a little bit of money to help me pay my bills?
Categories:
Comments are closed.
1 Posted by Matt Brubeck on 18 May 2010 | Permalink
I don't think you need to introduce a new term for "logical pixels" - just think of them as "CSS pixels when scale=1.0."
When scale=1.0 (zoom=100%), the relationship between CSS pixels and device pixels is defined in the section of the spec you linked. And of course when the scale (zoom level) changes, the relationship changes proportionally.
2 Posted by Frank van Puffelen on 18 May 2010 | Permalink
I had never read that part of the CSS spec, interesting stuff and surprisingly relevant in today's mobile world.
If I understand things correctly, one logical pixel should approximate 1 pixel on a 96 DPI device.
If that is the case, why not just call them "dots"?
3 Posted by Michael Kozakewich on 19 May 2010 | Permalink
I'd really love it if designers stopped saying things like, "Hey, guess what, we can go back to pixels, now!"
If everyone used ems, there wouldn't be as much fuss, and all the phone developers would need to do is double the default font-size of the browser.
4 Posted by Miller Medeiros on 29 May 2010 | Permalink
Mozilla is changing the way they interpret the viewport tag: http://hacks.mozilla.org/2010/05/upcoming-changes-to-the-viewport-meta-tag-for-firefox-mobile/
They have some extra info about this subject and even a link to your blog :)
5 Posted by timpeti on 10 June 2010 | Permalink
I have the feeling that this viewport concept, might also explain that the "missing support" for overflow:scroll and position:fixed is not due to Apple's unwillingness or incompentence just to implement but that it is just not possible the way mobile safari works: May it be that the user is kind of shifting the whole viewport around, so that he's never really scrolling inside the page itself? Has anybody some insights on that?
6 Posted by timpeti on 10 June 2010 | Permalink
I have the feeling that the viewport concept you describe in the article might be the reason, why overflow:scroll and position:fixed are just not able to work, rather than Apple is being incompetent or unwilling to implement it. May it be that, that the user kind of shifts the viewport around without really scrolling inside the page itself? Imagine you would place a mask on your monitor while just moving the browser window that you can see what you want. Of course position:fixed will never change in that scenario.
7 Posted by timpeti on 10 June 2010 | Permalink
I have the feeling that the viewport concept you describe in the article might be the reason, why overflow:scroll and position:fixed are just not able to work, rather than Apple is being incompetent or unwilling to implement it. May it be that, that the user kind of shifts the viewport around without really scrolling inside the page itself? Imagine you would place a mask on your monitor while just moving the browser window that you can see what you want. Of course position:fixed will never change in that scenario.
Someone has some insight to that?