User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100529 Minefield/3.7a5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100529 Minefield/3.7a5pre I noticed a difference in the way a web page that I maintain displays in minefield with html5 enabled. In the testcase url the black line (a part of the background image) appears too high. In order to get it to display the way I want in minefield I need to change the css height in the boxtab-blue div to 40 pixels from 37 pixels. In other browsers that I have tested I set it to 37 pixels. Reproducible: Always Steps to Reproduce: 1. Go to URL 2. View in Minefield and compare to IE, Chrome or Firefox 3. alter css height in boxtab-blue div to change the behavior. Actual Results: the bottom of the background image displays in a different place with minefield compared to other browsers Expected Results: the bottom of the background displays in the same place on all browsers.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100529 Minefield/3.7a5pre There is no difference for me. Compared with IE8, Opera 10.5, Chrome

It turns out gfx.font_rendering.directwrite.enabled has to be set to true for this to show up.

So you have to have dwrite enabled _and_ the html5 parser enabled to see the problem? Or just dwrite?

Also, can you perhaps post screenshots of your rendering with and without dwrite enabled?

Cannot reproduce with html5.enable=true & gfx.font_rendering.directwrite.enabled=true

This does not depend on the html5 setting. It shows up on my system with it enabled or disabled. I just assumed originally that it was html5 related.

Hmm. So on Mac, your testcase url shows the line "too high" for me (no gap as in attachment 448277 [details]). But really, won't the exact behavior depend on the precise font metrics of the text in the floats? You're trying to line up the bottom edge of the <div id="boxtab-blue"> with the bottom edge of the floats, but the height of the floats depends on the font metrics (and in particular, depends on the exact way antialiasing is being done, etc), while you're setting the height of the <div> to some fixed number of pixels. It would make more sense to make that div height:auto and have a clearing kid after the <ul> or in the <ul> to make sure the height is enough to fit the floats. That sai,d a 3px font metric difference for a 16px font sounds like a lot, even given the known differences between how DirectWrite does antialiasing and how GDI/ClearType do. Leaving this open for Bas to look at for that.