[css-sizing] Make flex % row-gap resolve to 0 when height is indefinite (only flex, not grid)

[davidsgrogan]

(The terminology here assumes horizontal writing mode)

% row-gaps in an indefinite-height container are specified to resolve against the container's intrinsic height. This currently applies to both flex and grid.

For grid, this can be used with % grid tracks to make a sensible layout. E.g.

height: 33% row track
height: 33% row-gap
height: 33% row track

This makes the gap and rows the same height and the grid container does not have overflow. There's a nice match here: % tracks and % gaps resolve off the same height.

The same is not true for flex. For example,

<div style="display: flex; flex-flow: column; height: auto; row-gap: 33%">
  <div class="flexitem" style="height:33%">some subtree</div>
  <div class="flexitem" style="height:33%">another subtree</div>
</div>

The items and gaps will not have the same size; there is no match like grid has. Items' % heights in an indefinite height flexbox resolve to 0. Further, the flex container will have overflow. In flex, using % row-gaps as specified now makes the flex container always have overflow.

This illuminates an inconsistency between flex and grid. Grid gaps resolve the same as the things they add space between: tracks. Flex gaps do not resolve the same as anything, they are their own beast.

Let's fix the inconsistency by prescribing that %gaps are resolved the same as their ~siblings: items for flex and tracks for grid. This would result in no changed grid behavior, because grid already does the right thing. There would also be no changed flex col-gap behavior. The only change is % flex row gaps would resolve to 0 when the flexbox has an indefinite height.

I don't know where this change would live. Maybe https://drafts.csswg.org/css-align/#column-row-gap. Maybe the first bullet point after the table in https://drafts.csswg.org/css-sizing-3/#min-percentage-contribution ?

/cc @chrishtr

[tabatkins]

Strong agree here. The original grid-gap behavior ended up resolving to satisfy the principles of (a) gaps acting like empty tracks as much as possible, and (b) row and column gaps acting identically. Since % tracks behave as auto during intrinsic sizing of the container, then resolve their %s against the container's size, gaps do the same thing.

We then applied a different consistency argument to transfer that behavior over to flex gaps, but that ends up meaning that we break the original consistency arguments! As you say, flex items with a % main size, when resolved against an indefinite flex container, do not resolve; they just behave as auto the whole time. So if we think of flex gaps as being empty items, a % gap should collapse to zero (aka the auto size for an empty item). And tho we can't compare cross-axis gaps with anything (because you can't explicitly size flex lines), we can apply the "consistent behavior in both axises" argument to say that % gaps in the cross axis will also resolve to 0 if the flex container's cross size is indefinite.

Agenda+ to discuss this at the next call.

[mrego]

BTW, the very same argument would apply for column-gap in flexbox too, resolving percentage gaps there is always causing overflow:

<div style="display: inline-flex; gap: 50%; border: solid thick;">
  <div style="background: magenta;">foo</div>
  <div style="background: cyan;">bar</div>
</div>

Anyway now going to the main point of my comment, IMHO we should change this for flex and grid at the same time. More specifically flex row gutters, grid row gutters and grid row tracks should resolve to auto when height is indefinite.

Usually percentages in the row axis behave like that and we added this different behavior for grid layout and flex in the past, and it seems it's not something really useful and it causes issues on the implementations as it's kind of tricky.

To give some historical background on the topic, we discussed about this in a bunch of places in the past but specifically these 2 issues:

• [css-grid] Percentages gaps and intrinsic size #509
• [css-grid] Percentage tracks and indefinite sizes #1921

Some interesting things happened on summer 2018:

• Firefox implemented the new behavior for grid row gutters only (not for grid row tracks)
• Firefox added support for flex gutters implementing this for flex row gutters too
• Chromium and WebKit implemented it for grid row gutters and grid row tracks

Since then there have been no changes in support regarding this, until very recently when Chromium added support fro flex gutters but without implementing this behavior (this hasn't been shipped yet).

This means that Edge never supported this for grid row gutters neither grid row tracks, until it started to use Chromium. And Firefox has never supported this for grid row tracks either.
Despite of that lack of interop I could only find 2 bugs on Chromium bugtracker about these topics:

• https://bugs.chromium.org/p/chromium/issues/detail?id=901447
• https://bugs.chromium.org/p/chromium/issues/detail?id=1020880

Also the bug for Firefox grid row tracks has 0 votes and no comments from authors asking about it: https://bugzilla.mozilla.org/show_bug.cgi?id=1481876

We also have a use counter for when percentage grid row tracks are used in a grid container with indefinite height in Chromium: https://chromestatus.com/metrics/feature/timeline/popularity/2248
It shows that a 0.03% of page loads hit this use counter, but I believe probably most of the cases would be grid-template-rows: 100% and a single row grid (which have the very same output resolving percentages or not doing it).

When we implemented the change related to percentage row tracks in grid layout we broke a few sites, but most of them were this single row 100% case that had no change in behavior. If we come back to the previous behavior the breakage would be way smaller, some sites might change a little bit, but we won't be causing overflow so not hard or problematic issues IMHO.
And we'll win in interop (I hope all browsers would be happy to come back to the old behavior, as it's going to simplify the implementations) and consistency, percentages for indefinite heights would be resolving the same everywhere (no exception for grid and flex).

I believe it's worth to reconsider all this, change it for everything flex/grid row gutters and grid row tracks and avoid the unnecessary pain on browsers implementations due to this without a clear benefit or web author's demand.

I'd love to hear opinions from @atanassov and @MatsPalmgren on the topic, as they were involved in the previous discussions.

[mrego]

About this example:

For grid, this can be used with % grid tracks to make a sensible layout. E.g.

height: 33% row track
height: 33% row-gap
height: 33% row track

This makes the gap and rows the same height and the grid container does not have overflow. There's a nice match here: % tracks and % gaps resolve off the same height.

This doesn't render very well for grid either, as first tracks are treated as auto height, that gets you the intrinsic height of the grid container, then you resolve 33%, so probably some track will end up being smaller than what it was originally and you'll get overflow in the items (not the grid container, but overflow anyway).

I'm attaching the output of the following examples:

<div style="display: grid; grid-template-rows: 33% 33%; gap: 33%; border: solid;">
  <div style="background: magenta;">foo</div>
  <div style="background: cyan;">bar</div>
</div>

<hr>

<div style="display: grid; grid-template-rows: 33% 33%; gap: 33%; border: solid;">
  <div style="background: magenta;">foo<br>bar</div>
  <div style="background: cyan;">baz</div>
</div>

<hr>

<div style="display: grid; grid-template-rows: 33% 33%; gap: 33%; border: solid;">
  <div style="background: magenta;">foo<br>bar<br>baz</div>
  <div style="background: cyan;">foobar</div>
</div>

Not a great result IMHO, and dunno when something like this could be really useful for anyone.

[davidsgrogan]

Rego, you make good points that I find very compelling, but they are orthogonal to this issue.

This issue is that we realized flex % gaps were matching the wrong behavior from grid. In grid, gap % resolve identically to the things they put space between. In flex, gap % resolve in a different way to the thing they put space between. Grid has that right. Flex has it wrong.

Your point is that grid gaps and tracks should change their current matching behavior to some other matching behavior. No matter how that shakes out, grid gaps and tracks behavior would still match each other, which is what we think flex should do too, so the point in this issue is unaffected.

[dholbert]

I'm fine with the proposed flexbox change here.

(The ~sibling consistency argument feels reasonable, and it feels unlikely that someone would intentionally write content that depends on the currently specced behavior, since it causes overflow pretty reliably/trivially.)

[css-meeting-bot]

The CSS Working Group just discussed [css-sizing] Make flex % row-gap resolve to 0 when height is indefinite (only flex, not grid), and agreed to the following:

• RESOLVED: % based gaps for flex in the cause of undefined constraint resolve to 0

The full IRC log of that discussion

<dael> Topic: [css-sizing] Make flex % row-gap resolve to 0 when height is indefinite (only flex, not grid)
<dael> github: https://github.com//issues/5081
<fremy> ack
<fremy> q?
<dael> TabAtkins: We had a number of complicated threads about how to deal with % gaps in grid. Had a good resolution. Gaps should act like tracks without content. Thus behavior of % in gaps is same as tracks. Resolve to content size for intrinsic and do % against it. Limited value for fixed size, but if everything is % it's nice
<dael> TabAtkins: We tried to apply different argument to move this to flex. Flex shoudl work same as grid and resolve % same way. Break simmetry argument we tried to apply. If a flex gap is empty % than % on flex item always behaves as auto. Never goes against initial size of container
<emilio> gregwhitworth: sure, that sounds good! I'm happy to poke at trying to add `<input type=file>` there and dig a bit. Thanks!
<Rossen_> q?
<dael> TabAtkins: More consistant is gaps act like empty items and make it so in a flexbox a % gap resolved against indefinant size becomes 0. Avoids annoying extra work and makes % consistently the same in flexbox.
<dael> TabAtkins: We don't know if we put this in flex or grid or centralize in alignment, but we'll figure that out when we get to it
<gregwhitworth> emilio: much appreciated, if you hit any snags it means I can add more to the docs
<dael> Rossen_: Agree we shoudl have consistent on resolve % against indefinte constraints. We do this is large # of places like intrinsic size with width undefined for all items in float, % goes to 0 initially. Then when we layout with defined contraint we'll resolve
<dael> Rossen_: With that rule said the rest of rules for block layout where for example has same behavior as shrink to fit but in block direction things that depend on height don't make sense.
<dael> Rossen_: That is not tue for when % computed based on resolved height. Items pos abs in box % resolve fine b/c constraint of containing block is defined. Want to make sure we're not introducing a new behavior for how % resolve during alayout regardless of layout types being considered
<dael> Rossen_: I symathize with issue but I think in this case we have to decide do we consider % gaps as resolvable during final layout pass of flex when all empty space if computed and all flexing is done? Is the height defined? b/c that's when gap % will be resolved and items positioned
<dael> TabAtkins: We decided that. % on flex items do not consider that to be resolved. THey stay as auto. Changing that in general is fine, but different for gaps vs flex items is concerning
<dael> Rossen_: I was going other wya, keeping same. If we have resolution for flex items that % in undefined are 0 same should be true for gaps
<dael> TabAtkins: Yeah. Resolve to be auto, but same deal. No content so become 0.
<dael> TabAtkins: If you're in agreement and no one else is disagreeing cool.
<dael> rego: I don't like that we're changing for flexbox only b/c will be different between flexbox and grid since same property works different. In grid % row gutters work nicely b/c you have overflow. I showed example in issue. In the end you have overflow items. I dont think it's useful and we'd have issues b/c not interop with tracks.
<dael> rego: We can do what's prop for flex but should do same for grid
<dael> TabAtkins: You want to revert grid so % gaps become 0 in grid and then we should be consistent so % tracks don't resolve to size
<dael> TabAtkins: I'm fine with that. It's consistent.
<dael> Rossen_: Not sure I'm on same page for grid. It will make grid row and column gaps behave asymmetric. If grid is in a block with defined width which is always the case (assuming left to right, top to bottom writing mode) the gaps of the columns resolve and gaps of rows go to 0
<dael> Rossen_: That will be bad, we've gone to lengths to keep rows and columns symetrical. Grid is 2d by its inception and we felt keeping the symetric true. Flex is 1d stack layout, even with multi-line. Applying a principle that's 1d in its conception to grid which is 2d doesn't always apply. In this case I don't believe it applies
<dael> Rossen_: WOuld rather go back and say % gaps don't make sense which is argument I made when we added gaps. THat solves all the issues. If people want defined gaps they can do it in px or fr in any layouts. % rarely makes sens ein gaps
<rachelandrew> q?
<dael> TabAtkins: I disagree. jensimmons has examples of people using % to build column with and than it makes sense to do % in gaps
<dael> Rossen_: No, I won't say remove % gaps. Pushing back on transfering ruls
<rachelandrew> q+
<dael> rego: So in grid we have different behavior for column and row gaps, that's true. BUt you'll have different behavior in flexbox too. Some people switching from grid to flex and reusing gap will get strange behavior. Also my point is we impl this 2 years ago and still don't have interop so we're not having issues here.
<dael> rego: I don't like flexbox and grid different, it's very confusing.
<dael> Rossen_: Agree. Agree that column for flexbox will resolve gaps and row will not is terrible.
<cbiesinger> q+
<Rossen_> ack rachelandrew
<TabAtkins> Agree with Rachel here.
<TabAtkins> Also: % gaps *only* do something reasonable if you're using % item/tracks as well; % gaps with non-% tracks automatically cause overflow, it's weird and bad.
<dael> rachelandrew: I don't nec think it's that confusing if flexbox and grid are different in this. Have difference in not being able to align items in main axis. Need to be clear about it. Grid the same in both dimensions is really important. Grid different rows and columsn is confusing. Once people get their head around how flexbox is different it's okay, wouldn't like to change grid
<Rossen_> ack cbiesinger
<dael> cbiesinger: Grid and flexbox already differ in some stuff. 1d vs 2d some things apply only main axis in flexbox and both in grid. THere's precedent for difference.
<dael> Rossen_: I think there's a general agreement around flex and how flex gaps should resolve. % based flex gaps.
<cbiesinger> s/some things/e.g. implied minimum size/
<TabAtkins> I'd still be fine with changing % beahvior for Grid here to match Flexbox and Block.
<rego> I guess Mozilla is fine doing the change for flexbox (as the spec behavior has been implemented in flexbox since 2 years ago)
<dael> Rossen_: If I'm reading the call correctly most people don't want to transfer to grid and keep grid symmetric. Happy to resolve for flex now, but if this comes bcak to grid we can discuss in the future. We shouldn't say keep the same on princlple. They're not the same.
<dael> Rossen_: rego mostly looking to you
<TabAtkins> Note that we can bring up the Grid-% change separately; if we make this decision for Flexbox it'll be consistent later to change Grid.
<dael> rego: If it's only me it's fine. I thought it was important to be consistent here. If it's only me I don't mind. I think will cause confusion. FF had behavior for a while so I don't think web compat, but I'd like to know that they're fine.
<dael> dholbert: I'm fine changing.
<dael> dholbert: One note on grid situation, with grid in block axis there is a special scenario with indefinite height but something reasonable to resolve % against. pixel value grid template rows create implicit value. There's cases like that where you get definite hiehgt w/o content and usefult o be symmetric for grid. I'm okay with prop resolution
<dael> Rossen_: Let's try to resolve
<dael> Rossen_: Prop: % based gaps for flex in the cause of undefined constraint resolve to 0
<dael> RESOLVED: % based gaps for flex in the cause of undefined constraint resolve to 0

[tabatkins]

s/cause of undefined constraint/case of resolving against an indefinite constraint/