Yes, I certainly understand that.
Still hoping its something we could talk about here, and that Mozilla
may have a change of mind.
Currently, within WebKit Chromium, there's a very hackish way of
calculating the zoom ratio, by comparing innerWidth and outerWidth .
This only works when there is no side bar present. The innerWidth is
returned in CSS pixels, the outerWidth in device pixels. I don't know if
that's a bug or not. I've not been able to bring any discussion about
unity in window.*Width implementations, as we're still stuck on CSS
metrics.
Here's the reasoning Mozilla has behind disallowing this information:
https://bugzilla.mozilla.org/show_bug.cgi?id=486200
Their refusal is not about the feature itself, but about whether that
feature would be exposed to untrusted scripts outside of an extension
context.
".... I don't want Web authors to have easy access to information about
screen pixels. They'll try to defeat our zooming or size things to
screen pixels, which we don't want." ( Robert O'Callahan ).
The accessibility costs of withholding this information are very real.
Mozilla's plan is to limit such information to media queries in CSS: the
very hackish result of this would mean a dozen or so css declarations,
calibrated for the Mozilla browser environment, then some JS to pull
through and see which media queries were active. A proprietary, ugly,
approach in itself.
I find it hard to accept that one man's decision to intentionally make
things difficult would have such reaching and lasting consequences.
On 11/27/2010 8:15 AM, Adam Barth wrote:
As a general rule, if Mozilla refuses to implement a feature, we're
unlikely to implement the feature unless there is a very compelling
reason to do so. Proprietary features are harmful to the web, which
is why we prefer to discuss new features in standards bodies.
Adam
On Sat, Nov 27, 2010 at 3:08 AM, Charles Pritchard<[email protected]> wrote:
The whatwg thread had no outcome other than the response of Mozilla reiterating
their prior conclusion. I've posted to WebKit for further feedback.
I don't see what broad base might develop within whatwg. In all pragmatic
aspects, webkit-dev seems to me the appropriate forum.
Moz has stated clearly, repeatedly, that they do not wish to make the
information easily accessible. This conclusion was made prior to my defect
report and was unaltered by it. As of this date, I do not believe any webkit
contributors have voiced their opinion. I'd prefer to focus on the technical
aspects and likelihood of adoption. I'm posting to webkit, as I like to see
this issue resolved within the webkit code base.
-Charles
On Nov 26, 2010, at 10:13 PM, James Robinson<[email protected]> wrote:
Are you posting here because there is something specific to WebKit in
your query or because you dislike the outcome of the WHATWG thread?
Most of us follow the WHATWG closely and generally prefer to discuss
standardization issues such as this in that forum to get a broader
feedback base.
- James
On Friday, November 26, 2010, Charles Pritchard<[email protected]> wrote:
Recently I brought this issue up to the WHATWG mailing list, without much luck.
Currently, mobile devices are given access to window.devicePixelRatio, used for
managing what are essentially higher resolution displays. See the iPhone,
Android, etc. Within the desktop environment, devicePixelRatio is not updated
on zoom events. I don't think it should be, but it's something to consider.
Such information is critical to adjusting the resolution of bitmaps, be they
from an image source or a canvas source, to be as crisp as can be.
Microsoft has gone ahead in IE9 and just exposed a collection of metrics data:
deviceXDPI, logicalXDPI, systemXDPI and "Y" counterparts.
Source:
http://msdn.microsoft.com/en-us/library/ms535868(VS.85).aspx<http://msdn.microsoft.com/en-us/library/ms535868%28VS.85%29.aspx>
The task at hand is deciding whether or not to expose this information, and
where. Technically, it's quite simple, as it's only a few floating point values
which are already available to the WebKit environment. Zoom events always
trigger a 'resize' event for window, as they alter the innerWidth and
innerHeight of the layout. That resize event is the point in which the
scripting environment would check to see if CSS pixel metrics have changed, and
adjust the page accordingly. I want to note, that I am not speaking at all
about changing how zoom works, or in any way suggesting that zoom be controlled
by the scripting environment / web authors.
I am recommending that we take a look at Microsoft's .screen extensions, and
decide whether they hold merit, and may be included in WebKit. Doing so would
mean that an independent implementation has picked up the extension, and it may
be on the fast track for standardization.
I had a rough time bringing this up with Mozilla. I'm hoping for a little more
focus here, on this mailing list. Again, I'm merely looking to have CSS pixel
metrics exposed, and I'm suggesting the MS proposal as it's certain to exist in
their upcoming IE9 release. Their proposal exposes six floating point variables
in the window.screen object, and is sufficient for current needs.
Please let me know thoughts on the matter, and try to keep focused on the fact
that we're just looking to expose a few floating points to the scripting
environment, we're not looking to change any existing behaviors in any existing
elements.
-Charles
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
