On 3/5/2011 5:41 AM, Benjamin wrote:
On Fri, Mar 4, 2011 at 8:16 AM, Charles Pritchard <ch...@jumis.com <mailto:ch...@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:
http://msdn.microsoft.com/en-us/library/ms535868(v=vs.85).aspx

Internally, to trusted scripts, Mozilla exposes window.screenPixelsPerCSSPixel:
https://developer.mozilla.org/en/NsIDOMWindowUtils

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
consensus.

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.


-Charles


_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to