All posts tagged ‘responsive images’

File Under: Multimedia, Web Services

Flickr Goes Big With Larger Images, Responsive Redesign

Flickr: now with bigger images and a (mostly) responsive design.

Flickr recently changed its “lightbox” photo pages — the darker photo-friendly interface on the site — to display much larger photos. Now the grandfather of online photo-sharing sites is rolling out a site-wide redesign that uses the same big, beautiful images to put your photos front and center on every page.

The larger images in Flickr’s revamped photo pages put the emphasis where it belongs — on your photos. Peripheral information, like comments, maps, tags, set info and so on are still there, they’re just now (rightly) dwarfed by the actual image.

The result is a much more photo-centric site that does a nice job of differentiating itself from the current trend of low-res, filter-heavy photo0sharing services.

Web developers, take note: Flickr’s new layout isn’t just eye-catching, it’s also somewhat responsively designed — adjusting to the myriad screens on the web today and displaying the best photo possible without clogging your tubes with huge photo downloads. Flickr does stop short of scaling pages down to phone-size screens — for which there is a separate mobile website — but it resizes nicely to handle tablets.

That’s right, Flickr is the latest (and perhaps the largest) website to embrace not just a mostly responsive design with a liquid layout and media queries, but also a responsive approach to images.

We’ve looked at dozens of ways to handle images in a responsive design, but Flickr has opted for a custom setup that uses a bit of server-side PHP and some JavaScript to serve images based on screen size. Flickr is also using a custom algorithm that takes the width and height of the screen into account and “will display content at a width that will best showcase the most common photo ratio, the 4:3.”

For more details on how Flickr is handling the responsive aspects of the new design, check out the Flickr code blog.

Developers working with the Flickr API should note that the new photo sizes are now available through the Flickr API if your app or website would also like to display larger images.

File Under: HTML, Web Standards

Use Your ‘Head’ For a Better Way to Serve Images

Responsive web design has grown well beyond its humble beginnings — using liquid layouts and media queries to scale websites so they fit any screen — and now means developers must wrestle with much more complex problems, like serving the right image to the right screen.

Mobile screens are small; downloading full-size images is a waste of bandwidth (and quite possibly users’ money as bandwidth caps become more common). But serving tiny pixelated images to increasingly high-resolution screens doesn’t help users either. There are already dozens of creative solutions to the problem of handling images intelligently in responsive design, but ultimately the web needs more than hacks; it needs a built-in responsive image solution.

The Responsive Images community group has been wrestling with this problem for some time and has proposed and refined the <picture> tag, one possible solution. The picture element would work much like the HTML5 <video> tag, with code that looks something like this:


 
 
 

Due to a communication breakdown between the WHAT WG, which actually writes the standards, and the community group, which is a way for outsiders to contribute to standards, the WHAT WG is already considering a different proposed solution that involves adding some elements to the good old <img> tag.

The proposed solution comes from Apple’s Edward O’Connor and mirrors a similar syntax for background images in CSS. Neither are standards yet and we’re hoping neither ever become standards. Here’s an example of the proposed syntax:

<img src="face-600-200@1.jpeg" alt=""
set="face-600-200@1.jpeg 600w 200h 1x,
face-600-200@2.jpeg 600w 200h 2x,
face-icon.png       200w 200h">

That’s a code tangle only a browser maker could love and in the subsequent discussion on the community group post developers are nearly unanimous in preferring the <picture> tag (though many dislike its verboseness). The truth is neither this nor the <picture> tag is a very appealing solutions.

However, toward the bottom of that discussion thread Denis Leblanc proposes another possible solution, namely, header tags. Matt Wilcox, who created the Adaptive Images solution we’ve covered before, takes Leblanc’s idea and runs with it in another post. What Leblanc proposes is creating a new head tag that would allow web developers to create breakpoints with a media-query-like syntax:

<head>
<meta name='case' data='breakpoint1' media='min-width:350px' />
<meta name='case' data='breakpoint2' media='min-width:1000px' />
</head>

Here’s Wilcox’s explanation of how it would work:

What the code above does is set “case” to equal a particular value, when a media query expression is matched. And if that’s done in the HTML <head> we know that absolutely everything else can rely on it — the <head> is the very first thing parsed by a browser, even before anything inside <body>. Anyone familiar with working on the ‘responsive images’ problem should at this point be getting very excited. It means that the browser can be aware of the need to adapt before any pre-fetch behaviours have been triggered by finding an <img /> element in the mark-up. That is a major advantage and is how this solution solves the problem of image pre-fetch.

In other words, this solution neatly avoids downloading anything other than only the image needed, saving bandwidth and processing power. Then in your body you would simply write:

<img src='/content/images/{case}/photo.jpg' alt='' />

It’s certainly less verbose than either of the other proposals, needing only a single image element with no custom properties or other code. It’s also backward-compatible provided you either create a directory called “{case}” on your server or alias the path to an existing file. Browsers that don’t understand the syntax simply serve the image referenced and those that do choose the appropriate image from the meta tag breakpoints you’ve set.

In short, this looks like a very ideal solution from a web author’s point of view. Whether or not browser makers and the standards bodies agree remains to be seen. One possible strike against it is that it would add variables to HTML in the form of the {case} syntax, but variables are already part of CSS and JavaScript, so why not HTML?

None of these proposals is anything more than an idea at this stage — though there is already a JavaScript polyfill for the new head tag idea — but if you’d like to keep up with what’s happening, be sure to keep an eye on the W3C’s Responsive Images community group. It’s not going to happen overnight, but eventually standards bodies and browser makers are going to start implementing solutions and the more experimenting web developers have done, the better those solutions will be. It’s your web after all, so make it better.

File Under: CSS, Multimedia, Web Standards

JavaScript Package Offers a Smarter Way to Serve Hi-Res Images

Given enough time, all simple, already solved problems of the web eventually rear their ugly heads again.

Remember when limited bandwidth was a huge problem? Then bandwidth was infinite. Now it’s a problem again. And that means serving up images is once again a complex problem with no elegant solution. Its seems simple. Websites should serve the right image to the right screen, high-resolution images to high-resolution devices and low res to the rest. But of course it’s not that simple. Factors like bandwidth as well as screen size and orientation complicate the matter considerably.

Arguably the best solution right now is to send low-res images to every device. Sure, your images might look terrible on high-res screens, but at least you aren’t wasting people’s time or worse, costing them money.

While that’s the safest solution for now, the web doesn’t get better if no one takes any risks. Fortunately, until some standard or best practice emerges, we’ll likely continue to see developers pushing the boundaries and discovering new ways to handle the seemingly simple task of serving the appropriate image to the appropriate device.

The latest image cleverness we’ve seen is Adam Bradley’s Foresight.js. Foresight.js is designed to make it easy to serve up high-resolution images to devices like the new iPad, but what sets foresight.js apart from half a dozen other solutions that do the same thing is that it not only checks for a hi-res screen, but also checks to see if the device currently has a fast enough network connection for larger images. If, and only if, your visitor has both a device capable of displaying high-res images and a network connection fast enough to handle the larger file size, are larger images served.

Part of what makes Foresight.js appealing is its use of the proposed CSS image-set() function, one possible solution to the problem of serving up the right image at the right time. The image-set() function, which works in WebKit nightly builds and is under consideration by the W3C, looks like this:

myselector {
    background: image-set(url(foo-lowres.png) 1x, url(foo-highres.png) 2x) center;
}

Foresight.js takes the image-set() proposal and uses an ingenious hack to make it work in other browsers: the font-family property. Yes, it sounds crazy. But it works and remains technically valid CSS because font-family allows for arbitrary strings (to handle font names). That means browsers have no problem with a rule like this:

myselector {
    font-family: ' image-set( url(/images/foo.png), url(/images/foo_2x.png) 2x high-bandwidth ) ';
}

It’s a hack to be sure, but it’s our favorite kind of hack: clever and functional. Because browsers successfully parse the font-family rule (even if they can’t apply it) the value is added to the DOM and JavaScript has no problem accessing it, which is exactly what foresight.js does.

For more on foresight.js, head over to the GitHub page which as links to plenty of examples uses and copious documentation on the script’s many tricks. Also be sure to read through Bradley’s Challenges for High Resolution Images, which offers some background on foresight.js and the design decisions he made.

The Web Needs to Get Ready for the High-Resolution Future

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.

To show off the sample on his site Davidson uses a bit of JavaScript to toggle the high- and low-res images, highlighting the difference.

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?

You can’t.

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.

Right now visitors with the new iPad are probably a minority for most websites, so not that many people will be affected by low-res or poorly rendered high-res images. But Microsoft is already prepping Windows 8 for high-res retina-style screens and Apple is getting ready to bring the same concept to laptops.

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.

Photo: Ariel Zambelich/Wired

What the New iPad’s Retina Display Means for Web Developers

The high-res future is coming

The first of the new iPads will arrive in the hands of the public this Friday, March 16. Like the iPhone before it, and no doubt many more devices to come after it, the new iPad has four times the resolution of typical screens. That means your visitors will soon be looking at your site on a high-resolution screen with a whopping 3.1 million pixels.

The sharp, crystal-clear screens are awesome news for new iPad owners, but they create some new dilemmas for web developers who’d like to offer a better experience for high-resolution screens. Sure, increased pixel density means you can serve up sharper, better looking graphics, but there is a cost as well — bigger images mean more bandwidth and longer page loads.

This isn’t a new problem by any means and Webmonkey has looked at a variety of solutions in the past, including techniques like adaptive images and responsive images.

The problem is simple: you need to send smaller images to small screens and larger images to larger screens. Sending a huge iPad-optimized image to a device with a max resolution of 320×480 just doesn’t make sense. At the same time, when bandwidth isn’t an issue, most sites will want to serve high-resolution content to displays that can handle it.

The ideal solution would be to detect both the resolution of the screen and the available bandwidth. Then, based on the combination of those two factors, the server could offer up the appropriate image. Currently that’s not possible, though there are already proposals to extend HTML to handle that scenario.

The Responsive Image Working Group is a W3C community group hoping to solve some of these problems. The group is proposing a new HTML element, <picture>, which will take into account factors like network speed, device dimensions, screen pixel density and browser cache to figure out which image to serve up. Think of it as a much smarter version of the old lowsrc property. So far though it’s all hypothetical

In the mean time if you’d like to serve up high resolution images to your third-generation iPad visitors look no further than Apple.com for one (not necessarily ideal) way to do it. An Apple Insider reader noticed that Apple is already prepping its site to deliver double-resolution images to new iPads. Cloud Four’s Jason Grigsby, whose responsive image research we’ve covered before, has a great breakdown of what Apple is doing.

Essentially Apple is serving up lower resolution images by default, then using JavaScript to send larger images on to iPads. That works, but it will definitely mean increased download times for new iPads since they have to download two files for every graphic. Apple’s approach will also up the number of HTTP requests, which will also slow down the page.

The slower page loads seem to be an acceptable trade off for Apple since the company no doubt wants to showcase the new iPad’s high resolution display with high resolution images. For other sites the bandwidth trade off may not be worth the gain in image resolution.

Still, screens are only going to continue getting better with ever-increasing pixel density. Now is the time, if you haven’t already, to start embracing CSS 3 (avoid images altogether with gradients, shadows and rounded corners in CSS 3), Scalable Vector Graphics (SVG) for resolution independent graphics and of course @media queries to serve high-res background images.

For more on detecting and developing for high resolution displays, check out these posts from around the web: