It’s true that a slightly blurry icon or logo on the iPad probably isn’t going to ruin a site by driving visitors away in droves, but it is a problem, and one that will only become more obvious as higher-resolution screens proliferate.
At the moment there are essentially two ways to swap out your PNG icons for something a bit crisper: icon-fonts or SVG graphics. Naturally, neither is perfect — the last time something worked perfectly on the web Tim Berners-Lee and friends were the web’s only users — so it’s worth looking into the advantages and drawbacks of each.
That’s exactly what UIX designer Simon Uray recently did, breaking down the good and the bad of both icon fonts and SVG images. Give Uray’s post a read for the finer details on both, but here’s the short story: icon fonts are probably your best bet at the moment, though you’ll have to live with the fact that some icons are a tiny bit blurry on traditional displays.
Since at the moment the vast majority of screens on the web are not high resolution, adopting icon fonts over the PNGs you’re using now might be a case of premature optimization.
As Uray writes, “sorry, if you’re looking for a silver bullet, I’m afraid it doesn’t exist.” To that we might add “yet.” But SVG support in browsers (one of the chief problems with SVG is that it isn’t as widely supported as icon fonts) continues to improve. There’s also always the option to use them all. “Maybe best,” writes Uray, “is to use PNG served in many different sizes for your high fidelity, multi-color logo and other graphics… SVG icons for your navigation that stays the same size, but also look sharp on Retina displays [and] Responsive inline SVG for bars and charts and an icon font for all your different button sizes.” The best of all worlds.
The high-resolution retina display iPad has one downside — normal resolution images look worse than on lower resolution displays. On the web that means that text looks just fine, as does any CSS-based art, but photographs look worse, sometimes even when they’re actually high-resolution images.
Pro photographer Duncan Davidson was experimenting with serving high-resolution images to the iPad 3 when he ran up against what seemed to be a limit to the resolution of JPG images in WebKit. Serving small high-resolution images — in the sub-2000px range — works great, but replacing 1000px wide photographs with 2000px wide photos actually looks worse due to downsampling.
The solution (turns out) is to go back to something you probably haven’t used in quite a while — progressive JPGs. It’s a clever solution to a little quirk in Mobile Safari’s resource limitations. Read Davidson’s follow-up post for more details, and be sure to look at the example image if you’ve got a new iPad because more than just a clever solution, this is what the future of images on web will look like.
As Davidson says:
For the first time, I’m looking at a photograph I’ve made on a screen that has the same sort of visceral appeal as a print. Or maybe a transparency laying on a lightbox. Ok, maybe not quite that good, but it’s pretty incredible. In fact, I really shouldn’t be comparing it to a print or a transparency at all. Really, it’s its own very unique experience.
But how could you go about serving the higher res image to just those screens with high enough resolution and fast enough connections to warrant it?
So what’s a web developer with high-res images to show off supposed to do? Well, right now you’re going to have to decide between all or nothing. Or you can use a hack like one of the less-than-ideal responsive image solutions we’ve covered before.
The high-res future is coming fast and the web needs to evolve just as fast.
In the long run that means the web is going to need a real responsive image solution; something that’s part of HTML itself. An new HTML element like the proposed <picture> tag is one possible solution. The picture element would work much like the video tag, with code that looks something like this:
The browser uses this code to choose which image to load based on the current screen width.
The picture element would solve one part of the larger problem, namely serving the appropriate image to the appropriate screen resolution. But screen size isn’t the only consideration; we also need a way to measure the bandwidth available.
At home on my Wi-Fi connection I’d love to get Davidson’s high-res images on my iPad. When I’m out and about using a 3G connection it would be better to skip that extra overhead in favor of faster page load times.
Ideally browsers would send more information about the user’s environment along with each HTTP request. Think screen size, pixel density and network connection speed. Developers could then use that information to make a better-informed guess about which images it to serve. Unfortunately, it seems unlikely we’ll get such tools standardized and widely supported before the high-res world overtakes the web. With any server-side solution to the bandwidth problem still far off on the horizon, navigator.connection will become even more valuable in the mean time.
Further complicating the problem are two additional factors, data caps on mobile connections and technologies like Apple’s AirPlay. The former means that even if I have a fast LTE connection and a high-resolution screen I still might not want to use my limited data allotment to download high-res images.
AirPlay means I can browse to a site with my phone — which would likely trigger smaller images and videos since it’s a smaller screen — but then project the result on a huge HD TV screen. This is not even a hypothetical problem, you can experience it today with PBS’s iPhone app and AirPlay.
Want to help figure out how the web needs to evolve and what new tools we’re going to need? Keep an eye on the W3C’s Responsive Images community group, join the mailing list and don’t be shy about contributing. Post your experiments on the web and document your findings like Davidson and countless others are already doing.
It’s not going to happen overnight, but eventually the standards bodies and the browser makers are going to start implementing solutions and the more test cases that are out there, the more experimenting web developers have done, the better those solutions will be. It’s your web after all, so make it better.