[whatwg] responsive images srcalt proposal
rasmusfl0e at gmail.com
Wed Dec 11 17:13:58 PST 2013
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"
480w 640w, 1x 1.33x 2x, webp jpg"/>
Wouldn't this sort of thing be much easier to learn/read/write? Both humans
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
> > 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,
> > which srcalt, postponed and CSS background images should be downloaded
> > 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.
> > 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
> > immediately visible to the user.
> > 4.) As soon as JS finishes, and step 2b was used, re-invoke step 3 for
> > real DOM (possibly altered by JS). Evaluate whether (too many)
> > images (srcalt/postpone/css backgrounds) were downloaded. If so, mark
> > for each category (srcalt/postpone/css) in a cache. Next time the same
> > 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
> > 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
> > 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
> > source and all CSS has been obtained. This might result in a slight
> > performance loss when responsive images are used. However, since most
> > 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