Relative pixels

Layout methods in web design have gone through a transition in the last few years, unfortunately we’re still using floats a lot, but flexible layouts have made a comeback in the form of responsive design – which is great.

Recently though, I have been puzzled by people suggesting that we should use EMs for layout, for two main reasons:

• Browsers translate EMs to pixels anyway, so why add a layer of abstraction?
• It is actually difficult for users to change the text size in browsers these days, so why do people think that EMs vary in a useful way?

In this article from Cloudfour on EM media queries, Lyza Gardner notes that the EM based media queries worked with zoom (in Webkit) and not with pixels.

However, that’s a bug in webkit. If you try the same in Firefox/IE/Opera, pixel based media queries work great with zoom. It just happens that a webkit bug for zooming EM based media queries has had some work, but not for pixels.

We noted that pixel measurement and divided it by the rough baseline of 16px to arrive at our em units. There may well be a better way to do this math, but this seems to do the trick so far.

If and when the bug in webkit is fixed, there would be no need for that maths, just note the pixel value!

Pixels (that is to say, CSS pixels) have always been a relative unit, but with new devices coming out that have higher (physical) pixel densities the relativeness is more obvious than ever.

There are some issues at the moment that can be worked around by using EMs, as shown in the Alistapart article. However, I think devices like the Kindle Fire are going to have to catch up and use CSS-pixels rather than hardware pixels. My Android phone does a great job of this, most websites have reasonable sized text and the site designers haven’t had to  jump through hoops.

Long term I bet that the pixel will be the most useful and consistent relative unit.

The people in the best position to decide what a (CSS) pixel should be on a device, are the people making the device. There are simply too many devices to test your website with; if web designers can’t rely on CSS pixels working across devices then those devices are going to loose out.

Device makers are going to have to make ‘normal’ sites readable and useful, so CSS pixels will need to be relative to the screen size rather than pixel density. This will be equally important on TV displays, where the resolution is quite high, but the distance from screen to eye is greater. So for TVs CSS pixels could vary by TV size even though they all have 1920 pixel wide resolutions (for HD screens).

Lets just make sure when we talk about pixels in web design, we are talking about CSS pixels.

---

Sidenote –  foreground pictures

Most things in web design scale to higher pixel-density displays nicely, for example, pixel sized text and css borders. Background images in the CSS can be adjusted with media queries, so you could have different background images depending on the pixel-density. (LukeW has some good resources on workarounds.)

Where the water is murkier is foreground pictures. We can scale down larger images with CSS, but that doesn’t affect the file size, so someone on a mobile connection might still get a 1MB image scaled down to 200px.

Something like Adaptive Images is probably the best solution to this at the moment, but I do wonder if it could be more automatic?

Progressive JPGs appear to offer a solution: You provide the biggest image as a progressive JPG (e.g. 3000px wide), and set the (CSS) pixels width in the HTML or CSS. The browser then downloads a sufficient amount of pixels to meet the device’s pixel density.

This thought was triggered by this example of photography on the iPad 3. However, to extend that idea, wouldn’t it be great if you could just use one image for every size from thumbnails up?

Having tried a quick test, unfortunately browsers (currently) download all the information, not just enough to fill the current size. Still, could it work? Is it worth considering?