[css-grid] Intrinsic size computation with orthogonal grid items. #537

Closed
javifernandez opened this Issue Sep 27, 2016 · 2 comments

Projects

Needs Discussion in css-grid-1

4 participants

@javifernandez
Contributor

Given the following example:

<div style="display: grid; grid: 50px / auto; width: min-content; font: 25px/1 Ahem; border: 5px solid;">
   <div style="color: magenta; background: cyan;  writing-mode: vertical-lr;">XX X</div>
   <div style="color: red; background: blue; grid-column: 2;">XX X</div>
</div>

Loading this example in Chrome or Firefox we've got the following results:

Chrome
Current result in Chrome

Firefox
Current result in Firefox

Current draft of Grid Layout specification states the following regarding grid container's intrinsic size computation:

5.2. Sizing Grid Container

The min-content size of a grid container is the sum of the grid container’s track sizes (including gutters) in the appropriate axis, when the grid is sized under a min-content constraint.

In the example defined above, we need to use grid's container intrinsic size as the available space for steps 1 and 2 of the Grid Sizing Algorithm. After executing them, the orthogonal item has changed its min-content contribution, so as it' state in the specs we need to repeat steps 1 and 2 with such new min-content contribution.

Since we are in the middle of a layout, we shouldn't compute again grid's container size, so even though column tracks's size have changed after running step 3, they is not reflected in the grid's intrinsic size.

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).

Hence, I think we have an issue on how grid's intrinsic size is defined when there are orthogonal grid items; at least, if we really want to apply step 3 of the tracks sizing algorithm. I assume it's clear that we shouldn't make intrinsic size computation to depend on layout.

@dbaron dbaron added the css-grid-1 label Sep 28, 2016
@fantasai
Contributor

“I assume it's clear that we shouldn't make intrinsic size computation to depend on layout.”

Correct handling of writing modes actually depends on this. For example (super common case) vertical column headers in an otherwise horizontal table.

@tabatkins
Member

As fantasai said, intrinsic sizes can depend on layout in a few cases, of which this is one. In particular, the intrinsic width of the first item is the laid-out width, given a height of 50px (the row height), which is two lines-worth (2em, in the Ahem font). This "assumed" available height is specified in step 1 of the layout algo (it spans a single fixed-height row). The second item's intrinsic width is just the normal min-content size, which is the width of two Xs (2em, in the Ahem font).

Passing this thru the layout algorithm, we find then that the two columns get their base size set to these widths (so 2em each in Ahem), and their growth limits set to, respectively, two lines-worth (2em in Ahem) and 3 Xs + a space (4em in Ahem). However, there's no free space, so they stick at their base size, 2em each.

Step 2 of the layout algo is trivial - the row is 50px high.

Step 3 is a no-op - setting the row to 50px high didn't change the min-content contribution of any element, because we'd already assumed the row would be 50px high.

Step 4 isn't relevant for us.


So the grid container's width should be 4em, with the two elements next to each other.

  • Chrome makes the items overflow the grid container, because it assumes the min-content width of the first grid item is a single line-worth. (I presume it does layout into infinite available height, rather than what the spec mandates.) However, it then sets the actual width of the column correctly, so the grid overflows the grid container.

  • Firefox appears to make the same mistake, but it never resizes the first column, so the first grid item ends up overflowing its column and painting partially underneath the second item.

@fantasai fantasai closed this Dec 20, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment