Could IMG@srcset be used sensibly in existing browsers?

srcsettoday.md

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.

What browsers are you seeing alt text displayed in the img is missing the src attribute. I know that's what some people have been doing for responsive image solutions based on JS.

Also, quoting @tubalmartin "Do not set an empty string for the value of src src="".
Some browsers react to this by assuming the empty string means src="/", and consequently the browser re-requests the current HTML page and tries to stuff it into the element. This is bad news for performance."

Opera was one at least. I'd guess IE will do something unexpected too... broken image icon?

Your second point is particularly troubling and valid. Thanks for following up.

Fact is, we shouldn't have to worry about these things for this. picture doesn't have these drawbacks.

This is red herring. <picture> with fallback suffers from the same problem.

Whatever solution is chosen, whether that's srcset, <picture> or <dancing-monkey> it will face dilemma of supporting non-JS clients or causing unnecessary request or including redundant <noscript>.

If you don't care about non-JS older browsers, then do <img src="data:" srcset=""> or ask Hixie to make src optional. If you care about non-JS older browsers, then <picture><img src></picture> will be as problematic.

Thanks for replying, @pornel, but I disagree.

Despite my bias against the srcset syntax, this post was intended to honestly explore the real applicability of srcset today (a draft spec deserves serious criticism), and as a result, I don't think it's as suitable for use today as picture.

picture element usage today (via picturefill)

While admittedly a little more verbose than the basic markup the community group has proposed, the markup for using picture today specified along with the Picturefill polyfill does not suffer from any of the request overhead or potential bugginess mentioned above (though, yes, it would require a noscript element), and it works as expected in all the browsers I've tested (emulators plus all of jQuery Mobile's device testing lab), with proper non-js fallbacks included to boot.

Here's the repo and readme.

https://github.com/scottjehl/picturefill/

Scott

Riloadr by @tubalmartin is probably the closest solution I know that could be morphed into a polyfill for srcset.
https://github.com/tubalmartin/riloadr

It has the same issues @pornel brought up and I think any responsive image polyfill has this issue, supporting non-JS clients. You either cause an unnecessary request, including an img src to your mobile image or include a noscript tag and exclude the img src attribute and create it with JS.

@scottjehl I must say, <picture><noscript><img></noscript></picture> is not so bad, but the <img> wouldn't be seen by picture-supporting JS-enabled browsers, so you'd have to have redundant <source> for it.

For <img src srcset> you can use any resolution image in src (if you set width/height), so you could use one of the less reliable methods to speculatively select src image server-side, and then rely on browsers to pick better one (if needed) from srcset.

Ideally, I'd like <source srcset> supported as well, to address both DPI and layout cases (srcset doesn't tackle layout adaptation).

I implemented a srcset proof of concept polyfill:

http://odin.s0.no/web/srcset/polyfill.htm

It has some shortcomings, but I think it works rather well.

Anyway, most people probably won't polyfill it, and rather rely on browsers having implemented it. srcset is actually a progressive enhancement after all. :-)

I must say, is not so bad, but the wouldn't be seen by picture-supporting JS-enabled browsers, so you'd have to have redundant for it.

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 the img tag in the polyfill gives browsers without Javascript enabled something to display, but Javascript-enabled browsers would use the including Picturefill script to parse the source elements for the image to display. There are no issues here.

Search engines, screen scrapers, RSS readers, site archivers — don’t forget that, at least for a while, many of them will only be checking out src.

In _my_ day, we surfed the web on 28.8, and we served up low-res, desaturated default jpgs that had been so compressed, you couldn't tell Aunt Gertrude from Uncle Bob. Two days later, the onLoad script would finally finish replacing all the images with the "right" ones.

It was magical.

And if XHTML had won out, ya'll would be able to see that I posted that with a "curmudgeon" tag. ;)

@velmont I think the vast majority of web devs are looking for something that works in browsers that exist today, so a polyfill that works without overhead will be critical.

@scottjehl What makes the approach I used not work? You can't have a polyfill that does programmatic choosing of an image without any overhead (javascript) when a browser does not support it.

The @srcset based minimum syntax (which gets even smaller if you don't care about broken image icon in IE) is smaller than the equivalent @media based one.

And it works in browsers that exist today, that's the whole reason I wrote the test, so that I could show that the approach would work. And it does. I guess it has some bugs, but I don't know about them, so they are hard to fix ;-)

Just realized you might be speaking about my second part of my comment:

Developers don't use polyfills

Which is true when you're coming from where I am. Looking at the millions and millions of web developers. You are in a very tight nit, small (in the web-sense) group of people who really care and are at the forefront of the web. So when you think "developers" you think about those that you interact with. That's not a representative selection at all. :-) Not that it really matters, -- but polyfill for those people is a nice thing.

Although older browsers getting slightly slower performance, the short time they're around? I can live with that, they are already used to it... :-)

Odin, the discussion is not about "older" browsers, it's about every existing browser today. Future browsers are easy. Browsers stick around for many, many years, especially on mobile devices. The entire Android 2.x platform is a great example: new devices are coming out running it every day. The browsers are ages old and locked from upgrades. It's about real users and performance. Also, the success of HTML5 is based on a polyfill (html5shiv). It seems like a stretch to suggest most html5 developers are not aware of that.

…

On May 16, 2012, at 12:31 PM, Odin Hørthe Omdal wrote: Just realized you might be speaking about my second part of my comment: Developers don't use polyfills Which is true when you're coming from where I am. Looking at the millions and millions of web developers. You are in a very tight nit, small (in the web-sense) group of people who really care and are at the forefront of the web. So when you think "developers" you think about those that you interact with. That's not a representative selection at all. :-) Not that it really matters, -- but polyfill for those people is a nice thing. Although older browsers getting slightly slower performance, the short time they're around? I can live with that, they are _already_ used to it... :-) --- Reply to this email directly or view it on GitHub: https://gist.github.com/2701939

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. :-)

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