Test ---- http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/baseline-alignment-inline-block-ortho-flow.html Expected -------- The margin bottom edge (blue border) of the inline-block "sits" at/on the baseline Actual ------ The margin top edge (orange border) of the inline-block seems to be aligned with the x-height of parent block container. Explanations ------------ " The baseline of an 'inline-block' is the baseline of its last line box in the normal flow, unless it has either no in-flow line boxes or if its 'overflow' property has a computed value other than 'visible', in which case the baseline is the bottom margin edge. " CSS2.1, § 10.8.1 Leading and half-leading http://www.w3.org/TR/2011/REC-CSS2-20110607/visudet.html#leading Since the inline-block with 'writing-mode' set to 'vertical-lr' no longer has a meaningful last line box for practical purposes, then the "in which case ..." clause should apply. Notes ----- - I think component should be 'Layout: Block and Inline' but it could be 'Layout: Text' - I have not yet submitted such test to the test.csswg.org repository but I will, along with its correspondent reference file - Chrome 40.0.2214.115, IE11 and Prince 9.0.5 pass the test - I am using Firefox 38.0a1 buildID=20150219021531 - I use Linux 3.16.0-30-generic x86_64, Qt: 4.8.6, KDE 4.14.1; Kubuntu (utopic) 14.10 - I've searched for duplicates and did not find any

> - I have not yet submitted such test to the test.csswg.org repository but I > will, along with its correspondent reference file This test will be eventually recoded to use Ahem font before it gets submitted the test.csswg.org repository.

What are the expected results when the line and the frame are both vertical?

If they're both vertical-lr or both vertical-rl, we can treat baselines "as usual". But if one is vertical-lr and the other is vertical-rl, I don't think trying to align "baselines" makes much sense. I don't recall any specific discussion of this case in the spec, but it becomes clear that it's nonsense if the frame being placed itself contains multiple lines. So my suggestion is that such a case (which is likely to be vanishingly rare anyway) should just behave like the orthogonal case: the frame being placed in the line is treated as having its "baseline" at its block-end side according to the line's writing mode, so that it "sits on" the baseline of the overall line and "rises" from there in the direction of the line's ascent. (In practice, if anyone really did want to mix the two vertical-* modes like this, using vertical-align:middle would probably be the more sensible option, in which case none of this matters anyway.)

Comment on attachment 8571262 [details] [diff] [review] Don't try to use the ascent when placing a frame whose block-direction doesn't match the line's Review of attachment 8571262 [details] [diff] [review]: ----------------------------------------------------------------- OK, that makes sense, and in that case |if (pfd->mFrame->GetWritingMode().GetBlockDir() != lineWM.GetBlockDir())| is indeed the correct condition (which was the question underlying my question)

(In reply to Simon Montagu :smontagu from comment #5) > OK, that makes sense, and in that case |if > (pfd->mFrame->GetWritingMode().GetBlockDir() != lineWM.GetBlockDir())| is > indeed the correct condition (which was the question underlying my question) That's what I figured. :) I originally wrote the patch using IsOrthogonalTo, which worked fine for the original case with orthogonal modes, but then testing convinced me that it made more sense to treat the vertical-opposite-dir case this way as well.

> http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/baseline-alignment-inline-block-ortho-flow.html > Since the inline-block with 'writing-mode' set to 'vertical-lr' (...) Just for your information... The provided test is now more complete as it covers both vertical writing-modes and both sideways-right and upright text-orientations.