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>