[whatwg] responsive images srcalt proposal

[Fred Andrews]

The problem with a prescriptive standard for pre-loading images is that it might be abused by content authors for other purposes.  I would like to see UAs able to implement a wide range of image loading strategies using the available information, including ignoring any pre-loading hints, and this might be necessary for reloading from a cache.

I am open to other ways to specify the available images, and there have been many proposals.

cheers
Fred

> Date: Thu, 12 Dec 2013 02:13:58 +0100
> From: rasmusfl0e at gmail.com
> To: fredandw at live.com
> CC: pghjvanblokland at gmail.com; lists at ericportis.com; whatwg at whatwg.org
> Subject: Re: [whatwg] responsive images srcalt proposal
> 
> I agree with Josh regarding preloading of images though.
> 
> I also think that the current proposals are bordering on being too
> cumbersome and verbose.
> 
> We could minimize it dramatically if only a url-pattern and the available
> options are exposed instead of a long list of explicit urls:
> 
> <img src="/path/to/foo-320w-240h-1x.jpg" width="320" height="240"
>     srcoptions="/path/to/foo-{width}-{height}-{dpr}.{format},    320w
> 480w 640w, 1x 1.33x 2x, webp jpg"/>
> 
> Wouldn't this sort of thing be much easier to learn/read/write? Both humans
> and machines.
> 
> I won't bother you with all the details here - I've tried to flesh out the
> idea in this gist: https://gist.github.com/rasmusfl0e/6727092
> 
> 
> On Thu, Dec 12, 2013 at 1:53 AM, Fred Andrews <fredandw at live.com> wrote:
> 
> >
> > Adding 'srcalt' does not seem warranted.
> >
> > The steps seem too prescriptive for a standard, but might represent one
> > possible implementation.
> >
> > I think too much weight is being put on the pre-loader optimization and do
> > not believe this should block a declarative solution that informs the UA of
> > the available image options.   Some argue that it is only for the benefit
> > of the pre-loader, that otherwise it could all be done in JS, but surely we
> > are here to settling on declarative HTML that can be used without JS!
> >
> > The src-N proposal appears to be a genuine attempt to meet all the use
> > cases.
> >
> > cheers
> > Fred
> >
> > > Date: Wed, 4 Dec 2013 18:16:39 +0100
> > > From: pghjvanblokland at gmail.com
> > > To: whatwg at whatwg.org
> > > CC: lists at ericportis.com
> > > Subject: Re: [whatwg] responsive images srcalt proposal
> > >
> > > Thanks to some feedback I got, I worked out the preloading algorithm in
> > > some more detail.
> > >
> > >
> > > It will enable efficient preloading of images in my srcalt proposal, as
> > > well as images with the proposed postpone attribute, and improve overall
> > > performance. The algorithm is meant to supersede the simple preload
> > > scanners that are currently implemented.
> > >
> > >
> > > In short, this algorithm will, when downloading is stalled by JS,
> > calculate
> > > layout on a separate DOM as if javascript were disabled, in order to
> > decide
> > > which srcalt, postponed and CSS background images should be downloaded
> > and
> > > with what priority.
> > >
> > >
> > >  1.) Start downloading all CSS, JS, and <img> without srcalt and postpone
> > > attributes (*1). Always reserve one socket for downloading each of the
> > > three file types (*2). Prioritize on CSS and JS.
> > >
> > > 2.) As soon as all CSS and the document source are downloaded, do one of
> > > the following:
> > >
> > > a.) If all JS has finished running, do layout and continue with step 3.
> > >
> > > b.) If JS is still running, build an independent DOM as if javascript
> > were
> > > disabled, do layout on that and continue with step 3.
> > >
> > > 3.) Clear the download queue for images. With the given DOM and layout,
> > > start downloading the required images from CSS backgrounds, <img>
> > > src/srcalt and visible postponed images. Prioritize on images that will
> > be
> > > immediately visible to the user.
> > >
> > > 4.) As soon as JS finishes, and step 2b was used, re-invoke step 3 for
> > the
> > > real DOM (possibly altered by JS). Evaluate whether (too many)
> > unnecessary
> > > images (srcalt/postpone/css backgrounds) were downloaded. If so, mark
> > this
> > > for each category (srcalt/postpone/css) in a cache. Next time the same
> > url
> > > is visited, delay downloading this category until JS finishes (*3).
> > >
> > >
> > >  *1.) Images without postpone attribute are required for the load event.
> > >
> > > *2.) A server might have specific performance problems serving one type
> > of
> > > file. By reserving sockets downloading can continue on the other file
> > > type(s).
> > >
> > > *3.) JS altering the DOM to such an extend that the wrong images got
> > > downloaded is probably quite rare, but this step will counter the
> > bandwidth
> > > penalty after the first visit. Developer modes of browsers should issue a
> > > warning when this occurs.
> > >
> > >
> > >  Compared to the current preload scanners, this implementation will:
> > >
> > >
> > >  * support srcalt responsive images,
> > >
> > > * support postpone attributes on images,
> > >
> > > * allow for earlier download of postponed images and CSS backgrounds,
> > >
> > > * can prioritize on all images that are immediately visible to the user.
> > >
> > >
> > >  In this scenario srcalt images can never start downloading until
> > document
> > > source and all CSS has been obtained. This might result in a slight
> > > performance loss when responsive images are used. However, since most
> > HTML
> > > and CSS downloads fast (once the server starts sending) and CSS is mostly
> > > cached anyway, in practice this will effect only a very few page visits.
> > >
> > > Depending on available bandwidth and user preference, UAs could also
> > > compensate for this delay by preloading a srcalt candidate by making an
> > > educated guess.
> > >
> > >
> > > Thank you for reading,
> > >
> > > Josh
> >
> >