(Castles are awesome. | Photo credit: Todd Gardner.)

Practical HTML for adaptive images

Greg Ochab
Highland
Published in
5 min readNov 26, 2019

--

Previously, on Practical HTML for responsive images

  1. I talked about the importance of responsive images on a web where big, beautiful images are desirable.
  2. I dug into the WEBP, JPEG 2000 and JPEG XR file types, and decided why WEBP was the only version I cared to support. I also covered some of the tools you can use to generate WEBP files.
  3. I gave you HTML for responsive images that you can confidently use in most cases.

I also promised a followup post where I would cover the code for adaptive images. This is that post.

What is an adaptive image?

Unlike a responsive image — which is exactly the same crop regardless of size — an adaptive image is an image that changes crop depending on the context.

That cool castle image from above scaled with different crops and aspect ratios for different browser sizes.

What we want to do:

When serving adaptive images on the web, I want the following:

  • I want my markup to provide the browser with all the images, and for the browser to choose what’s best.
  • I want to use modern the modern format WEBP, with JPG images as backups.

Let’s get into the code.

The Code

For a version of this code with all the comments stripped out click here.

We’ll break down the logic the browser goes through when it reads the code, then we’ll break down key formatting of the code itself.

The Browser Logic

The thought process the browser has when it sees this code:

  1. <picture> : A picture! 🆒
  2. <source> : I’ll assess the element before deciding whether or not I should display it. 🔎
  3. media= : Does this match my screen size? Either: Yep, looks good! 👍 (OR) Nope! Let’s move onto the next source element 👎
  4. type="image/webp” : I’m a modern browser and can handle this no problemo. 💪
  5. Now I’ll choose the image file that is the resolution I want, hop down to <img> and grab the alt, class and style elements, and display the image. Easy peasy! 😎

The Code — Elements and Formatting

I’ll do an abbreviated version of this since we went over it in the last post.

<SOURCE> and <IMG>

You can think of <source> as an updated version of <img>. Newer browsers can read it, but older ones can’t, so you can use them together to support both.

The most critical piece to displaying <source> is that you MUST put the modern formats first. So, your WEBP files must always come before your JPG files, as the browser will display the first one that matches its criteria.

SRCSET=

A refresh on this: we are telling the browser the path to our image, and the actual width of that image file. That’s why we use w instead of px; w indicates actual image file width, not display size.

So what image sizes should we use? In this case I’m using images at 7 different sizes: 1x (the base size), .5x, .75x, 1.25x, 1.5x, 1.75x, and 2x.

This seems like a lot, but it’s not. While I’ve not done my own deep dive into image sizes, this test run by Paolo Minoni indicates that we should use at least six or seven images. So don’t skimp on this and try to get away with two or three options.

Do it right, or else I’ll be doing this:

And trust me, no one wants to see my ugly cry.

Loading next-gen image formats

We’ve covered adaptive and responsive images, but we can also combine the two methods for loading next-gen image formats.

Let’s pretend like there’s a new brand image format that we want to use called NEXTGEN*. This hypothetical format is for photos, but the quality is so good and the filesize is so small that we only ever have to load one version of this photo.

*Any name or likeness to existing formats is entirely coincidental.

The problem is that support for this filetype is iffy, so we need to make sure we have a reliable and responsive JPG backup. In order to accomplish this, we can combine both the adaptive and responsive methods. Here’s what that might look like:

It’s pretty easy to see what’s going on here: our overall structure is that from our adaptive method, but when we load in our backup image we are using the responsive method.

If you’re savvy, you’ll notice we missed an opportunity: why not use WEBP as a primary fallback, and JPG as a secondary fallback? Smart move my wizard-friend. That would like like this:

It’s super effective!

Summary

That’s really it. Though our code for adaptive images is more verbose than that for responsive images, it is much easier to understand.

Whelp, that’s all folks.

I wrote these two posts as a reference for myself, and so I could easily share my learnings with others on my team.

I feel confident in implementing images now, but would love to hear thoughts from others; does this answer your questions about HTML for images? Do you have any big questions still nagging at you? Let me know in the comments below.

--

--

Greg Ochab
Highland

I'm a product design lead from Chicago with over 15 years experience. https://ochab.co