[whatwg] Responsive images and printing/zooming

[Odin Hørthe Omdal]

Markus Ernst <derernst at gmx.ch> wrote:
> I read the current spec and huge parts of today's discussions to find  
> out how images with multiple sources are intended to behave when  
> printed, or when the page is zoomed, but I found no hints. I think some  
> words on this might be useful in the spec, regardless of what the final  
> syntax will be.

Both issues you are highlighting is in the domain of competing browsers
to implement in the best way for their users/device/intended use case.
They should not, IMHO, be part of the spec. I'll tell you how I see it:

> 1. Print
> When a page is printed (or also converted to PDF or whatever), both  
> "viewport" width and pixel ratio change. Are UAs expected to load the  
> appropriate sources then? This could result in increased bandwidth,  
> delayed printing, and IMHO a disturbed user experience, as the image may  
> differ from the one seen on screen. Thus, I suggest to always use the  
> resource actually shown on screen for printing.

They are not _required_ to do anything when those change.

The spec draft does have an algorithm for updating img elements though:

> The user agent may at any time run the following algorithm to update
> an img element's image in order to react to changes in the
> environment. (User agents are not required to ever run this algorithm.

<http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#processing-the-image-candidates>
(Scoll way past the first algorithm, and you'll get to that algorithm)

So it's up to the user agent to decide what to do in that case. I think
it would be very nice to substitute the picture, if you can get one with
a higher resolution. But it might even use the one it has in the
preview, and download the big image while the user is using his time
pressing options etc.

Then, when the user agent has gotten the new image, it can dissolve the
preview to use the new higher-res one - and also decide to use that one
for the print.

If it can't make the deadline (user hitting print), it can just use the
one it has. Or another user agent that likes to nag its users might
decide to nag the user.

This is a place for quality of implementation (QoI), where browsers can
compete on providing the best experience. I like it.

> 2. Zoom
> On mobile devices, web pages are often zoomed out to fit the viewport  
> width by default, the user is supposed to manually zoom in and scroll in  
> order to read parts of pages. I understand that the whole thing about  
> responsive design is to make this kind of zooming unnecessary, but in  
> practice there will be all kinds of partly responsive designs using  
> responsive images.
> Specially in cases where separate sources are given to match device  
> pixel densities, zooming might matter, as for a zoomed-out page the low  
> res image might be more than sufficient, but after zooming in the higher  
> resolution might be appropriate. Which OTOH can disturb the user  
> experience, when the images differ.

Yes, but you might get a quicker page load if you do the smallest one
first. You can load that one and then when you're done with all the
network activity, you can start a new job to download a bigger version
in the background.

You can substitute that one when you have it (or when the user zooms).


Or the browser may choose to just load the one it wants for zoom
straight away.

It's decideable! If a browser does something that's ugly, the users of
that browser will just have to bear with it, or switch to another one
(hehe ;-) ).


These are not things at a user experience level, that need to be
interopable.
-- 
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com