[whatwg] Processing the zoom level - MS extensions to window.screen

[Charles Pritchard]

Regarding:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029557.html

My objections have been noted throughout the threads:

 > It's not possible to discover the scaling of CSS pixels to actual device
 > pixels, with the current standard.

Ian's response:

"This is by design. You shouldn't need to know the actual device pixel
depth, as far as I can tell. What's the use case?"

I've got to say, this horse has been beaten to death.

It's necessary to know CSS pixel scaling to match the backend bitmap 
with the device.
This is common, active practice on mobile devices:
  [canvas width="200" style="width: 100px;"]

This is the current "fix" for Mozilla, as they are unwilling to budge:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029475.html

Robert O'Callahan's proposal would break some existing applications, and 
though it is indeed within the bounds of the existing spec, it would 
lead to slower canvas implementations; it'd also lead to weird 
situations where canvas backing sizes are of different dimensions across 
elements -- this would again, lead to unnecessary computing when using 
resources.  I've forwarded his proposal to the FX group, as I do think 
it has strong merit as part of the SVG/CSS discussions: Canvas has not 
yet been examined from the role of SVG.

This is closer to my thinking (again from Ian):
"Either way, this seems like a graphics layer issue, not an HTML issue.  
It could be solved using media queries at the image level, for instance."

I see Canvas and the scripting environment as a part of the graphics 
layer, whereas it seems many on the list feel that the graphics layer
should not be handled by authors.

My use case, regarding Google Books, is not about printing. It was 
simply about using a computer screen, with the zoom level turned up.
That's it. If you go to Google books, and your zoom level is turned up, 
the image displayed will be upscaled, with some possible blurriness.
This could be avoided, by simply exposing the CSS pixel ratios, so that 
the image would match the correct scaling.

Glen has pointed the use case out, as I have many times before:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029558.html

It's a really simple issue, and I do not feel that it's been addressed 
on technical merit.

Nor will it be addressed, as Mozilla has given firm notice, they've 
intentionally obfuscated the value (devicePixelRatio), in
the scripting environment. I dislike seeing that kind of behavior in any 
software.

WebKit is stuck, as Mozilla won't budge. MS has exposed the values in a 
non-standard way.

-Charles