Summary: When vertical-align:baseline is used, a DIV with display:inline-block containing text behaves like it has a baseline, which is the baseline of one of its contained inline boxes. It should behave like the DIV's bottom is its baseline. To reproduce: open the testcase. Expected: The red shapes to be identical to the green shape. Actual: In the second case, the first lines of contained text are aligned with each other and with the bottom of the DIVs not containing text. In the third case, the last lines of contained text are aligned with each other and with the bottom of the DIVs not containing text.
Created attachment 4075 [details] testcase
This is a regression from the last released version.
See: http://www.w3.org/TR/CSS21/visudet.html Scroll to the very bottom of that document: "A UA should use the baseline of the last line box in the normal flow in the element as the baseline of an 'inline-block', or the element's bottom margin edge, if there is none." I made this change deliberately to be compliant with this part of the spec (despite the spec being pathetically ambiguous and not addressing what to do if the inline block has overflow or the line is outside its bounds, etc.).
Heh, I spent an hour staring at the part of the spec just above the last 2 paragraphs, wondering if this was a deliberate change or a regression, before opening this bug. I'm not sure why you didn't close it (perhaps because in the middle case it uses the first line rather than the last?).
I didn't close it because it's kind of an issue. For example, several Dashboard widgets have been broken by this change, despite being in strict mode. We're going to have to figure something out. Note this change was necessary for the new button controls, which are inline blocks that need to properly support baseline alignment.
Comment on attachment 4075 [details] testcase I'm marking this test case for review. The bug seems to be already fixed. This test case might still be useful however.
The bug is definitly not fixed for me...
Comment on attachment 4075 [details] testcase It's fine to land this test case, but marking it as review+ is going to misleadingly put this bug into the "needs commit" query.
The test case doesn't look the way it is describes itself in TOT. While landing a test that documents our inline block behavior seems good, we should probably have one that describes our current result as the correct one, if we think it is correct.
<rdar://problem/4404322>
Comment on attachment 4075 [details] testcase Given Maciej's comments, I'm setting the patch to review-. We can land a test for this if we revise it to no longer be misleading.
Adding Regression keyword.
We're keeping this new behavior.
Changing resolution from FIXED to more appropriate one.