[webkit-dev] Canvas backing resolution
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:
> 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
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
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...
More information about the webkit-dev