screen.width is useless

Yesterday I tested screen.width/height and related properties in the mobile browsers. The conclusion is that screen.width/height is completely unreliable.

There are two competing definitions of what screen.width/height actually means. In addition, a lot of browsers either ignore both definitions or have bugs in their implementation.

Thus, when analytics packages proudly present screen resolution stats, they don’t know what they’re talking about and you’d do best to ignore them. The package has no clue what kind of measurements it gets, but pastes the result into the database anyway and pretends it means something profound.

The two definitions

Web developers expect screen.width/height to give the number of physical pixels on the entire screen. The other option, however, is that it gives the width and height of the ideal viewport; the one you get when using width=device-width.

By now it will not surprise you that some browsers use the first definition, and others the second (details here). Therefore, simply reading out screen.width/height doesn’t give you any clue exactly what you are reading out.

Retina screens

But wait, it gets worse. Desktop isn’t safe, either.

On a Macbook with a Retina screen in full resolution, screen.width/height gives not 2880x1800 (physical), but 1440x900; sort-of the ideal viewport, except that the concept makes less sense on desktop, where width=device-width is not supported. In this case, the devicePixelRatio is 2, as you’d expect.

However, if we go back to a 1920x1200 resolution, screen.width/height also give 1920x1200 and thus switches to physical device pixels. Confusingly, devicePixelRatio remains 2. That’s obviously an error.

In other words, if an analytics script reads out screen.width/height from a Macbook Retina, it doesn’t know what data it gets, either.

devicePixelRatio to the rescue?

The Macbook Retina example also shows that window.devicePixelRatio will not help us here. Although it is supposed to give the ratio between the physical and ideal dimensions, sometimes it doesn’t, and even if it does it’s unclear if you have to multiply or divide screen.width by devicePixelRatio.

So forget about window.devicePixelRatio, too. It won’t help.

What do we want?

I’d like to start up a begging-and-screaming campaign that forces browser makers to choose one definition for screen.width/height. The problem is that I don’t know which one we need more.

So: what would you like to know as a web developer? Physical pixel dimensions? Or the ideal viewport dimensions? Or both? Or neither?

Right now I see two solutions:

  1. We ignore the problem because we don’t need either bit of data (except for analytics).
  2. We ask the browser vendors to add a new property pair so that one can return the physical dimensions and the other the ideal ones.

I’m not sure which to choose. I’d like to ask you to think about it. One day I’ll ask for opinions, and I hope to get a few useful ones.

This is the blog of Peter-Paul Koch, mobile platform strategist, consultant, and trainer. You can also follow him on Twitter.
Atom RSS

I’m around at the following conferences:

(Data from Lanyrd)

Categories:

Monthlies: