W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2010

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 20 Nov 2010 21:57:02 -0500
Message-ID: <4CE88A7E.3020205@mit.edu>
On 11/20/10 3:59 PM, Charles Pritchard wrote:
> This response is from the digest: I'm glad to see activity here.
> Canvas is supposed to be resolution independent,

No, it's not.  Vector images are supposed to be resolution independent. 
  Canvas is very explicitly a _bitmap_.  It's not a vector image.

 > When a user zooms in, I need to be able to reprint my fillText
> to match their resolution.

This is a valid use case if using canvas is the right requirement, 
though it really feels like you're using the wrong tool here; if you 
want resolution independence you should be using SVG, which is designed 
precisely to accomplish that.

That said, this seems like a general quality-of-implementation issue, 
right?  Expecting the page to rerender the entire canvas on any zoom 
operation doesn't seem reasonable....  A UA could handle this by 
supersampling the canvas, for example (and in the past we've considered 
doing that for Firefox, actually).

> Boris, Rob: As an accessibility use case, this is quite important.
> Please let me know if there are objections.

I don't think it's reasonable to demand resolution independence from 
what is designed to be a bitmap format.  We really do have better tools 
for them; using them instead seems more appropriate than grafting 
poor-man's resolution independence onto canvas.

-Boris
Received on Saturday, 20 November 2010 18:57:02 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:28 UTC