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

[Matthew Wilcox]

Ugh, my Gmail keeps sending mail from the wrong address, let me try again:

...

In fact, please just read the blog post Bruce Lawson (Opera Software)
made summarising the last few months of effort on this, and his proposal
for a mark-up level solution (which I'm in broad support of, though there
are a lot of knotty issues with any potential solution - as can be seen by
the volume of blog-posts, comments, and articles on the topic):

http://www.brucelawson.co.uk/2011/notes-on-adaptive-images-yet-again/

...

I should add that relying on mobile-networks compressing images is not a
good enough solution either. Firstly, they don't always. Secondly, this is
about performance and device capability not mobile network behaviour.

Personally I think media should respond to detected connection speed and/or
device capabilities. That involves equipping HTML with the ability to
detect those things which is a big ask. But, I feel, very worth while in
terms of future-proofing. I'm all for headers being sent with all HTTP
requests to inform the server of device details - allowing the server to
choose appropriately. But, we also need a mark-up level solution. They're
not the same problem though superficially they appear similar.

On 25 January 2012 13:42, David Goss <dvdgoss at gmail.com> wrote:

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