[whatwg] responsive images srcalt proposal
Fred Andrews
fredandw at live.com
Wed Dec 11 16:53:48 PST 2013
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
More information about the whatwg
mailing list