Bug 11644 – Absolute lengths assume 96.0 DPI

• Component: CSS
• Status: NEW

[Nicholas Shanks]

CSS lengths specified using units of cm/mm/in/pc/pt should be accurate across all output devices. This patch gets the DPI of the user's main screen and uses that to calculate to how many CSS pixels that length corrisponds.

Patch assumptions:
• 1:1 ratio of CSS pixels to device pixels
• CoreGrahics' ‘main device’ is the only device that matters

[Nicholas Shanks]

Created attachment 11564 [details]
First draft

[Nicholas Shanks]

Created attachment 11565 [details]
visual test page (requires human with ruler)

The first fve lines should all be the same length, which may but most liekely will not be the same as the bottom line. If you have an old VGA display that doesn't know how big it is, the lines will all be of equal length.

[Dave Hyatt]

Web designerss assume 96dpi.  We have no choice but to use that as the default for absolute units. 

The first Safari beta actually tried to use real DPI and the results were pretty disastrous.  Not only did we mess up the rendering of a lot of Web sites, but a lot of prominent Web developers also blogged about our mistake and appealed to us to fix the problem (which we then did in beta #2).

I could see the value in having a WebKit pref to control this, since I could see how a WebKit app might want absolute units to behave in a more desirable way, but the default should remain 96.

[Dave Hyatt]

FWIW, using 96 dpi is actually compliant with the CSS spec, since there's a fuzzy "at arm's length" rule.

[Nicholas Shanks]

"Web designers assume 96dpi." - This is what i want to change, but I can only go one step at a time, and haven't looked at the Mozilla code for four years, so I am starting here.

I think your last point is a case of the specification pandering to implementations, but I would welcome a DPI preference in Safari too (not just other WK apps). Personally I'd rather have a pedantically correct browser than to have one that is dumbed down because of inept web developers and/or designers.

An additional preference that would compliment this is to have the web DPI setting user-settable as it is in Internet Explorer ("Language/Fonts" preference screen - that browser has a nifty adjustable ruler to play with!). It would be of benefit to web developers if they could adjust the assumed DPI on the fly to check their site works at non-96.0 values, and that they were frequently made aware of the facility and encouraged to check. Screens at the moment are about 96 dpi anyway (mine are 86 and 99) so an accurate rendering wouldn't be that different. (Try setting IE to 30 or 200 dpi and go surfing, starting with the test page attached to this bug; few sites I frequent show DPI-related rendering errors)

I was aware of and loosely following the discussions surrounding Safari's early DPI issues, though I seem to recall you had fixed the browser at 72.0 with a default font size of 12 (px/pt), and you resolved it by changing the DPI to 96 so 12pt would equal 16px - and that it did not do any checking of the actual screen dimensions as this patch attempts to do, but of course I could be wrong there.

What use are the absolute units mm/cm/in/pc/pt if they are not independent from px ?
They might as well not exist. (I think pc and cm are rather redundant anyway :-)

[Nicholas Shanks]

*** Bug 9541 has been marked as a duplicate of this bug. ***

[Dave Hyatt]

"What use are the absolute units mm/cm/in/pc/pt if they are not independent from
px ?
They might as well not exist. (I think pc and cm are rather redundant anyway
:-)"

That's correct.  They are essentially useless.

[Robert Burns]

I have to say that I don't have an easy solution to this problem, but I think there appears to be a lot of confusion on this on both sides. The CSS specification was quite ahead of its time in terms of resolution (and general device) indepdendence. The OS world is just now catcfhing up with this.

With resolution indpendence successfully implemented, it is the px measurement that becomes obsolute (not the absolute measures). Then a physical inch should equal a screen inch (at least it should at the default magnification of most displays). However, it's hard to imagine what role there is in this resolution indpendent world for a pixel unit. By defining a pxel as 1/96th of an inch, the pixel becomes an abolute unit (like the other absolute units always in the same ratio). If an author does actually need a px unit (and I can't think of any reason off of the top of my head), then it's no longer available. Perhaps a new unit could be added ("pixel") that would still be available for that reason.

Take the iPhone display (160 dpi) or a larger and higher resolution display (for example a future Cincema Display  at say 192dpi). There, since size is not at a premium) the default magnification of the screen should be such that an inch on the screen should equal a physical inch (therefore, likewise for all the other absolute units). A px on that display is now 1/96 of an inch (2 device pixels). A display inch is equal to a physical inch (or it should be at the default magnification). The iPhone display is a different story because there's reason due to minmal screen real estate to change default magnification from 1:1 (virtual:physical measurement).

So it's not the absolute measures that are usesless. It's the current px measure that is becoming another absolute measure (1/96 of an inch). The other issue is one of the default magnification of a display. Here I think it should be 1:1 unless screen real estate is ilimited (as in the iPhone) or the audience distant is great (as in TV or Projection media) However, the default magnification is not something WebKit needs to worry about.  If there's a need for a genuine pixel measure (a unit relative to resolution), then implementations (and the CSs recommendation) could add something like "pixel". Again, I can't imagine what use an actual resolution relative unit would serve. Web designers have always been using it as an absolute measure (whether as 1/72 of an inch when the Mac graphical inteface arose or 1/96 of an inch when the Windows graphical interface came of age). Those are absolute (though changing) measures 

[Robert Burns]

One thing I should add. WebKit should make sure that a CSS inch equals any other inch. In other words an inch in WebKit should equal an inch in any other application running in the same environment. In this way the magnification (default or otherwise) of a display is uniform. 1 css inch should be the same length as an inch on a ruler in another application. Obviously, the OS has to provide a mechanism to ensure (and the OSs are). However, WebKit should not change a CSS inch to some other length independent of the environment inch.

[Dave Hyatt]

The CSS px is a relative unit and is allowed to scale at high DPI. 

[Robert Burns]

In reply to #10: Yes I know that a px is a relative unit and is allowed to scale at high resolutions according to the CSS recomendation. However, according to the expectations of Web designers and user-agent implementers it is not. 

As you said in comment #3: "Web designerss assume 96dpi." This makes a relative unit (one that is suppoed to be relative to the pixel resolution of a device) no longer a relative unit. It is now precisely 96 dots per inch: it is locked in a constant ratio with all the other absolute units. If a px is always 1/96 of an inch regardless of device resolution, then it's an absolute and not a relative measure. That makes it an absolute unit as well. Any unit locked in a constant ratio with the absolute units is an absolute unit. Obviously even the absolute units are relative to the magnification level. Em and Ex remain relative units. A device pixel likewise remains a relative unit. A CSS pixel become just another absolute unit (which are all functionally equivalent culturally different representations of the same absolute lenghts).

I don't see a problem with changing px to an abolute unit. Savvy content creators know to avoid px because it's not really all that useful as a device pixel. As this conventionally interpreted CSS pixel, it's just another absolute unit. The same as using pts and multiplying by 1-1/3. But I just want to make it clear (because from the discussion it doesn't seem clear) that this doesn't obsolete the absolute measure. It eliminates the px measure as defined in the recommendation (which the arms lenght and high resolution passages make fuzzy already).

Absolute measures: pt, pc, in, cm, mm, px
Relative meausers: ex em

Even the absolute measures are relative to display magnification (or the positioning and zoom of a projector). Most modern displays change the magnification level to less than 1x so that a phsyical ruler placed over the software ruler (in say TextEdit) do not equal. It is not WYSIWYG in the size sense that the term is (or was sometimes) used.

[Andre-John Mas]

It is now 2008 and MacOS X 10.5 has resolution independence, but from my tests I still see that specifying 6cm in a style sheet does not result in 6cm on screen.

A quick test with Opera 9.5, Firefox 3 and Safari 3 shows that a table specified to have width of 8cm is rendered to be 6.9cm, so at least they are consistent with each other. I tested on a 15" MacBook Pro (Core Duo) at native resolution. I assume they are all following the 96dpi assumption. I don't know the actual dpi of my screen, so I can't check.

I see the section in the specifications where it is indicated the resolution assumption for a pixel (CSS2 section 4.3.2), but for cm all I see is section 4.3.2 of CSS2 where it says:

  "Absolute length units are only useful when the physical 
   properties of the output medium are known."

CSS1 says the same thing in section 6.1.

For this reason I ask myself if the not rendering a cm as a real world cm is indeed an issue of misinterpretation? 

Are there any plans to address this issue?

[Nicholas Shanks]

You can find out your screen's DPI by downloading and compiling this:
http://web.nickshanks.com/downloads/software/sourcecode/DPIFinder.tar.bz2

It outputs information to the console so it's easiest to run it in Xcode and look at the debug console there. The app will launch and not do anything, kinda crap but it's just a quick hack. I will clean it up if there's demand.

Make sure you run the app with your LCD panel set to native resolution, it reports the displayed pixels per inch (and in millimetres) so you can get different results if you run at lower resolutions.

[Dave Hyatt]

(In reply to comment #12)
> Are there any plans to address this issue?
> 

No.  We cannot address this issue without breaking Web sites.

[Robert Burns]

Resolution independence isn't really here yet anyway, so the difference is size is not something that is directly fixed by resolution independence nor involved with anything you're seeing today. But I do think this could be fixed once resolution independence does arrive.

Consider this:

A 96dpi screen right now treats 1 CSS inch as 1 physical inch. Or in the WebView, 1 physical inch is 96 units (CSS pixels)

However, in NSView coordinates that 1 inch is 72 units wide 72 or points. On a 96dpi screen then (without resolution independence), 1 inch is 0.75" measured with a physical ruler. In other words the base zoom of the screen is 75%.

So the NSView one inch wide cannot both be 72 units and 96 units at the same time. The way to think about this is the following:

 * WebView has an internal zoom factor set so that it is 133% larger than the OS zoom factor.
 * With resolution independence the OS will scale the display according to the users needs (ideally with user defaults permitting adjustments)
 * on modern displays (e.g., 111 dpi) the OS scales the output to about 65% of actual size
 * WebKit scales its inner-application output to 133%
 * together that's about 85.45% of actual size (so the comment #12 example 8cm becomes 6.8 cm when measured with a physical ruler on the display)

So in order to fit in with upcoming resolution independence on Mac OS X (and presumably other OSs I"m less familiar with), a WebView simply needs to add a method to set and get its base zoom factor. By default it should be 1.33x so as to not break web sites (as Dave points out). However, other applications may want to set it to 1. When setting the factor to another value an affine transformation is set on the WebView to scale it accordingly. Internally this could only scale when the value is set to something other than 1.33x so as to not cause any performance hit for mainstream web use (the magic of OOP and opaque methods). Eventually, though when resolution independence becomes more widespread and users start widely varying the base zoom of their displays, it may not at all seem unusual for WebKit to display using a zoom of 1x instead of 1.33x.

However, it doesn't seem like a good idea to leave something as central as WebView as incompatible with the resolution independence of the rest of the OS.

Are there any problems caused by this solution that I have missed?

[Robert Burns]

I wonder if putting this in terms of Mac OS X resolution independence would make more sense. A summary such as:

"WebView uses 1.33 points per unit rather than 1.0 points per unit standard for an NSView"

In other words a CSS inch = 96 NSView units = 1.33 * 72 points = 1*33 * 1 inch
or 0.75 CSS inch = 72 NSView units = 72 points = 1 inch

It's important to underscore here that both CSS and NSView were both long ago designed for resolution independence (for example both use floats for dimensions rather than integers like other resolution dependent APIs). The issue then is that currently WebView does not make a CSS inch equal to an NSView inch which makes it inconsistent with other applications and even other views running in the same application on the same system.

BTW, daring fireball has a table of display resolutions for some recent (as of last year anyway) Apple models:

http://daringfireball.net/2007/06/high_res_macbook_pro#fnr1-2007-06-07

[Nicholas Shanks]

The long and the short of it is that some apps that use WebKit, whether locally running in a WebView or online via a browser (such as a canvas-based, platform-independent CAD app), will need to have 1cm in CSS == 1cm on the output screen/printer/plotter. Anything that is the wrong scale will be laughably unacceptable in a professional environment.

Variable DPI *has* to be supported for HTML-based applications, and Safari will set it to 96.0 for browsing the public internet, which is fine. My only concern is that when implemented, this ability will not be exposed in the browser as a user feature (like it is in Mac IE). That would be disappointing.

[Dave Hyatt]

Yeah sure, I think it's fine to make a pref out of the 96 number.

[Dave Hyatt]

This is not really going to be high priority for us at Apple though, since we have yet to receive a single request from any WebKit-based app to add such a feature.  I think this fall squarely in the realm of theoretical purity, but have no real objection to making the 96dpi number into a WebKit preference.

[Robert Burns]

As a WebView developer I would like to see this bug addressed. I'm surprised Apple itself doesn't also want its supporting teams to support resolution independence and all of the work Apple has put into that.

I'd just really like to see someone central to the WebKit team take the time to understand this bug. It is not about the 96dpi issue. CSS sets 96dpi as the recommended screen and print resolution. Fine. That has nothing to do with resolution independence (which is why I recommended renaming this summary). The issue is that WebViews do not fit in with other NSViews because an NSView unit is supposed to be a point —  especially in a resolution independent environment — and WebView treats the unit as less than a point (0.75% of a point). That means using two NSView classes (or their subclasses) side by side in an application where units matter will lead to the WebView being larger than the non-WebView NSView.

So in the future no one should necessarily care about whether pixels are 96dpi or 80dpi or whatever. What matters is the scale of the WebView compared to the other NSViews. Perhaps I should file a separate bug on that, but the gist of the discussion is about resolution independence and the 96dpi for pixels has got little to do with resolution independence (if anything setting a pixel to 1/96th of an inch improves resolution independence by turning a pixel into a resolution independent unit as strange as that sounds).

[Nicholas Shanks]

Then I recommend filing a seperate bug. It seems like you are changing the original purpose of this bug. I intended it to be about asking for 1cm and getting 1cm on the output medium, not what you seem to want, which is asking for 1cm and getting the same result as other on-screen NSViews would produce if asked for the same. You're not bothered if it's 1cm or some other scaled value, I gather?

I envisage something like this:

[webView scaleForInternet] -> sets WebKit to 96 DPI
[webView scaleForDesktop] -> sets WebKit to 72 DPI  (this is what you want, Robert)
[webView scaleForMainDisplay] -> sets WebKit to DPI of main display
[webView scaleToCustomValue:133.33] -> for 17" MBPs
[webView scaleToCustomValue:160.0] -> for iPhones

[Dave Hyatt]

(In reply to comment #21)
> Then I recommend filing a seperate bug. It seems like you are changing the
> original purpose of this bug. 

Agreed.  Rob, you are talking about something different from this bug.

[Dave Hyatt]

I also think you're making assumptions about how resolution independence is going to work in WebKit on OS X.  Our own thinking about it was that the CSS pixel would scale.  In other words as the view scale changes, so does the CSS pixel scale.  The ratio of 96dpi would still be preserved (thus absolute units would scale as well).  Given that information, maybe you can clarify what you want.

[Robert Burns]

Much of this bug discusses resolution independence. I apologize if I'm misinterpreting this, but the resolution independence team at Apple says that applications using an NSView should treat the units of the NSView as points. So 72 points equals one inch (again keep in mind that with resolution independence this has got nothing to do with DPI at this point which is handled at a different level separate from WebKit in a resolution independent world or a resolution independent redefined world).


(In reply to comment #23)
> I also think you're making assumptions about how resolution independence is
> going to work in WebKit on OS X.  Our own thinking about it was that the CSS
> pixel would scale.  In other words as the view scale changes, so does the CSS
> pixel scale.  The ratio of 96dpi would still be preserved (thus absolute units
> would scale as well).  Given that information, maybe you can clarify what you
> want.

 Yes, I understand that the units will scale as well. However, the treatment of WebView units as 75% of a point instead of as 1 point means that the scale of WebViews is different than all other NSViews (and all other views) on the system. So when you draw a ruler using CSS units it will be a different size than the ruler drawn in an NSView using NSView units. It creates an inconsistency between apps that is jarring to users and unnecessary. Having said that I do understand that the scale of text and such in webpages is such that web authors are already compensating for this difference so that authors might use smaller fonts in web pages than in other pages because they get scaled up by systems already (due to IE most likely).

(In reply to comment #21)
> Then I recommend filing a seperate bug. It seems like you are changing the
> original purpose of this bug. I intended it to be about asking for 1cm and
> getting 1cm on the output medium, not what you seem to want, which is asking
> for 1cm and getting the same result as other on-screen NSViews would produce if
> asked for the same. You're not bothered if it's 1cm or some other scaled value,
> I gather?

I'm a bit uneasy with bringing up this example, but it seems apt here. What about the case of projection media in a large conference halls or television media in someone's home theater. Here even more than computer displays users prefer to have things scaled at other than 100%. Isn't it better that one inch in InDesign is equal to one inch in Safari (or another WebKit application)? Why should the WebKit application always maintain a 100% scale no matter how the user changes her preferences.

> 
> I envisage something like this:
> 
> [webView scaleForInternet] -> sets WebKit to 96 DPI
> [webView scaleForDesktop] -> sets WebKit to 72 DPI  (this is what you want,
> Robert)
> [webView scaleForMainDisplay] -> sets WebKit to DPI of main display
> [webView scaleToCustomValue:133.33] -> for 17" MBPs
> [webView scaleToCustomValue:160.0] -> for iPhones
> 

Just to clarify what I want has got nothing to do with DPI at all. I'm pushing for better understanding of resolution independence and for more consistent implementation of resolution independence. Resolution independence implies that pixels dependent units are not used at all. By defining a pixel as 1/96 of an inch (which CSS 2 does) even a pixel is now a resolution independent unit (because it is not a pixel at all anymore but a unit that is always in the same ration with an inch).

I think one has to consider what a truly resolution independent device will look like from a developer and web authoring point of view and think backwards to where we are now (which is what I think the resolution independence team at apple is doing).

In that world every view is measured in points as floats (or inches or mm or cm, etc). Only low-level developers and those using OpenGL need to ever concern themselves with pixels and device resolution.  Once were at that point, it doesn't concern any of us (as webkit developers or as web site developers) what the resolution of a display is because we're now firmly in the resolution independent world (everything is in terms of absolute units even pixels are absolutely 1/96 of an inch).

Ideally similar applications should display their content at the same scale (whatever the OS default is or whatever the user selects). The scale no longer changes as the bit resolution of the screen increases. If a user likes a 133dpi 17" display at 70% of full scale, then when the user switches to a 500dpi 17" display they will likely continue to want the scale at 70% of full (though the users preferences may be effected in subtle ways by the drastically increased resolution; they're more likely concerned about the obvious screen real estate than the subtlety of the resolution).

Obviously apps such as Google Earth will not be at 70% of full scale (where one mile equals 0.7 miles :-). But for like applications, that deal with NSRulers for example, should all be consistently scaled (or it disorients users).

The issue Nick raises on the scale on the screen is then up to the user. If they want their display at 100% scale, then they will set it at 100% scale. In that circumstance a physical ruler held up to an NSRuler will match. The same physical ruler held up to an NSRuler accompanying a WebView will not match (since a WebView currently does not follow the resolution independence team's guidelines on resolution independence). However, the WebView difference aside, it is really up to the user how they want the display scaled (once we're fully resolution independent). It should not be up to the WebView to maintain 1 inch equals to 1 inch as the user scales the rest of the display in a vastly different scale (like to 50% or 25%, 300% or so on). So fixing the bug I thought this was about is completely at odds with fixing the bug Nick says this is about.

What I want to see is better adherence to resolution independence. What the other approach does is disregard the users preferences for on screen scale and maintains WebViews at 100% even as the scale of everything around it shrinks or grows drastically. That would be the wrong approach in my opinion.

How to get authors to stop authoring to IE inappropriate scaling precedence is a completely separate problem, though a solution to that too improves resolution and device independence because it makes it easier to create output that works with the same stylesheet declarations whether on high resolution printer or high-resolution display.

[Andre-John Mas]

> I'm a bit uneasy with bringing up this example, but it seems apt here. What
> about the case of projection media in a large conference halls or television
> media in someone's home theater. Here even more than computer displays users
> prefer to have things scaled at other than 100%. Isn't it better that one inch
> in InDesign is equal to one inch in Safari (or another WebKit application)? Why
> should the WebKit application always maintain a 100% scale no matter how the
> user changes her preferences.

Well I would take the approach that the 1cm specified = 1cm displayed would be correct on a standard display. By a standard display I mean anything like a computer monitor or a sheet of paper.

A projector would be a 'scaled display', therefore it would be accepted that what is displayed is a scaled version of what is specified. The other question is how many DPI is a projector, since it largely depends on the distance of the projector from the wall and I generally there is no clear feedback on the actual display size. Though how we deal with a 'scaled display' in Webkit is certainly an interesting problem and this would probably be handled slightly differently to a regular display. The other thing is trying to make things feel natural for the user, while not trying to be too smart with the approach.

Two attributes I would be tempted to see are:
 - boolean maintainScale : whether or not to follow screen scale
 - double zoom : the zoom ratio

[Nicholas Shanks]

To be clear, I wasn't advocating enforcement of physical size after scaling the page, according to the user's browser or GUI preferences, only that the CSS px-per-inch ratio be variable, before any re-scaling is applied.

[Robert Burns]

(In reply to comment #26)
> To be clear, I wasn't advocating enforcement of physical size after scaling the
> page, according to the user's browser or GUI preferences, only that the CSS
> px-per-inch ratio be variable, before any re-scaling is applied.
> 

OK. that's a much narrower issue then. To me this actually undermines resolution independence since it puts focus on pixel resolution instead of focussing on absolute units. Ideally the pixel would have never been added to CSS because it undermines resolution independence. Savvy authors have known to avoid it whenever possible. When CSS 2.0 made a pixel into 1/96 of an inch it made pixels into an absolute unit (since regardless of resolution — whether 72dpi or 1200dpi — the pixel is always 1/96 of an inch).

Making the pixel size variable places focus on pixels again when we should really just let them slip into obscurity (or be used to specify a small unit like 1/96 of an inch rather than having to type: "0.01041... in").

The second issue of widely varying resolutions for displays will already be fixed by resolution independence in Mac OS X and presumably other OSs when it is finally implemented so there's no need to do that at the WebKit level.

The other issue then (the one I thought this bug was about) is that the size of an inch in  a WebView is different than the size of an inch in an NSView. An NSRuler must be scaled differently when the client view is an WebView than when it is a ancestor class NSView. This is due to the history of IE defining a pixel to be 1/96 of an inch by default in a resolution dependent environment where one pixel also equals one point).  Authors have become accustomed to this and have scaled their text and images down compared to other content because they know that web browsers will scale them back up again.

One thought that occurred to me is that browsers could cheat down this scaling like 11% every 5 years until 133% became 100% (in 2025 or so).

[Nicholas Shanks]

The ideal solution would be for IE8 to stop supporting px units. :-)

[Felix Miata]

Is there a webkit equivalent to mozmm? Currently, I have a lot of special demo pages that, because of the 96 assumption, lie to a current Webkit (or current Opera or IE, but not Gecko) user, such as http://fm.no-ip.com/Auth/dpi-screen-window.html and http://fm.no-ip.com/Auth/Font/fonts-ptdemo.html and http://fm.no-ip.com/Auth/Font/fonts-comps-droid.html

[Daniel Upstone]

As this issue isn't really resolved and likely never will be in a good manner, i'd like to chime in late with a link containing my opinion on how we got here and the porblems faced with current solutions, as well as a simple way forward that i hope webkit will think carefully about. It reflects some comments made here too.

http://static.zealous-studios.co.uk/projects/web_tests/PPI%20tests.html

[Nicholas Shanks]

Another update on the issue, from A List Apart:

http://alistapart.com/column/responsive-typography-is-a-physical-discipline

Especially pertinent is footnote number 2 and the EDID/DisplayID discussion in the comments:

"I would much rather change the specification so that px always refers to device pixels, in always refers to actual, physical inches, cm always refers to actual physical centimeters, and so on."