Re: [whatwg] responsive images srcalt proposal

On Thursday, November 21, 2013 at 3:42 AM, pghj wrote:
> I'm resending this (slightly updated) message because the first didn't
> appear to get delivered.
>  
>  

Both of your emails came through (:
> * Art-direction & matching media features/types should not be part of a
> responsive image solution.
> * The benefits of a preload-scanner are overrated when it comes to images
> from <img> elements.
> * There is a more elegant solution than srcset, src-N and picture
>  
>  

I came into the discussion a year ago with similar ideas, but have since come around to thinking that there *must* be a way to do this that works with the preloader, rather than around it.

Here are a couple of the articles that convinced me:
http://www.stevesouders.com/blog/2013/04/26/i/
http://andydavies.me/blog/2013/10/22/how-the-browser-pre-loader-makes-pages-load-faster/

As you point out, any solution that works with the preloader needs to provide it with some (probably duplicate) in-markup styling information for it to pick a source, which is messy, harder to maintain, and which feels, I dunno, sorta icky.

So if you (like me), find yourself valuing separation of concerns over performance on certain projects, what you really want is a keyword on <img> that gets the preloader to skip it. This would allow you to do whatever you want via javascript without worrying about incurring a double load. There's a spec for just such a keyword: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html

There's no equivalently simple path to "just use javascript" for a preloaded solution (and there are strong arguments that a native solution should be fast-by-default). Thus a markup-based solution needs to work with preloading.

—eric

Received on Thursday, 21 November 2013 18:56:07 UTC