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
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."
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
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…
srcset attribute and set that image’s
src to whatever
<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.