Skip to content

Instantly share code, notes, and snippets.

Created May 15, 2012 13:52
Show Gist options
  • Save scottjehl/2701939 to your computer and use it in GitHub Desktop.
Save scottjehl/2701939 to your computer and use it in GitHub Desktop.
Could IMG@srcset be used sensibly in existing browsers?

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.

Copy link

scottjehl commented May 16, 2012 via email

Copy link

odinho commented May 16, 2012

Scott, well, whan I say "older browsers", I do mean the ones of today.

Even without the polyfill for @srcset the fallback story is good enough already, so people will see the image as they're supposed to. It's not taking anything away that you couldn't already do. Ofc, hoping to get to the future real quick.

Anyway, I have not gotten any criticism on the proof of concept polyfill, which is what I wanted to discuss. I'll let the rest slide, it's not that interesting to me. :-)

Copy link

@notasausage: I think you've missed the part where I was talking about new browsers in which the polyfill wouldn't activate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment