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.

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.

(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/

(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!