Re: srcN - Alternative to picture and srcset

[ snip ]

> 
>> 
>>> 3. In non-supporting browsers, the src image always will be http
>>> prefetched,meaning a polyfill for this syntax may not be able to avoid
>>> wasteful overhead. Element based approaches like picture can avoid overhead
>>> through use of noscript wrappers on fallback content.  Could srcN be
>>> polyfilled without waste?
>> 
>> To an extent.  If you avoid use of src entirely and polyfill with
>> script in downlevel browsers, you'll get good behavior in new
>> browsers, okay (script-gated) behavior in older browsers running
>> script, and failure in older browsers without JS.
>> 
>> Alternately, a similar strategy to what you described can be used:
>> 
>> <img src1="..." src2="...">
>> <noscript><img src="..."></noscript>
>> 
>> This is then similar to the behavior of your proposal - it's good in
>> up-level browsers running script and down-level browsers not running
>> script, okay in down-level browsers running script, and bad in
>> up-level browsers not running script (as both images will be shown).
>> This last problem could probably be worked around by adding a
>> src1="0x0_image.png" to the fallback, so the image still shows up in
>> the page, but doesn't display.
>> 
>> ~TJ
> 
> 
> I can dig it up to confirm, but I thought there were existing (popular) browsers that will make a wasteful HTTP request on <img> even if a src attr is omitted? Perhaps someone else can chime in.

It looks as it if isn’t entirely uncommon, based on http://www.nczonline.net/blog/2010/07/13/empty-string-urls-browser-update/

I wrote up some of my initial thoughts on potential polyfill patterns at https://etherpad.mozilla.org/polyfilling-srcN — I’d love to get more eyes on it. 

> 
> Potential overhead in existing browsers is my main concern with this proposal.  The ability to polyfill a standardized responsive image approach in browsers today without incurring additional overhead is very important, as request overhead is not just a future problem, but one we can and should address for existing browsers and users. At the very least, a standardized solution shouldn't make pages costlier for existing browsers, which is what I fear will happen if an img element-based approach makes unavoidable requests. It'd be good to find out how avoidable this is - hopefully it's solvable!
> 
> 
> Thanks
> Scott