W3C home > Mailing lists > Public > public-respimg@w3.org > September 2013

Re: srcN - Alternative to picture and srcset

From: matmarquis.com <mat@matmarquis.com>
Date: Fri, 27 Sep 2013 13:15:47 -0400
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Marcos Caceres <marcos@marcosc.com>, "public-respimg@w3.org" <public-respimg@w3.org>, Robin Berjon <robin@w3.org>
Message-Id: <B6E1AB14-D394-4D13-872C-326980598A4E@matmarquis.com>
To: Scott Jehl <scottjehl@gmail.com>
[ 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 isnt 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  Id 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
Received on Friday, 27 September 2013 17:13:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:40 UTC