[whatwg] add html-attribute for "responsive images"

[David Goss]

On Tue, 24 Jan 2012 23:26, Ian Hickson wrote:

>
> What's the use case for doing it for images in <img> elements? Typically
> <img> elements are for content images, where you don't usually want to
> adapt anything.
>
> On Tue, 30 Aug 2011, Karl Dubost wrote:
> >
> > And as I explained elsewhere it is not a question of high/low-resolution
> > only, but about interaction contexts. Different images for different
> > surface sizes.
> >
> > Desktop: Show a full photo of Anne van Kesteren riding on a plane
> 1024*250 px
> > Tablet: Show the photo a closer shot of the plane (cowboy frame)
>  400*150 px
> > Mobile: Show a portrait of Anne with his leather pilot helmet 100x100 px
>
> I don't understand the use case. For something like a user profile icon
> surely it would be rather bad UI to use a different icon on different
> devices. I presume you don't mean a profile icon though, since 1024x250 is
> a bit excessive for an icon these days, and I'm not aware of any site that
> lets users pick different icons for different size contexts.
>

The use case is that you want to serve the same image (same content) to all
users, but you want to serve it in different resolutions depending on their
context to avoid wasting bandwidth and killing performance (especially on
mobile devices where performance is key - you don't want to download a
1000px-wide image when you're scaling it down to 320px wide to display it).

Karl's example is on dangerous ground, IMO. The different sizes of the
image could be slightly cropped/zoomed as appropriate, but should still
clearly represent the same thing - in other words, the same alt text should
correctly describe all of them.


> On Wed, 31 Aug 2011, Bjartur Thorlacius wrote:
> >
> > Bottom (top?) line: User agents should negotiate an appropriate
> > message-body size using HTTP. Sending an accept-size (or some such)
> > could solve both the problem of high resolution photography and lengthy
> > documents. The amount of split articles ("Click here to go to the next
> > page / page 4") and long search results show clear demand.
>
> I don't think that really works. You wouldn't want to get different
> results if I started with a small window vs starting with a big window and
> narrowing it. It should adapt in realtime.
>

I agree: this needs to be done in markup, not on the server with headers.
Not that users resize their browsers all that much (except orientation
changes on phones and tablets). But, yeah.


> Note that "resolution" and "number of pixels on the screen" are orthogonal
> issues. Also, note that the number of pixels on the screen is irrelevant,
> it's the number of pixels on the viewport that matters.
>
> My phone has a far higher resolution than my TV, but has the same number
> of pixels. My phone also has a higher resolution than my desktop, but
> windows on my desktop typically have far more pixels.
>

You're right - all pixels are not equal. The solution I'm going to propose
involves media queries, so things like device-pixel-ratio can be used to
address that issue.

I'm proposing this (adapted from Bruce Lawson's <picture> idea, and similar
to how the <video> element works):

<adaptiveimg>
    <img src="sweater-small.jpg" alt="Blue v-neck sweater in soft wool">
    <source src="sweater-medium.jpg" media="(min-width: 300px) and
(max-width: 450px)">
    <source src="sweater-large.jpg" media="(min-width: 451px) and
(max-width: 600px)">
    <source src="sweater-huge.jpg" media="(min-width: 601px)">
</adaptiveimg>

Yep, another new element: <adaptiveimg>. It doesn't have any attributes of
its own (except the standard ones). It must contain one <img> element,
which the author will furnish with an alt attribute and whatever else as
normal. It then contains one or more <source> elements, each with a media
attribute containing a valid media query.

The user agent should cycle through each <source> element in order,
updating the src of the <img> accordingly if the media query is matched. If
there are no <source> elements, or none of the media queries are matched,
the original src on the <img> is used. Only after this logic has completed
should the HTTP request for the image file take place (so there are no
wasted downloads). The media queries I've used in the example are very
simple, using just min-width and max-width, but in reality authors would
often include other things such as device-pixel-ratio and color/monochrome.

Non-supporting UAs would simply ignore the new elements and render the
<img> as normal, but the structure would allow authors to implement a
JavaScript polyfill if desired.

To be clear, all the <source>s should point to different sizes of the same
image — otherwise the content is being changed, which isn't what we're
looking to do here. In other words, the same alt attribute should correctly
describe all the <source>s.

I'm sure there's a lot I haven't thought of, but hopefully this is a good
start. Thoughts?