User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-gb) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090224 Minefield/3.2a1pre In the text example, I've cloned a node and set the clone to be positioned absolute - with the position based upon getBoundingClientRect(). I would have expected the cloned node to exactly overlay the original - but it appears to have an offset. If you remove one of the <br>s the error is smaller, with noether of the <br>s then the offset appears to be as small as one px. Tested and fully reproducible in: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090224 Minefield/3.2a1pre Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:188.8.131.52) Gecko/2009011912 Firefox/3.0.6 Reproducible: Always Steps to Reproduce: 1. Just load my example page 2. 3. Actual Results: There is an offset on the cloned node. Expected Results: There shouldn't be an offset.
If you set style="text-rendering:geometricPrecision" on all the text does that fix it.
I'm afraid not. If I add style statements for the body, html, p and span tags (the only rendering elements I've really used) with text-rendering:geometricPrecision, then the offset is still apparent.
This is the right behavior. While the two <span>s have the same vertical position, one is a block while the other is an inline. And the position of the block doesn't match the position of the parent block of the inline. Which means that the vertical-align calculations are performed with different baselines. And in particular, for any line-height that's different from the font-size you will get an offset because the leadings are being added in different places (for the inline above and below the inline itself and thus affecting its position, while for the positioned text inside the positioned block). In effect, any nonzero leading is double-counted in the positioned block. Since normal line height is not equal to the font size, you get the observed behavior. Setting line-height to 1em on the positioned element should make the layout what you want. It's odd that Webkit and Opera seem to do something different here, though...
Though that may just be an effect of them rounding their getBoundingClientRect, at least for webkit.