Designer and developer Mat Marquis has outlined on the W3C responsive images community group (RICG) the state of the <picture> specification. He reported on the group's new Twitter account (@respimg), its new formal home on GitHub, and where things stand regarding the specification. He said both <picture> and srcset are now being handled as 'extension specifications', developed independently of the HTML spec.
The two proposals are being worked on to be complementary, and there's hope browser representatives will collaborate. Marquis stated no decision-maker has the final word, as outlined in more depth by Marcos Caceres on the W3C mailing list. He added that there's now "steady progress on a long overdue solution to a very real problem" and that the community was "bringing about changes to the way the web is built".
.net spoke further to Marquis about the proposals, how <picture> and srcset can work together, and the benefits <picture> would bring to designers and developers.
.net: How will development of <picture> and srcset independent of the HTML spec benefit everyone?
Marquis: I think this is great news for groups like ours – namely, we're not waiting on a single person or group of people to give the thumbs-up or thumbs-down to a proposal. Future community groups will be able to do what we've done – work through a problem, gain consensus, and publish a spec – and it'll be given a fair shot so long as there's interest from implementors.
With regards to the <picture> versus srcset situation, it's good news, because the two specifications can peacefully coexist. We're not waiting on anyone to decide whether one or the other goes into the spec, and we can focus on ensuring the two solutions work together to address all the use cases we've outlined in the RICG.
.net: So how do the two proposals complement each other?
Marquis: The <picture> proposal leans on srcset as a sort of short-hand for resolution-switching, while still using familiar media queries to handle selecting a source element in the first place. I like it because it keeps the two concerns somewhat separate. First, we focus on getting a screen and layout-appropriate image source selected. Then, we select the correct resolution of that image. Now, there's nothing preventing you from using existing pixel density media queries to accomplish the same thing, but if you wanted to make use of the terseness of srcset, you could.
Likewise, while less flexible than <picture>, one could use the extended srcset syntax to select the most appropriate source and resolution on an img tag – say, in the event you know you'll only be working with a single pixel-based breakpoint. It can be thought of as more of a less-featured shorthand.
.net: What are the specific benefits of <picture>? Why are you fighting so hard for it?
Marquis: The most important feature of <picture> is its flexibility. By making use of the familiar media query syntax, we'll have access to an ever-expanding list of ways we can tailor our asset delivery. For example, if Microsoft's proposed high contrast mode media query gains wide acceptance, it would afford us the opportunity to tailor our images to that browsing context. We'll be able to use min-width or max-width media queries to ensure our images stay appropriate to the way we spec our layouts, and relative units like ems to ensure our images remain appropriate for the user, regardless of their zoom level.
