1272783 - [css-grid] Wrong height for auto rows with text in several lines

Status: RESOLVED DUPLICATE of bug 1174569

(Core :: Layout, defect)

Description

[Manuel Rego Casasnovas]

Attachment: auto-row-height.html

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.36 Safari/537.36

Steps to reproduce:

Define a grid with 2 columns and 1 row.
The size of the columns is fixed and the item in the 2nd column
has a long text so it needs several lines.


Actual results:

The height of the row is the size of just 1 line.


Expected results:

The height of the row should be the the size of all the lines needed.

I'm attaching an example of a simple grid like the one described,
the columns are 200px and 100px.
The item in 1st column has just 1 line,
but the item in the 2nd column needs 5 lines.
The row has the size of just 1 line instead of 5.

BTW, if you use <br> the height of the row is increased.

Comment 1

[Manuel Rego Casasnovas]

Attachment: Current output

Comment 2

[Manuel Rego Casasnovas]

Attachment: Expected output

Comment 3

[Mats Palmgren (inactive)]

There is actually nothing in any CSS spec to support your view as far as I'm aware.

The CSS Grid spec is very clear that the containing block for a grid item is its
grid area:
https://drafts.csswg.org/css-grid/#grid-area-concept
"A grid item’s grid area forms the containing block into which it is laid out."

The *size* of that grid area is indefinite before the Track Sizing algorithm
has been completed.  Now, this is a dilemma, because the grid item's intrinsic
size should contribute *as input* to the Track Sizing in some cases, and in
the case of rows that means its block-size (assuming default writing modes).
Finding the item's intrinsic block-size requires flowing it though:
https://drafts.csswg.org/css-sizing-4/#block-intrinsic
"The min-content block-size contribution and max-content block-size contribution
of a block-level box is the block-size of the block after layout"

But flowing it ("after layout" as the spec puts it) requires having
a containing block with a definite inline-size at least, but this isn't
actually known *before* the Track Sizing algorithm is completed.

CSS Sizing says this about this case:
https://drafts.csswg.org/css-sizing-4/#terms
"indefinite size
   ... An indefinite available size is essentially infinite."

So, given an infinite available inline-size, the block-size is one line
high for the given example.

I'm curious, is Chrome determining the grid area inline-size after Track Sizing
has been run over the columns, and using that for measuring its block-size for
input to the row sizing?

How do you handle items with a vertical writing-mode that should contribute
its block-size to a column with an intrinsic sizing function?

Fwiw, I think the expected results you suggest is very reasonable though.
I'm just saying that I can't find anything in the Grid spec to support it.
On the contrary, the CSS Sizing spec seems to support our layout.

Comment 4

[Manuel Rego Casasnovas]

(In reply to Mats Palmgren (:mats) from comment #3)
> I'm curious, is Chrome determining the grid area inline-size after Track
> Sizing
> has been run over the columns, and using that for measuring its block-size
> for
> input to the row sizing?

Yeah, we do that.
I believe this is the text in the spec (https://drafts.csswg.org/css-grid/#algo-overview):
"2. Next, the track sizing algorithm resolves the sizes of the grid rows,
 using the grid column sizes calculated in the previous step."

If you have a 100px column, you should use that size
to determine the height of the "auto" row.

WDYT?

> How do you handle items with a vertical writing-mode that should contribute
> its block-size to a column with an intrinsic sizing function?

I believe that the solution for this is the next step on the spec:
"3. Then, if the min-content contribution of any grid items
 have changed based on the row sizes calculated in step 2,
 steps 1 and 2 are repeated with the new min-content contribution
 and max-content contribution (once only).

 This cycle is necessary for cases where the inline size of a grid item
 depends on the block size of its grid area.
 Examples include wrapped column flex containers (flex-flow: column wrap),
 orthogonal flows (writing-mode), and multi-column elements."

BTW, orthogonal flows are not supported yet in Blink,
the patch is almost there but hasn't landed:
https://codereview.chromium.org/815833005/

Comment 5

[Mats Palmgren (inactive)]

(In reply to Manuel Rego Casasnovas from comment #4)
> (https://drafts.csswg.org/css-grid/#algo-overview):
> "2. Next, the track sizing algorithm resolves the sizes of the grid rows,
>  using the grid column sizes calculated in the previous step."

Good point.  Yeah, we need to refactor the code a bit here and
also add a second pass in some cases as you suggest.

I think I'll dupe it to bug 1174569 which is already open on
implementing that part of the spec. I'll try to get to it
soon-ish since it's a fairly major layout bug.

Thanks for the report!