Re: srcN - Alternative to picture and srcset

On Sep 27, 2013, at 11:51 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Fri, Sep 27, 2013 at 4:57 AM, Scott Jehl <scottjehl@gmail.com> wrote:
>> Thanks Tab
>> 
>> A few questions:
>> 
>> 1:
>> 
>> Their most popular attempt so far, the <picture>element, only hits 2 of the
>> 3 major use-cases, and has certain aspects that implementors seem to be
>> rather unhappy with.
>> 
>> 
>> Just to clarify,which major use case does picture (or picture with srcset )
>> not address?
> 
> I was under the impression that <picture> didn't hit the
> viewport-discrimination case, unless you did the verbose "repeat urls
> multiple times" thing.

To my knowledge, Picture was designed to address these use cases specifically, and we mimic this viewport behavior using Picturefill today.

Picture's use of media queries per source element addresses the viewport use case well. In addition, resolution media queries (or optional srcset attributes if you prefer) address the screen pixel density use case as well.

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

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:07:02 UTC