Hi Andre,
On Jun 24, 2008, at 5:04 PM, Andre-John Mas wrote:
Because of the move to resolution independence on the Mac, I decided
to see what would happen if I indicated a table using centimeters.
What I found is that what was indicated was not what was displayed.
The computer being used for this test is MacBook Pro (Core Duo), with
the built in screen and using native resolution.
A test case is added at the end of the file. In the test case the
table is specified to be 6cm wide, but is in reality 5.1cm wide. Is
there something I am missing here, or is this something that should be
flagged as a bug? What should the expectations be?
BTW I decided to compare this with Firefox 3 and Opera 9.5 and the
results are not consistent:
Opera 9.5 results in 6.9 cm
Firefox 3 results in 6.9 cm
Some of this discussion has moved to the bugzilla system, but I
thought it might be a topic worth discussing here too. Keep in mind
that resolution independence is still coming and not yet ready for
prime-time. So any tests conducted without specifically enabling
resolution independence, will not reflect resolution independence on
Mac OS X 10.5.x. Also it is important to understand that even with
resolution independence we should not expect users to change their
base zoom to 100% just because resolution independence supports that.
Certainly some users will want that, but many users have become
accustomed to the greater screen real estate afforded to those of us
with a base zoom of 70% or even lower.
That means that even if WebKit treated 1 point in CSS units as 1
point in NSView units (which it does not currently do), that would not
necessarily equal 1 point on a physical ruler for many users. Having
said that I do think WebView should be compatible with the resolution
independence of the other views on the system and I've outlined a way
that it could be made so without breaking compatibility (it is
outlined on bugzilla). Basically it involves adding setters and
getters to a webview to permit changing its base zoom from the system
default. Currently WebView uses 1.33x base zoom from the system
default. For Safari and other web browsers this makes sense to do to
meet the expectations for users and make type readable. However, I
think other applications may want to use a WebView with a standard
1.0x base zoom (compared to the rest of the system). Allowing
applications to change the base zoom of a webview can fulfill the
needs of both users (perhaps this is a method that belongs in the
parent NSView class). Some applications may even want to provide a
user default setting to alter the base zoom for webviews to suit the
users needs. In this way the user could change either the base zoom of
the OS or independently alter the base zoom of an individual WebView
using application.
Take care,
Rob
[1]: https://bugs.webkit.org/show_bug.cgi?id=11644
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
