Category Archives: Web Development

Proposal: Move Media Queries from CSS to HTTP

Martin Wolf in reply to my reply to his earlier post on Bandwidth Media Queries:

So I could show a small image on an iPad 3 which is on LTE, but a big double sized image on an iPad which is on wifi.

I still believe Bandwidth Media Queries are a bad idea, but I do believe that bandwidth is an important factor in the user experience. However, I think that detecting the bandwidth is a wrong solution for a right problem. We want to provide content that fits and loads fast on the users device and network. As I mentioned in my previous article, in practice it is not possible to determine the real bandwidth the user currently has, we can only estimate it by detecting the network the user is currently on. Martin mentioned that he does not want to mess with the users data limit. This might be a problem in Germany and some other countries, but if I am in Austria and have a good 3G connection I want to view the full image, not a shitty JPEG with 50% compression. If you truly want to serve the best image for each device and connection you have to do something like this:

You have to repeat this for mobile devices without a retina display, for iPads, for iPads with retina display, for notebooks, for notebooks on a 3G network and so on. Probably you will end up with hundreds of different media queries. That is not practical.

As a web developer I do not even want to deal with the display size of the device and I want for sure not have to deal with the bandwidth the user has and the network the user is on. That is like developing web applications in C instead of PHP or Ruby.

Here is a proposal:

CSS seems to me the wrong place to deal with hardware related features. I suggest: Remove media queries. Instead of media queries add native support for grids to the standard. Additionally there should be properties to define how the layout should be resized. For example, there could be a property to define that it is ok to display this column beneath the previous one if the device is to small to display them side by side.

Second of all, we should move the part of delivering the right image to the web server. If devices would send a HTTP header like X-MAX-WIDTH: 640px the web server could determine the which image to serve. It could even dynamically call a tool like ImageMagick or a PHP or Ruby script to resize the image. This is very similar to the Adaptive Images technique, although instead of hacking it together using cookies (which breaks if the browser prefetches images) it would be supported natively and therefore it would work. One small problems remains, that if an user opens an image explicitly in the browser he probably wants to view the full version, not the version optimized for mobile devices. Therefore the browser should additionally send a X-EMBEDDED: 1 header which signals if the image is embedded in a HTML page or requested explicitly.

I don’t like media queries because it requires me to deal with low-level hardware stuff instead of creating a great user experience on every possible device. As a developer I can not test and optimize my website for each new phone or tablet. Thus I want to be able to trust the browser vendors that my website will look great on each new device the produce

Bandwidth Media Queries

Chris Coyier:

That issue is: bandwidth. If I’m in a place / on a device that has super slow internet, I’d love to be served a very light web page so browsing is still acceptably fast. If I’m in a place / on a device that has super fast internet, by all means ratchet it up and deliver me more.

Martin Wolf:

But even a picture tag, which could deliver different files for different screen sizes would be a step forward. Yes, there are Javascript solutions for that, but it is not perfect and it would be better if there was a simple HTML solution.

First of all, JavaScript is not really a solution for serving different image sizes. Any solution that I currently know of needs at to download at least the smallest version in addition to the appropriate image. A very clever solution which nearly worked is described by Mat Marquis.

My problem with bandwidth detection is that it will never be really accurate. In its simplest case the browser would just send the speed of the network the user is currently on. However, I can be on 3G but since I am also currently updating a dozen of iPhone Apps, I don’t really can surf using 3G speed. If the browser wants to detect the real bandwidth I currently have, it would need to download some Megabytes and measure how long it takes. Since my available bandwidth can change quite often, he would need to repeat this on a regular basis. Thus it would use a quite big amount of my network just to detect my bandwidth.

This seems to be a lot of work for a feature I can’t come up with a single use case where this would be absolutely necessary. I still need to detect the screen size and ratio (has the device a retina display?) in order to provide the browser with the correct image. Of course I would be able to serve, for example, two different versions to mobile clients. One JPEG with 60% compression if the user is on a slow connection and one with 90% compression if the user is on a fast network. However I am quite sure that only a small minority of web developers will go through the trouble creating even more different versions of an image. If only very few web developers would use this feature, it seems like a bit of overkill to detect the real bandwidth (and therefore use up my monthly download limit) just to improve the quality of these few sites.