Wednesday, June 30th, 2010

The death of the pixel as we know it; The new DPI web

Category: Browsers

<p>The Web used to be so simple. Browser request goes to server, where you do some work, and return some HTML. Then we got Ajax and finally web apps could have some semblance of UI responsiveness. Now we have richer HTML5 technologies to change expectations of our users once again.

The Web is getting some new DPI love, and the new iPhone 4 display personifies this fact. The new display is fantastic for the consumer, and an opportunity for the design enlightened to build truly beautiful web sites. There is a big difference:

However, how do we as developers deal with this new world?

Aral Balkan has a nice post that goes into detail on the new opportunity and shares samples and ideas.

As with so many things on the Web, some of this has been thought of a loooong time ago. Dave Hyatt wrote about this back in 2006.

Walt Dickinson put together a guide to the retina display and using CSS3 media queries:

  1. <link rel="stylesheet"
  2.     type="text/css"
  3.     href="/css/retina.css"
  4.     media="only screen and (-webkit-min-device-pixel-ratio: 2)"
  5. />

Aral explains that “in the Retina-specific CSS, he loads in 32×32 icons as background images and specifies their dimensions in CSS pixels as 16×16 using the background-size CSS property.”

It is interesting to see a device pixel ratio used rather than specifying a DPI itself.

What else can be done to help folks in this new world?

Aral talks about how the browser could natively help via convention:

I’d like to suggest that browsers adopt the same naming convention that Cocoa Touch uses to find and load high-DPI versions of image and video assets. That is, if I embed an image using the following code…

  1. <img src="flower.jpg" alt="A beautiful rose"/>

… it should load in flower.jpg when the device-pixel-ratio is 1 but it should attempt to find an image called flower@2x.jpg at the same relative path if device-pixel-ratio is 2 (and so on, for higher pixel-ratios), falling back to the original graphic if it can’t find a high-resolution version.

(And the same convention could be used to load video assets.)

Maybe there are server side techniques that could be put in place to automatically serve up the most optimized image for a given DPI. This would stop a bunch of 404s, but requires more work on the part of the server monkey.

This is good news for SVG and libraries like Raphael, who are well suited for scaling. When playing with an iPhone 4 it was amazing how quickly you noticed the bitmaps that were too low res… they stick out like a sore thumb. Expectations have changed.

What else can we do?

Related Content:

Posted by Dion Almaer at 11:17 am
29 Comments

++++-
4.3 rating from 3 votes

29 Comments »

Comments feed TrackBack URI

O/T
This is the second* Ajaxian article recently where the image that forms the main point of the article doesn’t actually fit the 455px fixed width of your site’s template. For a “Web 2.0 / CSS / JavaScript” based blog, do you not think it time to fix your layout so it stretches to the entire width of the browser window?

* The first was a chart – I forget the exact article.

P.S. Irony: “Spam Question: What three letter acronym is what we use to style web pages?”

Comment by spyke — June 30, 2010

This is excellent stuff. I recommend browsers send additional HTTP request headers along with the image GET request, to specify the desired DPI. I had an idea for this years ago, where an IMG tag would send along its “width” and “height” attributes as HTTP headers, so the server could send back optimized content. However, we can go even further with this DPI concept, with the client sending its actual effective screen DPI, so the server can adjust accordingly.

GET /path/to/flower.jpg
X-Browser-DPI: 150
X-Container-Width: 256
X-Container-Height: 256

Of course, as you Dion mentions, this does require more work on the server side. But someone could easily create an Apache module that reads the headers and rewrites the request to a filename lookup scheme, if that’s what you want.

Comment by jhuckaby — June 30, 2010

@spyke This comes up all the time, especially with youtube videos. I guess they just don’t have time to redo the layout at the moment.

Comment by Skilldrick — June 30, 2010

Text and layout is already designed to scale, proper font sizes and layout should already be done in percentages and em’s. This is no more of an issue than desktop monitors increasing resolution.

This seems like more of a hack to make layouts designed in pixels look better when zoomed… but I think the real answer is to adapt to viewport size and stop making pixel-based layout. Forget DPI, I want calc() support and the improved box model ASAP!!

Comment by doublerebel — June 30, 2010

I don’t think X-Browser-xxx or X-Container-xxx headers are the way to go. HTTP already has an Accept header. We have Accept, Accept-Charset, Accept-Encoding, Accept-Language, and Accept-Ranges. Now we just need some sort of Accept-Display header that functions exactly like the other Accept headers. This way, servers can simply use existing Content-Negotiation techniques that maintain cacheability of resources, while at the same time keeping the display-specific references out of our code.

Comment by posaune — June 30, 2010

“proper font sizes and layout should already be done in percentages and em’s”

Why? Can you actually give a real justification for why anyone should still do this in the age of page zoom?

The issue of low-res bitmap assets on a high-res screen is a valid one that requires some thought, but all of these posts about liquid layouts and designing with relative units is bunk.

Comment by SashaSklar — June 30, 2010

Native device apps should be designed with resources for variable DPI, Android is a good example of this. Webpages should be designed with fluid layout and relative units because browser viewports come in all sizes and ratios. Desktop browser zoom isn’t like mobile browser zoom, users shouldn’t be required to zoom on their PCs because a lazy designer is still stuck on px’s.

Comment by doublerebel — June 30, 2010

I’ll leave out application design and web application design, there are concerns there that don’t apply to content web development.

“Desktop browser zoom isn’t like mobile browser zoom, users shouldn’t be required to zoom on their PCs because a lazy designer is still stuck on px’s.”

EMs are relative to a base that is defined in pixels, either explicitly by the developer or implicitly by the user agent.

Ok, I have a page where the font size on the body is 11px. Let’s say you have an element with text that’s 1.2em. he element has a defined height and width of 10em. What is the actual difference between those values and their equivalent in pixels if you discount user agents that don’t support page zoom?

Comment by SashaSklar — June 30, 2010

“P.S. Irony: “Spam Question: What three letter acronym is what we use to style web pages?””

I fail to see the irony.

Comment by MattCoz — June 30, 2010

A good fluid & relative layout scales to the size of its content, not just the size of the screen. Relative font sizes allow the browser to scale text independently of the other page elements, and a fluid layout will still be legible when font size changes. (I won’t go into the browser differences with font rendering and fractional pixels that make absolute px layout practically impossible.)

If you are designing using device-pixel-ratio then you are already designing using relative units, px is not px anymore, it is a relative unit based on DPI. Instead of this bass-ackwards pretending that you are using an absolute unit, call it what it is and use relative units like em and %, that is what relative units are designed for.

Comment by doublerebel — June 30, 2010

It begs the question: why the heck does 1px != 1 pixel?

I feel like Apple is making it harder for us by deciding to stretch pages by default. The web hasn’t used inches, cm, twips, or any other “real-world” unit, and it should stay that way.

Comment by rethinker — June 30, 2010

a screen has no dots, the picture is made of pixels. so it’s not DPI it’s PPI ffs.

Comment by antpaw — June 30, 2010

Those would be CSS pixels, which are relative lengths (and have been for quite some time):
http://www.w3.org/TR/CSS2/syndata.html#length-units

While technically it might be a correct use of the word “pixel,” I think there could have been a much better choice for the term. This is even more clear when “device pixel” has to be added to clarify things.

Comment by bckenny — June 30, 2010

A streamable image format where progressively more downloaded data meant higher resolution would be better than having an awkward convention where different higher resolution files are looked for.

Comment by meandmycode — June 30, 2010

@doublerebel Please address the point I made: relative units are relative to a base defined in pixels, so what is the difference given full page zoom which is what the overwhelming majority of your users are using?

Comment by SashaSklar — June 30, 2010

@rethinker Because if they did that then the iPhone 4, which has 4 times the resolution of the previous device, would not display existing content legibly.

Comment by SashaSklar — June 30, 2010

@rethinker
If 1px = 1 pixel then the iPhone 4, which has 4 times the resolution of the previous device, would not display existing content legibly.

Comment by SashaSklar — June 30, 2010

@SashaSklar: I did address your point already: You are thinking only of page zoom, not text scaling. Pt and px do not scale in all browsers when base font size is changed – as I assume everyone here knows. For example, here is a good article on why text scaling is important.

Comment by doublerebel — June 30, 2010

@doublerebel The article you linked doesn’t actually come to the conclusion your link text implies.

Going back to mobile webdev, no mobile browser I know of supports text scaling, so we are stuck with two options:

1. Setting the viewport to an absolute width and designing our content to that width (I’m assuming we’re talking about content sites where the desired behavior is a width that’s fixed and vertical scrolling).
2. Setting the viewport to device-width, using fluid layout and hoping our assets and content scale properly: what a hassle!

Comment by SashaSklar — June 30, 2010

Before we jump to handling DPI in CSS, how about we first get that whole CSS3 out the door all proper, with full support across all browsers and stuff. As big as the media is making out the iphone 4, it’s barely a drop in the bucket when it comes to desktop/laptop computers with “regular” DPI. Take into account all the other smartphones with regular DPI and well, let’s put it this way, is it worth spending the time to create x2 images for every icon on your website so that .002% of your visitors can enjoy them on iphone’s screen?

Comment by iliad — June 30, 2010

@MattCoz, The question is not ironic but it is wrong. CSS is not an acronym.

Comment by okonomiyaki3000 — June 30, 2010

I didn’t went through the comments, but the new approach of apple just looks not good. It introduced new complexity in dealing with half- or twice pixels where it just does not need to. hä?

If the total number of pixel changes, this would logically result in a dimension change and we know how to deal with that, easy job for us. But now… dush how many different stylesheets with different media-query’s do I need to put in my html5 app to service different plattforms at once?

Instead of simplifying they make it more complex. Fail.

Comment by gossi — July 1, 2010

I’m glad someone finally had the guts to mess with the dpi. I’ve been annoyed for years that high-dpi screens were readily available but the platforms refused to support them properly. Apple has had experimental high-dpi support for years, but they never properly used it in shipping products.
.
Think of all the wasted time on font hinting, anti-aliasing logic, cleartype, … That’s all stuff that’s unnecessary on a 300 dpi screen. Everything can be vector-based, and designers can work in ignorance of hardware pixels. It’s what we all want, so we should be happy apple is finally making it happen.

Comment by Joeri — July 1, 2010

@MattCoz It’s ironic because the CSS on a site *about* CSS sucks. So Ajaxian themselves don’t use CSS to style their own pages using best practice techniques that the article (and perhaps the entire site) relates to.

Geddit?

Comment by spyke — July 1, 2010

Yes, we really need to make things more complicated!

Comment by igl — July 7, 2010

I think this is wrong. There’s nothing wrong with the Pixies as they are. I have all their records and changing them to be “high definition” is in my opinion a mistake.

Let’s move on.

Comment by Benny007 — July 8, 2010

Is there any plans for browsers in future that the text displayed will be based on DPI settings of the OS? I mean CSS pixels should be relative to the DPI setting of the device. Now i’ve higher DPI set in my system but the browser’s text are based on the normal one. This forces me to to do Ctrl++ every time to magnify the page content.

Since images gets pix-elated upon zooming. Will this technique solve this issue? For instance, i will design an image in higher DPI (say 200x200px) and set its dimension as 100x100px in CSS.

Or, is SVG the only alternative?

Comment by krishnajay — July 8, 2010

thought the higher res was going to impact the ui somehow, oh well.

now the idea of using svg over images where possible seems more feasable as every man and his dog will soon have the enhanced display.

frickin’ cool though, good work Aral!

Comment by johnantoni — July 9, 2010

agree with meandmycode, pretty sure one the ruby side you could use paperclip and some fancy sass to render user-uploaded images based on res and then enhance the interface with raphael svg graphics. load times would rock!

Comment by johnantoni — July 9, 2010

Leave a comment

You must be logged in to post a comment.