[whatwg] Processing the zoom level - MS extensions to window.screen
chuck at jumis.com
Fri Dec 31 17:17:06 PST 2010
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.
"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:
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:
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
WebKit is stuck, as Mozilla won't budge. MS has exposed the values in a
More information about the whatwg