[whatwg] responsive images srcalt proposal

[Fred Andrews]

There are still some pre-loader issues.  Google is promoting that the CDN dynamically optimize the content, that the user agent share enough info to allow the CDN to do so - effectively moving a UA function to the cloud and making a service out of it!  From a user privacy perspective this is not good.  To counter this, any proposal needs to be competitive, and needs to support the pre-loader being able to make the same decisions that the CDN with some UA info could - it does not need to be any better.

The <picture> element proposal addresses all the use cases.  It might be even better if it's srcset also allowed the image height and file size to be specified as in your srcalt proposal, or if at least the parsing of the srcset tolerated other attributes rather than giving up so that is could be extended with other attribute hints in future.   Could this be considered for the  <picture> element proposal?

cheers
Fred

> Date: Sat, 25 Jan 2014 16:25:13 +0100
> From: pghjvanblokland at gmail.com
> To: dhtmlkitchen at gmail.com
> CC: whatwg at whatwg.org; fredandw at live.com; lists at ericportis.com; rasmusfl0e at gmail.com
> Subject: Re: [whatwg] responsive images srcalt proposal
> 
> Thank all of you for your feedback.
> 
> 
>  For clarification, the srcalt proposal is NOT intended to specify an
> (image) pre-loading mechanism. The pre-loading strategy I described earlier
> is just a suggestion for an implementation that I came up with to show that
> page loading performance does not need to suffer from srcalt, and might in
> fact be improved.
> 
> The srcalt proposal is basically just
> 
> <img src="image0.jpg" srcalt="image0.jpg 200x150 10kB, image1.jpg 100x75
> 4kB, image2.jpg 400x300 16kB"/>
> 
> and the fact that the browser has great freedom in deciding when to load
> which image when srcalt is present (even until after the page load event
> has been fired).
> 
> The source alternatives (imageN.jpg in the example) are supposed to be
> visually identical, and differ only in resolution/quality/file size.
> 
> 
> I completely agree with Fred that too much emphasis is on pre-loader
> optimization, but that is exactly what srcalt intends to avoid. Most of the
> other proposals that I read seem to be about spoon-feeding the pre-loader.
> Srcalt just tells what image sources are available to pick from.
> 
> 
> An advantage of srcalt for authors is that they only need to worry about
> display resolutions, physical screen size and design breakpoints when they
> are writing their stylesheets, and can leave the choice of <img> source to
> the browser.
> 
> An advantage of srcalt for users is that they can instruct their browser to
> safe bandwidth/increase speed through always loading the smaller sources,
> because all sources are supposed to be visually identical (unlike in other
> proposals).
> 
> Srcalt leaves switching between visually different images to stylesheets,
> treating images and other content equally:
> 
> <div class='smallscreen'> <img src='closeup.jpg' srcalt='...' /> little bit
> of text </div>
> 
> <div class='largescreen'> <img src='overview.jpg' srcalt='...' /> lots of
> text </div>
> 
> 
> I was wondering how people feel about this separation of concerns. In my
> opinion having one <img> element representing one conceptually unique piece
> of information is superior to the 'it depends on external conditions what
> it represents' approach of other proposals (the art-direction/media
> features use cases). Anyone like to comment on this?
> 
> 
>  Thank you for reading.
> 
> Josh.