Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-grid] Stretching tracks fails to feed back into sizing algorithm #1150
Continuing from #1117 examples 3/4/7/8...
The row here being 50px is not very helpful. It should respond to the stretching of the track.
The responsible spec prose is in https://drafts.csswg.org/css-grid/#algo-overview where
referenced this issue
Mar 30, 2017
I'm not sure if this will be possible without introducing other issues. For example in the case of orthogonal flows.
Let's try to illustrate that with the following example:
<div style="display: grid; with: 500px; grid: 250px / auto auto; border: magenta solid thick; font: 100px/1 Ahem;"> <div style="background: cyan; writing-mode: vertical-lr;">XX X X</div> <div style="background: yellow; writing-mode: vertical-lr;">X</div> </div>
With the current spec
However, with the new proposal I believe this will end up in a worse result:
As you can see in the picture, in the last case we'll be overflowing the grid container because of
Last, I'm not sure if the use case is important enough to introduce changes on the track sizing algorithm at this stage. If you're using percentages on items against indefinite track sizes, I guess that having weird results in some cases can be somehow expected.
Fixed max track sizes in the row axis are assumed at the beginning of the first column sizing pass, so the second interpretation can't happen in any case. Note the second paragraph:
A case where we could get this result would be if the grid container itself had a fixed height.
A second comment is, if we're recalculating the column sizes, shouldn't the extra space from stretching be re-calculated? In which case we should still get the first result.
The CSS Working Group just discussed
The full IRC log of that discussion<dauwhe> Topic: Stretching tracks fails to feed back into sizing algorithm
<astearns> github: https://github.com//issues/1150
<dauwhe> fantasai: the issue here is that the stretch alignment property takes effect
<dauwhe> ... at the end of the algo
<dauwhe> ... you size the cols, then use size of cols to set height of rows
<dauwhe> ... at the end you do alignment
<dauwhe> ... that's generally fine
<dauwhe> ... cause alignment don't change track sizes
<dauwhe> ... but stretch does
<dauwhe> ... if you start with this example, you have image with intrinsic size, col sizes to intrinsic size, then try to size the rows
<dauwhe> ... and we use the size of the columns because there's an aspect ratio
<dauwhe> ... and now the item that's 100% wide fills the track in that axis, but then overflows the row
<dauwhe> ... the suggestion is that the stretching phase should be accounted for in the sizing algo
<dauwhe> TabAtkins: makes sense
<dauwhe> fantasai: we'll try to incorporate this into the algo, then will bring to group for review
<dauwhe> TabAtkins: is auto track and stretch distro the only thing that does this?
<dauwhe> fantasai: yes
<dauwhe> TabAtkins: then this makes total sense
<dauwhe> fantasai: the proposal is to handle the streching at each phase of stretch sizing
<dauwhe> astearns: would it make sense to have a note in align?
<dauwhe> fantasai: flex already has this
<fantasai> s/this/this kind of integration/
<dauwhe> Rossen: stretching and last baseline tend to have feedback back into the layout algo
<fantasai> astearns: Yeah, so should have a note pointing to the appropriate section of grid/flex
<dauwhe> RESOLVED: integrate stretching into track sizing algo
<dauwhe> fantasai: ONE MORE THING
Yep, you're right that I missed the part of the algorithm that explains that we'll be using the fixed max track size, so that case is not an issue.
Also if we go for the case where the row is
I've been doing some experiments and it seems that it works as expected and I didn't find any case that breaks due to this. Of course this need more testing but it seems a good approach.
Regarding the prose, it seems there are 2 verbs together in: