baseline alignment of inline-block in orthogonal flow

RESOLVED FIXED in Firefox 39

Status

()

RESOLVED FIXED
4 years ago
a year ago

People

(Reporter: bugzilla, Assigned: jfkthame)

Tracking

(Blocks: 1 bug, {testcase})

Trunk
mozilla39
testcase
Points:
---

Firefox Tracking Flags

(firefox39 fixed)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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
(Reporter)

Updated

4 years ago
Blocks: 1079125
Keywords: testcase
(Reporter)

Comment 1

4 years ago
> - 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.
(Assignee)

Comment 2

4 years ago
Created 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
Attachment #8571262 - Flags: review?(smontagu)
(Assignee)

Updated

4 years ago
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
What are the expected results when the line and the frame are both vertical?
(Assignee)

Comment 4

4 years ago
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)
Attachment #8571262 - Flags: review?(smontagu) → review+
(Assignee)

Comment 6

4 years ago
(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.
https://hg.mozilla.org/mozilla-central/rev/7ad48d9fb454
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
(Reporter)

Comment 9

4 years ago
> 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.

Updated

a year ago
Depends on: 1386541

Updated

a year ago
No longer depends on: 1386541
You need to log in before you can comment on or make changes to this bug.