Re: [whatwg] responsive images srcalt proposal

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@gmail.com
> To: whatwg@whatwg.org
> CC: lists@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

Received on Thursday, 12 December 2013 00:54:14 UTC