One Solution To Responsive Images | Smashing Mobile
"Common Solutions
Before going over our solution, let’s look at some common solutions currently being used. To keep up with currently popular methods and the work that the Web community is doing to find a solution to responsive images, head over to the
W3C Responsive Images Community Group.
PICTURE ELEMENT
First up, the
picture element. While this doesn’t currently have native support and browser vendors are still deciding on
picture versus
srcset versus whatever else is up for discussion, we can use it with a polyfill.
<picture alt="description">
<source src="small.jpg">
<source src="medium.jpg" media="(min-width: 40em)">
<source src="large.jpg" media="(min-width: 80em)">
</picture>
The picture element is great if you want to serve images with a different shape, focal point or other feature beyond just resizing. However, you’ll have to presize all of the different images to be ready to go straight in the HTML. This solution also couples HTML with media queries, and we know that coupling CSS to HTML is bad for maintenance. This solution also doesn’t cover high-definition displays
For this project, the picture element required too much configuration and manual creation and storage of the different image sizes and their file paths.
SRCSET
Another popular solution,
srcset, has recently been made available natively in some WebKit-based browsers. At the time of creating our plugin, this wasn’t available, and it looks like we’ll be waiting a while longer until cross-browser compatibility is good enough to use it without a JavaScript fallback. At the time of writing,
srcset is usable only in the Chrome and Safari nightly builds.
<img src="fallback.jpg" srcset="small.jpg 640w 1x, small-hd.jpg 640w 2x, large.jpg 1x, large-hd.jpg 2x" alt="…">
The snippet above shows srcset in use. Again, we see what essentially amounts to media queries embedded in HTML, which really bugs me. We’d also need to create different image sizes before runtime, which means either setting up a script or manually doing it, a tiresome job.
SERVER-SIDE SNIFFING
If you’d rather not use JavaScript to decide which image to serve, you could try sniffing out the user agent server-side and automatically send an appropriately sized image. As a blanket rule, we almost always say don’t rely on server-side sniffing. It’s very unreliable, and many browsers contain inaccurate UA strings. On top of that, the sheer number of new devices and screen sizes coming out every month will lead you to maintenance hell.
OTHER SOLUTIONS IN THE WILD
We chose to make our own plugin because including layout code in the HTML seemed undesirable and having to create different image sizes beforehand was not enticing.
If you’d like to explore other common solutions to decide which is best for your project, several great articles and examples are available on the Web, including one on this very website.
- “Choosing a Responsive Image Solution,” Sherri Alexander, Smashing Magazine
Alexander looks at the high-level requirements for responsive images, and then dissects the variety of solutions currently available in the wild.
- “Which Responsive Image Solution Should You Use,” Chris Coyier, CSS-Tricks
Coyer takes us through imaging requirements while suggesting appropriate solutions.
- Adaptive Images
A solution very similar to Etch’s in its implementation. It uses a PHP script to size and serve the appropriate images. Unfortunately, this wasn’t available when we were coding the website.
- Picturefill
This is a JavaScript replacement for markup in the style of the picture element.
- “Responsive Images Using Cookies,” Keith Clark
Clark uses a cookie to store the screen’s size, and then images are requested via a PHP script. Again, it’s similar to our solution but wasn’t available at the time.
Onto our solution.
Our Solution
With both picture and srcset HTML syntaxes seeming like too much effort in the wrong places, we looked for a simpler solution. We wanted to be able to add a single image path and let the CSS, JavaScript and PHP deal with serving the correct image — instead of the HTML, which should simply have the correct information in place.
At the time of developing the website, no obvious solution matched our requirements. Most centered on emulating picture or srcset, which we had already determined weren’t right for our needs...."
Read more :
