Re: [csswg-drafts] [css-sizing] Make flex % row-gap resolve to 0 when height is indefinite (only flex, not grid) (#5081)

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-sizing] Make flex % row-gap resolve to 0 when height is indefinite (only flex, not grid)<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5081<br>
&lt;fremy> ack<br>
&lt;fremy> q?<br>
&lt;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<br>
&lt;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<br>
&lt;emilio> gregwhitworth: sure, that sounds good! I'm happy to poke at trying to add `&lt;input type=file>` there and dig a bit. Thanks!<br>
&lt;Rossen_> q?<br>
&lt;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.<br>
&lt;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<br>
&lt;gregwhitworth> emilio: much appreciated, if you hit any snags it means I can add more to the docs<br>
&lt;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<br>
&lt;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.<br>
&lt;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<br>
&lt;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<br>
&lt;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<br>
&lt;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<br>
&lt;dael> TabAtkins: Yeah. Resolve to be auto, but same deal. No content so become 0.<br>
&lt;dael> TabAtkins: If you're in agreement and no one else is disagreeing cool.<br>
&lt;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.<br>
&lt;dael> rego: We can do what's prop for flex but should do same for grid<br>
&lt;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<br>
&lt;dael> TabAtkins: I'm fine with that. It's consistent.<br>
&lt;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<br>
&lt;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<br>
&lt;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<br>
&lt;rachelandrew> q?<br>
&lt;dael> TabAtkins: I disagree. jensimmons has examples of people using % to build column with and than it makes sense to do % in gaps<br>
&lt;dael> Rossen_: No, I won't say remove % gaps. Pushing back on transfering ruls<br>
&lt;rachelandrew> q+<br>
&lt;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.<br>
&lt;dael> rego: I don't like flexbox and grid different, it's very confusing.<br>
&lt;dael> Rossen_: Agree. Agree that column for flexbox will resolve gaps and row will not is terrible.<br>
&lt;cbiesinger> q+<br>
&lt;Rossen_> ack rachelandrew<br>
&lt;TabAtkins> Agree with Rachel here.<br>
&lt;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.<br>
&lt;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<br>
&lt;Rossen_> ack cbiesinger<br>
&lt;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.<br>
&lt;dael> Rossen_: I think there's a general agreement around flex and how flex gaps should resolve. % based flex gaps.<br>
&lt;cbiesinger> s/some things/e.g. implied minimum size/<br>
&lt;TabAtkins> I'd still be fine with changing % beahvior for Grid here to match Flexbox and Block.<br>
&lt;rego> I guess Mozilla is fine doing the change for flexbox (as the spec behavior has been implemented in flexbox since 2 years ago)<br>
&lt;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.<br>
&lt;dael> Rossen_: rego mostly looking to you<br>
&lt;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.<br>
&lt;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.<br>
&lt;dael> dholbert: I'm fine changing.<br>
&lt;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<br>
&lt;dael> Rossen_: Let's try to resolve<br>
&lt;dael> Rossen_: Prop: % based gaps for flex in the cause of undefined constraint resolve to 0<br>
&lt;dael> RESOLVED: % based gaps for flex in the cause of undefined constraint resolve to 0<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5081#issuecomment-631595507 using your GitHub account

Received on Wednesday, 20 May 2020 16:48:57 UTC