1570039 - Multi-columns in orthogonal writing-mode overflow their container with column-span enabled

Status: ASSIGNED

(Core :: Layout: Columns, defect, P3)

Description

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

+++ This bug was initially created as a clone of Bug #1173689 +++

The patch will not help if column-span is enabled.

Also, both original test cases Testcase with column width and Testcase with column-count in bug 1173689 didn't seem to be added as reftests.

Comment 1

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

heycam, this bug involves columns with writing-mode. Would you like to take a look at this bug?

(I feel this doesn't need to block enabling column-span on nightly, so I block it shipping column-span instead)

Comment 2

[Cameron McCormack (:heycam)]

Thanks, I'll take a look at this one tomorrow!

Comment 3

[Cameron McCormack (:heycam)]

Attachment: test with column-width

Here's a smaller test case with column-width and the columnar element having an orthogonal flow. I'm not sure why Chrome has the results that it has, but I'm just going to assume that its multicol support in the presence of orthogonal flows isn't right.

With the columns-span pref off, the columns fill up eagerly, so if the browser window is wide enough, there's a single column, and as you narrow the window, more columns appear. With the pref on, there's always only a single column.

First step is to work out what the correct behavior is...

Comment 4

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Cameron, I'm re-evaluating which bugs worth blocking shipping column-span. I feel we should fix this. Are you still working on this? If not, I can take a look next week.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Perhaps it's worth seeing what effects the changes in bug 1095937 have here.

Comment 6

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Per David's comment, let's unblock this bug from shipping column-span.

Comment 7

[Cameron McCormack (:heycam)]

I'm going to punt this back to TY.

Comment 8

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: test with column-width (update).html

This testcase fixed the width property in .wrapper. (It was xwidth in comment 3's attachment.)

Comment 9

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Bug 1570039 - Use ColumnSetWrapper's reflow input to determine whether computed inline size adjustment is needed in orthogonal reflow.

After implementing column-span, ColumnSetWrapperFrame and the inner
ColumnSetFrame have the same writing mode. In order to making
ColumnSetFrame's computed inline-size being unconstrained when the
multicol container is in orthogonal reflow, we need to test whether
ColumnSetWrapperFrame is in orthogonal reflow or not.

Comment 10

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Even with the attached patch, the layout is so deeply wrong so I'm not sure it makes much sense to land it without fixing the underlying issues more thoroughly (as dbaron hinted above).

Why are we stretching the column-set's block-size (width)? It seems to me we shouldn't. (Chrome has the correct block-size I think.)

Why is the column-set's inline-size (height) the size of just one column? Given that the available inline size is unconstrained, we should use the "fallback size" per https://drafts.csswg.org/css-writing-modes-4/#orthogonal-auto which in this case is the ICB height. Then, per https://drafts.csswg.org/css-writing-modes-4/#auto-multicol, the column-set should use its shrink-wrap size within that available space (I think), so in this case its inline-size should be 3 columns * 100px + 2 gaps * 2px = 304px (assuming the ICB height is larger than that).

Comment 11

[Mats Palmgren (inactive)]

BTW, is the min[max]-content inline size of a multi-column box defined anywhere?
I can't seem to find it in:
https://drafts.csswg.org/css-multicol/
https://drafts.csswg.org/css-sizing/

Comment 12

[Mats Palmgren (inactive)]

Hmm, nsColumnSetFrame::GetPrefISize uses 1 column unless it's specified, so I guess the shrink-wrap size in the above case really should be 100px since that's our max-content inline size. So that answers the 2nd question.

Comment 13

[Mats Palmgren (inactive)]

Attachment: horizontal writing-mode intrinsic sizing

Chrome renders this test the same as Gecko, so I wonder how they get a different inline size in Testcase #2. I assume that's a just a bug in Chrome.