We’ve been clamoring for a solution to responsive image, and now there’s a suggested solution to one and we are like “oh my gosh, what have we got?”
It is SO complex which is a barrier to adoption.
Is it complex? YES! So were gradients (and still are!), but people use them all the time!
Did you know that if you have a jpeg with dimensions that are divisible by 8 or 16, they compress better than if not? PNG and JPG compression work differently, do we think about that decision correctly? Probably not all of us all the time. The point? Optimizing images for web is difficult, it is STILL difficult, and it has gotten a lot easier, but that doesn’t mean it’s not a complex thing. So, while the solution to dealing with responsive images is complex, that doesn’t mean it won’t get easier or that we won’t get used to just doing it like we have with gradients and images for web.
<picture> element discussed..
srcset – we can set 1x and 2x descriptors, but we need more source files – we need more than a single density and double density option.
To achieve that, we have a width descriptor we can set. This works pretty well for images whose widths are close to the size of the viewport. But as the viewport get bigger, the connection between the viewport size and the image size kind of breaks.
How does the browser pick the best source???
All the browser knows is the size of the viewport. The images are downloaded before size is known. Knowing the viewport size alone doesn’t help us.
The pre-parser is why we can’t solve responsive images with CSS, JS , or a magical new image format.
The unicorn format promises this idea, that allows the browser to download portions of an image… However, we need to know the size of the image and the page but again that is information the browser doesn’t know.
How to fix that:
We declare, using a media condition of “sizes” (subset of media queries) to set max width and length of the image based on that.
100vw = 100% of the viewport
sizes=”(max-width: 480px) 100vw, (max-width: 900px 33vw, 254px”
These can be absolutes, they can be calculated: calc()
Using srcset and sizes allows browsers to be smart.
These are both parts of the picture specification, so when do we use pictures?
WHEN DO WE USE <PICTURE>?
For Art Direction
Your picture element has:
- media queries
- full srcset (all capabilities there)
- multiple sources <source>
- image <img> element required (it is our base, we’re always going to start from that)
Example: Shopify uses <picture> on the homepage to present either a tall or a cropped image of a person depending on the size of the device.
To Provide Different Image Formats/option
You could use the <source type=”image/svg+xml” srcset=”logo.sml”> to declare different types of images.
The media attribute on <picture> is optional. If all you want to do is provide different image sources, just skip the media attribute.
So far we’ve been talking about inline image in html.
What about CSS? We need to decide if we’re talking about art direction or resolution switching.
With resolution switching, there’s something very similar to srcset, called image-set(). It was a precursor to srcset but it was forgotten so it does not yet support image width.
image-set can be used anywhere that takes image (border-image, background-image…)
In cases of art direction, the art direction may dictate image breakpoints.
But for image breakpoints for image resolutions switching, there really isn’t an indicator for the breakpoints…
Resize browser until something looks bad and then that’s a breakpoint, boom! You could end up with quite a few breakpoints depending on all the content elements on the page! You could have different breakpoints for column changes, for image, and for a weather widget you’ve got…
What is a sensible jump in file size? Images compress differently!
Could we maybe make a performance budget for responsive images to help us make informed breakpoint decisions?
What is the cost of flexible images? Images that resize in the browser are a feature of responsive design. So let’s look at the cost of that feature.
So what if we set a performance budget of 20K per image for responsive images? You may have 3 image breakpoints, or 1 breakpoint, or 7 image breakpoints depending on the complexity and size of the image in question!
How to deal with image breakpoints? It’s not a science yet… Pick representative images and test how many breakpoints you’ll need. You’re going to want to do a responsive images audit so this doesn’t get away from you.
Real life example: HERO image
Educate the designers on the client side? Ask THEM to pick the breakpoints? Cruel.
So what they did instead was go off of the font size on the HERO image – the font size was never smaller than 18pt font, so they took the image with 18pt font at the largest size they would have ever used for a responsive HERO image on the site, and shrunk it in the browser until it was not possible to read the text on the image, and that was a breakpoint. Then they took that second, smaller image they created and did the same thing, shrinking it until the text was not legible, and that gave them another breakpoint.
Image audit for the site they were working on (super large site):
They came up with a table that would give the company the format, size, markup tactic, and notes for the 6 different types of images they used on their entire website.
BIG HOPE: Automation for Responsive Images
There is RICG Responsive Images plugin for WordPress and a few other tools that can be used.
I know responsive images can seem daunting… but remember, you’re not alone. If there’s ever been a generalized problem for web developers, something like images is going to be that! Every site that he is aware of has to figure out how to handle images. Since sites are trying to shift to responsive design, lots of us are trying to solve this problem.
As people experiment, as YOU experiment, there will be written content on how we’re solving the problem.
There will be more tools 5 years from now than there are now, but we need to take the first steps to start implementing this on our websites right now.
Make decisions on how to handle responsive images on your sites and write about it because we want to know what you’re doing!