Early throughs on img@srcset in the real world

Scott Jehl — of Filament Group fame — puts together his thoughts about the new image SRCSET proposal. You can also find the Original Article written by Scott Jehl.

Strangely in the months after this article was published it was actually the srcset syntax that took most favour with the browser vendors and the <picture> approach was nearly cast to the dust pile.

Fortunately sanity prevailed and we’re now (at the time of this update) seeing a resurgence for the <picture> element.

Some early thoughts on img@srcset in the real world

Many agree that the newly proposed srcset attribute is much less syntactically intuitive than the widely appreciated picture element. I hope that the WHATWG and W3C review all of the efforts that the web dev community have put into the picture element proposal in their own community group and go back on this recent addition.

Syntax aside… if srcset was here to stay regardless of what we want, is there any way we could make it work in existing browsers without introducing unnecessary overhead or potentially buggy markup? At a glance, it looks shaky to me.

The main problem is request overhead, and attempting to work around that.

Given the following markup, existing browsers will prefetch/fetch the image referenced in the src attribute, and JavaScript can not prevent that request from going out. This means larger screen devices will request an unnecessary image for every imgset on a page – not good.

<img src="smallimg.png" srcset="..."> 

To avoid that HTTP request, we might omit the src attribute, but that would invalidate our HTML5 document, per the spec:

"The src attribute must be present, and must contain a valid non-empty URL potentially surrounded by spaces referencing a non-interactive, optionally animated, image resource that is neither paged nor scripted." 

Perhaps the src could contain a null data-uri for a transparent image, but that wouldn’t work in many browsers. It also seems like a crufty workaround.

Assuming the spec was amended to accommodate src -less img elements, it’s possible some unexpected behavior will occur when existing browsers try to render that image, since they were written to conform with existing specs.

Let’s assume it didn’t cause any issues…

<img srcset="..."> 

With this markup, some javascript could be used to parse each image’s srcset attribute and set that image’s src to whatever src in the set should apply. But then, non-JavaScript devices will receive no image at all. We’d then need to add a noscript fallback…

<img srcset="..."> <noscript><img src="smallimg.png"></noscript> 

Plausible, but there seem to be a lot of unanswered questions with how this would play out in existing browsers. A serious solution to this problem should feel more stable, in my opinion.

To the existing browsers question:

In some brief testing, it looks like several popular browsers will render the image’s alt text if src isn’t provided, so the non-JS experience in these browsers would include a box with alt text followed by the image. I expect some browsers might display a broken image icon, which would be worse.

Standardizing on a solution that requires us to omit src attributes on images doesn’t seem like a great way forward. picture still appears to be a much more intuitive answer to this problem, and it’s already polyfilled for use in existing browsers today.