just a random minimal page to demonstrate the zooming random woes. <html> <body> <table> <tr><td> <table style="border: solid 1px;"> <tr> <td style="height: 20px;"> </td> </tr> </table> </td> <td> <table style="border: solid 1px;"> <tr> <td style="height: 7px;"> </td> </tr> </table> <table style="border: solid 1px;"> <tr> <td style="height: 7px;"> </td> </tr> </table> </td></tr> </body> </html>
s/go to make zoom level/go to max zoom level/g
I just tested this in Opera and IE7 in both x+x is always 2x, while in Opera a letter of with x px always stays x px, in IE7 this changes but the total span is at least always the addition of the two smaller spans. Not that IE7 page zooming is otherwise fundamentally broken :-) (And Opera I could not deeply check on my application, because I can't use it, because of the broken onKeyPress handling...) I also noticed there is a <br/> to much in the example of Comment #2, just make it: <span style="font-family: monospace"><span id="a3"><span id="a1">W</span><span id="a2">W</span></span> Problem stays the same. Kind Regards, Axel
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core
QA Contact: general → layout
Hardware: PC → All
We support subpixel layout so a span can have width 10.5 pixels, for example. But offsetWidth always returns an integer, the rounded value of the true width of a span. So for example you could have two spans of width 10.3 each. They each have an offsetWidth of 10, but together they have an offsetWidth of 21. Use getBoundingClientRect to compute your widths and the problems should mostly go away, because it can return fractions.
Robert, as far I recognized the pixels I get returned for e.g. offsetWidth do not repesent the actual pixels on screen at a certain zooming level but (roughly) the amount of pixels it would have been, if at zooming level 100%. So if I set a div to be 100px wide, and ask its offsetWith while at zooming level 150% it still returns (roughly) 100px, never 150px. But now its like 102.34px ... So it is IMHO a logical falacy. Since, shouldn't the JS ideally not be able to "see" (say bothered with) current zooming view? Even not having to start to worry about subpixels?
(In reply to comment #7) > Robert, as far I recognized the pixels I get returned for e.g. offsetWidth do > not repesent the actual pixels on screen at a certain zooming level but > (roughly) the amount of pixels it would have been, if at zooming level 100%. That is correct. > So if I set a div to be 100px wide, and ask its offsetWith while at zooming > level 150% it still returns (roughly) 100px, never 150px. But now its like > 102.34px ... If you actually use width:100px on the div, and no borders, then offsetWidth should always return 100. Do you have a testcase that shows otherwise? > So it is IMHO a logical falacy. Since, shouldn't the JS ideally not be able to > "see" (say bothered with) current zooming view? Even not having to start to > worry about subpixels? No, because the layout depends on the zoom factor. See http://weblogs.mozillazine.org/roc/archives/2007/10/a_tale_of_two_z.html for more information.
Hmmm, There is one thing I do not understand, when I first read your comments first I thought, oh! maybe the spans had never an integer width at 100% zoom to start with. But something subpixel and only got rounded to integer. But thats not the case 100 double-u do have exactly the 100 times the width of a single double-u. So when the browser tells me the offset witdth is say 7px this should stay 7px no matter which zooming level you are with. And when you don't have subpixels at 100% zooming views, isn't it a bug subpixels get introduced as soon you get to any zooming levels?
You do have subpixel sizes at 100% zoom on Linux and Mac. We don't have them on Windows just because Windows GDI rounds all text metrics to integer device pixels. But when you zoom in to say 200%, then if Windows tells us a character is 19 device pixels wide, that's going to be 9.5 CSS px.
I am testing on Linux, and since 100 double-u is exactly 100 times the width of a single double-u I'm conclude that in this particular case no subpixels are involved at default zooming stage. Take marijns example. Okay he does get the exact fractionals value. http://martijn.martijn.googlepages.com/b.html But why is 7px at 100% zooming stage, suddendly reported as 7.199px when zooming on step in? Shouldn't it always stay 7px?
No, because of glyph hinting.
But Opera and IE don't have changing offsetWidths on different zoom levels. I guess they don't use glyph hinting?
They probably do use glyph hinting because the text looks bad otherwise especially at small sizes. But I don't really know what they do. You might be able to figure it out with some clever experiments.
You need to log in before you can comment on or make changes to this bug.