[whatwg] responsive images srcalt proposal

[Rasmus Fløe]

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
>
>