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.
I think you missed the point of the Picturefill polyfill, @pornel. As I understand it, and @scottjehl can correct me if I'm wrong, the
noscript
tag around theimg
tag in the polyfill gives browsers without Javascript enabled something to display, but Javascript-enabled browsers would use the including Picturefill script to parse thesource
elements for the image to display. There are no issues here.