Skip to main content
Theme

Apple Annie’s Weblog


The picture element for unexpected art direction.

Sometimes I post on social media as a means of thinking out loud. Occasionally this is a rant and it gets me in trouble. Other times, if I'm lucky, it is a query or request for assistance and some wonderful, helpful follower actually has an answer or solution, or boosts my post and someone else does. In the past, this was the magic of Twitter, but we know that ship has sunk.

Recently, I was dismayed at the screenshots of weblog bits that I'd been using on posts only showing in whatever theme was applied at the time of capturing the screenshot. This meant that someone with prefers-color-scheme: light would see a screenshot of the dark theme if I'd captured something in the dark theme, and vice versa. Any normal person would probably not be bothered by this. Alas, I am not normal.

I need light and dark variant responsive images without the need for JS…must think on this.

@anniegreens@social.lol

Lo and behold, my thoughts were answered before I even had a chance to "think on this."

@anniegreens Something like this? https://codepen.io/kizu/pen/VwqpWRx

Using a picture with a source for the dark-mode image via a media with prefers-color-scheme, and the light version as the img fallback.

@kizu@front-end.social

The history of responsive images on the web goes back many years, more than a decade. It goes back to a time when the community thought up a solution and then created and maintained a polyfill to support the solution until browsers adopted it. The polyfill was flexible and worked on both img using srcset with or without the sizes attribute, and on the picture element. Honestly, that was one of the last times that I felt like we owned the web, that the web was made for us and by us.

The seminal series on Responsive Images by Jason Grigsby of Cloudfour is nearly a decade old if you can believe it, but still relevant today. I read that series. I read much of what Jason wrote on responsive images on the web, and thusly I had moved to only use the picture element for "art directed image changes".

For example, when a hero component uses a differently oriented image for a differently oriented device screen with text overlay; or when an image is cropped to avoid cutting off the head of a subject in an image, changing, again, across devices and orientations; often when content authors using the CMS framework I worked on chose a different focal point for an image before processing various crops. This idea of art direction made sense.

Not long after getting this excellent advice from @kizu, I saw another post on Mastodon requesting "anything good and comprehensive about the <picture> element" (https://a11y.info/@ben/111093314916621632), and the reply by an instructor and colleague jogged my memory about <picture> and art direction and when and why I had stopped using it for most images on the web.

@ben I may be a little biased, but my colleague @grigs wrote an amazing series of articles on responsive images for @cloudfour. Part 6 dives into <picture> specifically: https://cloudfour.com/thinks/responsive-images-101-part-6-picture-element/

Also of interest is his follow-up on client hints: https://cloudfour.com/thinks/responsive-images-201-client-hints/

And an earlier post on the use case for <picture>: https://cloudfour.com/thinks/dont-use-picture-most-of-the-time/

@tylersticka@social.lol

It felt like everything was coming full-circle. What I wasn't expecting was that changing the image for light and dark themes is also art direction, so I was missing the connection in my brain when I hadn't had a chance to "think on this" before the solution was presented to me. I remarked on the memory this triggered and got a response from Grigsby himself on the elegance of the solution.

@anniegreens @tylersticka @ben @cloudfour @kizu Makes sense. Picture element has access to full media queries so you could use prefers-color-scheme to select a different image source.

I wonder how often it is used for this. It's an elegant solution for a use case I hadn't considered.

@grigs@front-end.social

For the first time since joining Mastodon, this small series of interactions had me feeling like it was 2013 again on Twitter.

<picture>
  <source srcset="https://cdn.anniegreens.lol/assets/image/apple-annies-feeds-item--dark-theme.png" media="(prefers-color-scheme: dark)">
  <img src="https://cdn.anniegreens.lol/assets/image/apple-annies-feeds-item--light-theme.png" alt="A screenshot of a feed item for social.lol on Apple Annie's Feed on weblog, showing a user avatar, the username and Mastodon instance, the content of the item, and the publish date linked to the post." width=785 height=220>
</picture>

Soon after, I implemented the change to the images on my most recent weblog post about adding microblogging feeds and came across a remaining task to tackle.

So far the only hiccup I'm seeing by using <picture> for swapping light/dark images based on prefers-color-scheme is the inability to set that via JS. I'm already in need of refactoring my poorly slapped together theme switcher, so I guess I should plan on figuring out a solution for this at the same time. Perhaps I should just remove the switcher for now and only rely on the user's preference (except then I remember Zack's recent poll where people want both…)

Another todo item.

@anniegreens@social.lol

🌓 TBD


Post info

Links in this post:


Back to top

Featured post

Recent posts

Search posts


Works in Progress