[webkit-dev] Canvas backing resolution

Charles Pritchard chuck at jumis.com
Sat Mar 5 09:23:29 PST 2011

On 3/5/2011 5:41 AM, Benjamin wrote:
> On Fri, Mar 4, 2011 at 8:16 AM, Charles Pritchard <chuck at jumis.com 
> <mailto:chuck at jumis.com>> wrote:
>     I'm hoping for a resolution to this issue, as we do use the canvas
>     tag, and our canvas elements appear a little blurry on some devices:
>     without a solution, some of our users will have to manually adjust
>     the "sharpness" of the site... adjusting a website until it
>     comes into focus seems a bit strange.
> For reference: in November, there was a thread on the whatwg mailing 
> list regarding this problem: 
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-November/029072.html
> If that is something we want to solve, that should go through 
> standardisation in my opinion. There are already too many methods 
> available, let's not create a new one :)
As with applying css to things like scroll bars, Mozilla is immovable in 
their position.

WebKit and Mozilla currently take different routes on items like css on 
scroll bars and on window screen units.

You can simply compare the MS/WebKit window.outerWidth/innerWidth and 
window.screen objects to Mozilla's to see that divide.

Mozilla's current requirement of using CSS selectors falls within 
existing practice. And I posted their method at the start of this thread.
-webkit-min-device-pixel-ratio and -moz-device-pixel-ratio

Microsoft's extended window.screen does not use any existing standards:

Internally, to trusted scripts, Mozilla exposes 

I'm all for standardization here, but like other UI items, Mozilla has 
as a policy, obfuscated their access.
As CSS selectors are working in FF4, and WebKit supports a similar 
selector that seems a good place for

Canvas has been in for some five years now, and this issue has still not 
been addressed. I'm a bit frustrated,
as it truly is a matter of exposing a single floating point value to the 
scripting environment.

The consensus response at whatwg seems to be that the value should never 
be exposed to the scripting
environment [though the css selector inadvertently does so], and that in 
the long-term, the resolution
will be managed by the UA/implementation.

Again.. this issue could have been fixed five years ago. I'd like to see 
it addressed this year.
My current webkit hack will not work in the long term. IE9 
[intentionally] and FF4 [inadvertently]
expose the value I need. Let's do something for WebKit.

I'm fine with: window.webkitPixelRatio, or any other manner to address 
this accessibility issue in the short term.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110305/9a9a2b26/attachment.html>

More information about the webkit-dev mailing list