User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36 Steps to reproduce: Let's consider the following situation: <div style="display:block"> <span style="display:inline"></span> </div> under default values of all the other CSS styles. Let's calculate the following difference div.getBoundingClientRect().top - span.getBoundingClientRect().top Actual results: In Firefox (WinXP, Win7) the difference is amazingly 0.5px. Expected results: One would expect the difference to be 0px. This is the case in Chrome (WinXP, Win7), IE9, IE10, IE11 (Win7). The issue happens when the child is inline. If it's inline-block or block, the difference is zero.

> One would expect the difference to be 0px. That depends on the exact font metrics of the font being used, no? For example, when I load your testcase I see a difference of 1.6px, not 0.5px. The relevant spec text is: The height of the content area should be based on the font, but this specification does not specify how. A UA may, e.g., use the em-box or the maximum ascender and descender of the font. (The latter would ensure that glyphs with parts above or below the em-box still fall within the content area, but leads to differently sized boxes for different fonts; the former would ensure authors can control background styling relative to the 'line-height', but leads to glyphs painting outside their content area.) On the other hand, the height calculation for the block _is_ defined, in terms of the line height. So if the height of the inline doesn't match the line-height, you get leading which is what you're observing. You can see this in this testcase: data:text/html,<div style="background: yellow"><span style="background: purple; color: white;">Some<br>text</span></div> Note that the heights of the inlines are different in different browsers; in some they match the text used and in others they're just the default line-height of the block

Oh, that spec text was from http://www.w3.org/TR/CSS21/visudet.html#inline-non-replaced

Or for more fun, try data:text/html,<style>span { background: purple; color: white; }</style><div style="background: yellow; font-size: 50px"><span style="font-family: Times;">Some</span> </div> and observe the differences in heights and positions across browsers....

Hello Boris, Thanks for your quick response! I didn't think about the line-height and font families / font sizes here, I've read your comments and Eric Meyer's article [1] and I understand the topic better right now. Obviously, if line-height is big, the discrepancy will be non-zero. I didn't know though that font size/family can be of significance also here. I've done some more tests for different fonts and sizes. It seems Chrome is also affected but under higher font sizes than Firefox. Q: Is there a nonzero discrepancy between child.getBoundingClientRect().top and parent.getBoundingClientRect().top for certain font families and sizes? (assuming line-height:normal, tested for integer values 1px-100px, Windows 7) Firefox: -------- ! times new roman >= 1px ! arial >= 1px OK tahoma, verdana, courier new, georgia, garamond never Chrome: ------ ! times new roman >= 36px (varies with browser zoom) ! arial >= 46px (varies with browser zoom) OK tahoma, verdana, courier new, georgia, garamond never IE11 ---- OK times new roman never OK arial never OK tahoma, verdana, courier new, georgia, garamond never (you can run this yourself with the new attachment to this bug). TL;DR: Don't use Arial nor Times New Roman for the web unless you like being surprised in edge cases like this, and check your custom fonts accordingly. It's interesting to note that IE11 seem to always return 0, regardless of font size, family, browser zoom level. Coming back to the topic, is this a WONTFIX then? [1] http://meyerweb.com/eric/thoughts/2008/05/06/line-height-abnormal/

> It seems Chrome is also affected but under higher font sizes than Firefox. Oh, interesting. I wonder whether they're doing some sort of pixel-snapping which basically hides the problem until the half-leading ends up >1px or something. I _think_ this is a wontfix, but worth double-checking with someone who really understands how text layout is supposed to work..