Re: [whatwg] Responsive images and printing/zooming

[Tab Atkins Jr.]

On Wed, May 16, 2012 at 6:15 AM, Markus Ernst  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.
>
> 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.
>
> 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.

I'm with Odin.  Both of these seem like simple
quality-of-implementation issues.  We shouldn't overly restrict
browsers right now, so we can see what works best in the wild.  If
necessary, we can come back through later and tighten the
restrictions.

~TJ

Re: [whatwg] Responsive images and printing/zooming

[Odin Hørthe Omdal]

Markus Ernst  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.



(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

[whatwg] Responsive images and printing/zooming

[Markus Ernst]

Hello

I try to follow the actual discussion with much interest and, I admit, 
not full understanding. If my inputs are inappropriate, please feel free 
to ignore this message.


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.


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.


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.