Re: [whatwg] responsive images srcalt proposal

On Thu, Nov 21, 2013 at 7:55 PM, lists@ericportis.com
<lists@ericportis.com>wrote:

 Both of your emails came through (:
>
> Strange, didn't get my copy even though my list configuration says so..
Anyway, thanks for your reply!

I came into the discussion a year ago with similar ideas, but have since
> come around to thinking that there *must* be a way to do this that works
> with the preloader, rather than around it.
>

Actually, there is, but the preloader would need some redesign:

It already works fine for CSS and JS. However, for <img> elements, we have
two problems:

1. browser loads images that the user may never see.
2. any system of responsive images impossible without spoon-feeding the
preloader

Point 1 is a big issue. I see many sites that make you download an insane
amount of images that remain hidden in carousels or outside the viewport.
As a user, I would have liked a choice between bandwidth conservation and
the fabled 20% speed increase of the preloader.

The way the preloader SHOULD work, the RIGHT way:

1.) Scan and preload all CSS and JS
2.) Ignore all <img>, and <video>, <audio> without autoplay
3.) If document source and CSS are fully loaded (generally not a
bottleneck), but still waiting for JS to complete (generally a bottleneck),
build a separate DOM as if javascript were disabled. Do layout on that
(this should be very cheap), and see what images/videos/etc are actually
visible. Start downloading these.
4.) When JS completes, modifications to the real DOM may cause other
resources to be downloaded. Compare this to downloads in step 3. If many
unneeded resources where downloaded, mark the URL as 'badPreload' in a
cache to prevent the same mistake in the future.

This mode of operation has many benefits over the old preloader:

* better priority ordering for downloads
* does not download excessive amounts of unneeded resources
* allows for user preferences in bandwidth/speed management
* allows preloading of CSS background images at an earlier stage
* compatible with simpler Responsive Image schemes like the one I proposed,
because in step 3 style information is readily available.

As you point out, any solution that works with the preloader needs to
> provide it with some (probably duplicate) in-markup styling information for
> it to pick a source, which is messy, harder to maintain, and which feels, I
> dunno, sorta icky.
>

Not for the preloader I just described :)

So if you (like me), find yourself valuing separation of concerns over
> performance on certain projects, what you really want is a keyword on <img>
> that gets the preloader to skip it. This would allow you to do whatever you
> want via javascript without worrying about incurring a double load. There's
> a spec for just such a keyword:
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html
>

Yes, I'm waiting for that to be implemented. This can also be done with JS,
by moving src to another attribute, but I really hate messing up html that
way.

Anyway, I would rather have a simple and elegant Responsive Image solution
for everyone to share and rejoice in :)

Josh

Received on Thursday, 21 November 2013 21:47:33 UTC