Re: [csswg-drafts] [css-grid] Resolution of percentage row tracks and gutters with indefinite height (#5566)

The CSS Working Group just discussed `Grid and % row tracks and gutter`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: Grid and % row tracks and gutter<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/5566<br>
&lt;chris> s/the announcement/the SOTD/<br>
&lt;TabAtkins> rego: We discussed on Monday, asked for feedback<br>
&lt;TabAtkins> rego: Rachel had some comments<br>
&lt;TabAtkins> rachelandrew: The reason I'm seeing %s in use is because people are putting a grid component in an older layout that uses %s, becuase that's how we did things with floats or even flexboxes<br>
&lt;TabAtkins> rachelandrew: And people generally only cared about columns, then<br>
&lt;TabAtkins> rachelandrew: I like staying with the symmetry, but I don't know whether authors really expect symmetry. Probably more important that Flex and Grid behave similarly, so I'd be generally okay with the change.<br>
&lt;Rossen_> q?<br>
&lt;TabAtkins> astearns: Can yo usummarize for a resolution?<br>
&lt;Rossen_> q+<br>
&lt;astearns> ack Rossen_<br>
&lt;TabAtkins> rego: resolve % of row tracks and gutters of grid with indefinite height to auto for tracks and 0 for gutters<br>
&lt;TabAtkins> Rossen_: Gonna be the shining voice on the hill<br>
&lt;TabAtkins> Rossen_: Symmetry was an important part of grid and made it what it was<br>
&lt;TabAtkins> Rossen_: We're trying to break that principle here. I object to this decision.<br>
&lt;TabAtkins> Rossen_: But before I do that I want to go back and understand what the current interop is<br>
&lt;TabAtkins> Rossen_: Because we don't have a 2d layout system that we can have precedent with<br>
&lt;TabAtkins> Rossen_: We can only have interop between the Grid impls themselves<br>
&lt;TabAtkins> Rossen_: So are we talking about interop with 1d layout systems like Block and Flex, or between the UA impls?<br>
&lt;TabAtkins> astearns: Is there a consensus across impls yet?<br>
&lt;TabAtkins> rego: There are no track interop, there's interop on gutters. Firefox would have to change track, but Mats says he wants to change.<br>
&lt;TabAtkins> rego: With regards to Rossen's other issues, I don't know about that.<br>
&lt;TabAtkins> astearns: Rossen, do you have a plan to bring people around to your objection?<br>
&lt;TabAtkins> Rossen_: Not as part of this call.<br>
&lt;TabAtkins> Rossen_: Issue is, what's the pressing issue? Why do we need to resolve now? Take it another way - we've discussed this in the apst many times, another fix is to get rid of % in gutters.<br>
&lt;TabAtkins> fantasai: Far too late for that<br>
&lt;TabAtkins> Rossen_: But not too late to break grid, apparently?<br>
&lt;TabAtkins> fantasai: %s in gutters works just fine between columns, and people are using<br>
&lt;TabAtkins> fantasai: This is just about between rows<br>
&lt;TabAtkins> (and in an indef height)<br>
&lt;TabAtkins> fantasai: So what we need is interop between browsers. And right now we have interop on the behavior you want for gap between rows.<br>
&lt;TabAtkins> fantasai: But we don't have interop for sizing tracks<br>
&lt;TabAtkins> fantasai: Chrome/webkit have one behavior, the one you wanted iiuc, Firefox has another behavior<br>
&lt;TabAtkins> fantasai: This is causing problems bc we have impls behaving differently, so rego wants to fix that.<br>
&lt;TabAtkins> fantasai: So either Firefox has to change their behavior for tracks, or Chrome/WebKit has to; one of those has to happen, then we have interop<br>
&lt;TabAtkins> fantasai: And if Chrome/WebKit changes behavior, we should make gaps behave the same way as well, which is further change<br>
&lt;TabAtkins> fantasai: We could theoretically go either way, but we need at least one group of people to switch their behavior.<br>
&lt;TabAtkins> florian: One step I didn't follow - if Chrome/WebKit align with Firefox, that would mean % on gaps and tracks dont' work the same?<br>
&lt;TabAtkins> fantasai: Yeah, which is why the issue says if we do that we shoudl also switch the gap behavior, even tho we currently have gap interop.<br>
&lt;TabAtkins> fantasai: I think that % gaps between rows are rarely used so their behavior isn't a big issue, it's mainly just a cleanup step to keep them consistent.<br>
&lt;TabAtkins> fantasai: It's really about which behavior we end up with for row sizing<br>
&lt;TabAtkins> Rossen_: So if current impls impl % row-gaps behavior the same, it's essentially the same behavior that they need for row tracks?<br>
&lt;TabAtkins> Rossen_: I'm curious about the new Chrome Grid rewrite, which behavior is currently there<br>
&lt;TabAtkins> Rossen_: It seems like it's the symmetric one, right?<br>
&lt;TabAtkins> rego: I dunno if the new grid impl has this behavior done yet<br>
&lt;TabAtkins> [iank_: yo]<br>
&lt;TabAtkins> Rossen_: What I see currently is that Chrome/Firefox/WebKit have same beahvior<br>
&lt;TabAtkins> rego: For gutters, yes. For tracks Firefox has the different behavior<br>
&lt;iank_> ops sorry - no currently implemented yet afiak.<br>
&lt;iank_> not*<br>
&lt;TabAtkins> rego: Firefox resolves % rows to auto, and that's not following the spec, it's alone in that behavior<br>
&lt;TabAtkins> rego: So if we keep the spec as is, only Firefox has to change.<br>
&lt;TabAtkins> rego: This proposal would take Firefox's behavior, so the other browsers would change.<br>
&lt;TabAtkins> rego: When I did back-compat analysis, there were three pages that did better in Firefox and only 1 that did worse<br>
&lt;TabAtkins> rego: But Chrome/WebKit aren't getting bugs reported on this, despite the lack of interop<br>
&lt;TabAtkins> astearns: So sounds like we won't have agreement here<br>
&lt;TabAtkins> rego: Should ask the layoutng people about things<br>
&lt;TabAtkins> rego: And Mats<br>
&lt;TabAtkins> astearns: yeah he said yes one way, should see if he's okay with the other way<br>
&lt;TabAtkins> astearns: So we'll table this for now<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 23 October 2020 14:31:24 UTC