Open Bug 1095937 Opened 10 years ago Updated 2 years ago

improve inline-sizing of orthogonal flows

Categories

(Core :: Layout: Block and Inline, defect)

defect

Tracking

()

People

(Reporter: jfkthame, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

When we reflow an orthogonal flow, we currently apply an mOrthogonalLimit from a parent reflow state that is based on the top-level viewport size. This leads to poor results when the orthogonal flow's parent is itself a smaller block, not the page as a whole. See attached testcase.
Attachment #8519464 - Flags: review?(smontagu)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Comment on attachment 8519464 [details] [diff] [review] Apply better inline-size limits to orthogonal flows. Cancelling r? for now, as this appears to have a bad effect on other examples I've been playing with. Needs further investigation.
Attachment #8519464 - Flags: review?(smontagu)
Attached file testcase (deleted) —

Hi jfkthame,
I'm not sure what you were trying to do here, but css-writing-modes has some fairly specific rules about orthogonal flow sizing in https://www.w3.org/TR/css-writing-modes-3/#orthogonal-flows

I've attached a testcase which shows some interesting ways in which the current mOrthogonalLimit system fails. In particular the code you're trying to modify in Initi() doesn't work if the frame that has an mOrthogonalLimit set doesn't happen to be orthogonal to an orthogonal flow (because we've nested orthogonal writing modes). You can see this case in the 'auto' example of the testcase, which ends up sizing as max-content instead of as the ICB height due to the nesting.

Assignee: jfkthame → fantasai.bugs

This patch brings us in line with css-writing-modes-3 wrt orthogonal limits.

(It doesn't handle resizing of the ICB correctly, but that's an existing problem. Fixing that requires invalidating layout of the orthogonal flow at appropriate times, which is a bit tricky since the frame relationship is quite indirect, which is probably why we don't do it right now. I can try to figure that out, but I'd prefer to land this first and handle that separately.)

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: fantasai.bugs → nobody
Status: ASSIGNED → NEW
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: