Article Continues Below

After almost three years in pursuit of a standardized solution to the problem of responsive images, the Responsive Images Community Group is excited to announce that the picture element is officially coming to a browser near you. Once it lands, we’ll see the trend toward massive, bandwidth-heavy responsive websites begin to slow—and hopefully, reverse—over time.

Since starting out, the Responsive Images Community Group has evolved from a handful of passionate developers sending emails to an organization producing detailed specifications alongside WHATWG and HTML WG members and holding summits attended by representatives of all the major browsers. It took us a while to learn all the rules, but we’ve gotten pretty damn good at playing the web standards game.

When a company is interested in seeing a feature added to the web platform—something that they feel stands to benefit developers and users alike—they invest. After getting a formal thumbs-up from browser representatives, they’ll contribute their employees’ hours to seeing that feature through—from writing the initial proposal to submitting the code that brings that feature to the browsers. Adobe’s work on the WebKit project is a great example of this process in action.

Unfortunately, the last step is the one where we saw ourselves coming up short, for sheer lack of time: submitting the code to land the feature itself. The picture element specification came to life during evenings and weekends, thanks to the efforts of dozens of designers and developers just like you—mailing list conversations took place during desk lunches and Friday nights spent in front of a screen. Blog posts were—and are, in fact—written on crowded commuter trains. We can compete on determination and willingness to put in what time we have, but we just don’t have as much time as a dedicated team of employees. Writing browser patches takes that kind of time.

For that reason, the RICG recently asked the community to sponsor Yoav Weiss’s work on the Blink and WebKit implementations of picture , and together we’ve managed to raise over $10,000 in a little more than a week—enough to cover several months of full-time work on implementation.

Having helped write the spec and prototyped picture in Chromium before, Yoav will know many of the the potential gotchas right out of the gate. In the meantime, the Blink team has plenty of work to do on their side, well beyond just reviewing Yoav’s code. This is a collaborative effort—adding the new code for the picture element means a lot of changes to Chrome’s internals, and those are best left to the experts on the Blink team. Blink developer Christian Biesinger is our point person there, and he’s already working hard to pave the way for picture . Without Christian’s changes throughout the rendering engine, getting picture into the DOM wouldn’t be possible.

Alongside Firefox’s upcoming implementation, spearheaded by Mozilla’s Marcos Caceres—of RICG fame himself—and John Schoenick, this will give us coverage in Firefox, Opera, Chrome, and hopefully soon, Safari. Our aim is to have picture land in the majority of common rendering engines within the year.

We’re putting a lot on Yoav, I know—but I also know that he’s the right person for the job, and implementation is already well underway. Let’s clear the way for him, and together we’ll do something that has never been done before: introduce a feature to the web that was specced, tested, funded, and implemented by the community.

Together we have an opportunity to contribute to the web in tremendously meaningful ways: by introducing a feature that could reverse the trend toward massive, resource-heavy responsive sites, and by further changing the role of web developers in web standards from spectators to active participants. We have a chance to provide a solution to our fellow developers and, above all else, provide a better experience to users—not just our users, but all users of the web.