We fail these tests (all identical): http://test.csswg.org/suites/css2.1/20101001/html4/white-space-mixed-001.htm http://test.csswg.org/suites/css2.1/20101001/xhtml1/white-space-mixed-001.xht http://www.hixie.ch/tests/adhoc/css/text/white-space/mixed/001.html I'm not sure if the tests are valid (also see bug 191699 comment 17, etc.). However, I'm pretty sure they demonstrate a bug in our code, for the following reasons: The reason we fail is that we're breaking in the middle of the 4th of the 7 lines in the test (with "PASS" on lines 3-7). If I make the following change to the test, we start passing: --- white-space-mixed-001.htm 2010-10-17 14:42:42.000000000 -0700 +++ white-space-mixed-001.htm 2010-10-17 14:42:45.000000000 -0700 @@ -30,7 +30,7 @@ xxxx </span> </span>x<span class="normal"> <span class="pre"> </span> <span class="pre"> </span> <span class="pre"> </span> <span class="nowrap"> </span> </span> <span class="pre"> </span><span class="normal"> </span> <span class="nowrap"> - </span><span class="normal"> </span> x x x x x x x + </span><span class="nowrap"> </span> x x x x x x x <span class="nowrap">x x x x x x x x x x xxxx xxxx xxxx xxxx </span> This forces that fourth line back together. However, if I *additionally* change the space that allows a break between lines 3 and 4 to a "z": -xxxx </span> </span>x<span class="normal"> <span class="pre"> </span> <span class="pre"> </span> <span class="pre"> </span> +xxxx </span>z</span>x<span class="normal"> <span class="pre"> </span> <span class="pre"> </span> <span class="pre"> </span> then I'd have expected that to put lines (3) and (4) (both previously wider than their container) together. However, it doesn't; instead we get a new (earlier) breakpoint. This demonstrates an inconsistency between the break points to which we backtrack and the break points that we use when we're over width (or going to be over width by placing the next frame). I *think* the test is asserting that the first set is correct and we have too many potential breakpoints in the second set. I'm not sure if that assertion is correct (though it is compatible with WebKit, since WebKit passes).