[whatwg] Features for responsive Web design

[Eric Portis]

Long time listener, first time caller. This echoes some of the points Fred
Andrews and others have made here over the past few months, but I don't
think I've seen the emphasis on separation of content/presentation before.
Apologies if anyone thinks this has already been adressed (say, with the
"performance matters more than convienence" paragraph here:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037146.html
).

On Tue May 15 00:28:54 PDT 2012, Ian Hickson wrote:

> In practice, the only information regarding dimensions that can be
> usefully leveraged here is the viewport dimensions. This isn't the end of
> the world, though -- there's often going to be a direct correlation
> between the dimensions of the viewport and the dimensions of the images.

This relationship will be direct, however it will not often be simple and
requires authors to bake information about their layout into their srcset
declarations—a potentially complex and error-prone process which results in
fragile markup.

For example, let's say:

• I have a profile pic on my blog. I have a 200px-wide image (200.jpg), a
400px-wide image (400.jpg), and an 800px-wide image (800.jpg)

• My layout displays this image at max-width: 100% with 0.5em of padding on
all sides within a sidebar. By default this sidebar is folded under the
main content; I have a media query which pops it over to the right at
viewport widths >= 32em. Both the sidebar and the main content are in a
container element with a min-wdith of 20em, a max-width of 80em, and a
margin of 1em. The min-width: 32em media query stipulates that the sidebar
should have a width of 25% of this container after it pops over.  The
sidebar's font-size is 1rem (so, as long as the user hasn't zoomed, 16px).
I want to support up to 2x screens.

(like this: http://ericportis.com/etc/stretchy-images-example/)

• If we tie a responsive images markup pattern to viewport size ALL of that
info needs to go into how I write the markup for my image. Like this:

At viewport widths from our min of 20em (320css-px) to just under 32em
(512css-px):
image ddpx width = (viewport em width - 2ems container margin - 1em image
padding) * 16px/em * device-pixel-ratio

At viewport widths >= 512css-px:
image ddpx width = ((viewport em width - 2ems container margin) * .25 - 1em
image padding) * 16px/em * device-pixel-ratio

We can turn these equations around to figure out the srcset Xw (max-width
in css-px) declarations:

When the viewport < 512css-px:
viewport css-px width = (image ddpx width / device pixel ratio) + (2 ems
container margin + 1em image padding) * 16px/em

When the viewport >= 512css-px:
viewport css-px width = ((image ddpx width / device pixel ratio) + (1em
image padding * 16px/em)) / .25 + 2em container padding * 16px/em

Plug in some numbers and the srcset declaration that falls out of this is:

<img src="200.jpg" srcset="400.jpg 448w,
                           800.jpg 512w,
                           200.jpg 896w,
                           400.jpg 1x,
                           800.jpg 512w 2x,
                           400.jpg 896w 2x,
                           800.jpg 2x" />

Crazy complicated! And it would require re-writing if:

- we tweak almost anything about the CSS
- some new device bursts on the scene and we desire to support resolutions
other than 1x & 2x

Too fragile!

I should note here that for what's been called the "art direction" use
case, which straddles (or perhaps blurs) the line between presentation and
content, being able to put breakpoints in markup and tailor specific images
for those breakpoints is great. But for the simpler—let's call it "stretchy
images"—use case, where we don't want to crop or otherwise alter an image
at all, but simply have it display as well as it can, efficiently, within a
fluid layout across a wide range of viewport-sizes & device-resolutions, we
don't *need* to put information about the layout in there at all. We might
currently want to bake it in for performance reasons, but I'll get to that
in a second.

For stretchy images the only two variables that really matter (excepting
bandwidth concerns) are 1) the device pixels the image is slotting into on
the layout and 2) the resolution of the image files themselves. Given
these, load the smallest image that is bigger than the device-pixel
dimensions of its box, or, failing that, the biggest file.

If the browser can handle figuring out the layout, authors only have to
make declarations about their content, resulting in simpler markup that is
far more resilient to layout changes:

<img src="200.jpg" srcset="200.jpg 200x133,
                           400.jpg 400x266,
                           800.jpg 800x533" />

I realize that requiring browsers to figure out what size the image will
end up rendering at on the layout before deciding which resource to load
will break image pre-fetchers as they currently operate. And that
pre-fetching is crucial to performance and therefore users. But it seems to
me pre-fetchers have a lot more headroom to get smarter than authors do,
and that we should strive to keep markup for content images as free from
presentational concerns as possible.

This pattern isn't mutually exclusive with the current srcset spec. What
I'm proposing is that if authors want simpler, more robust,
non-presentational markup, they should be able to opt into it and accept
the performance penalties that result (hopefully only for a while, while
browsers and pre-fetchers adapt).


—eric


PS
It would of course be *even better* for authors if the browser could do the
work of figuring out image resource dimensions, too:

<img src="200.jpg" srcset="200.jpg, 400.jpg, 800.jpg" />

I presume this would require additional HTTP requests and incur further
performance losses.


PPS
Also I want a pony: this is all just in the meantime while everyone works
towards fast, efficient, secure & universal JPIP/JPEG2000 support, right? (:

<img src="3200.jp2" />

(Note that, regarding prefetching, browsers may have the similar problems
determining *how much* of a streaming, multi-resolution file to download
before all of the CSS is in. Though I suppose it will never be a wasted
effort to download the first renderable portion of a file, given that
higher resolution versions will all build off of that.)