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

BTW, the very same argument would apply for column-gap in flexbox too, resolving percentage gaps there is always causing overflow:
```html
<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:
* https://github.com/w3c/csswg-drafts/issues/509
* https://github.com/w3c/csswg-drafts/issues/1921

Some interesting things happened on summer 2018:
* [Firefox implemented the new behavior for grid row gutters only (not for grid row tracks)](https://hg.mozilla.org/mozilla-central/rev/be1b4c042170)
* [Firefox added support for flex gutters implementing this for flex row gutters too](https://hg.mozilla.org/mozilla-central/rev/347512fd214e)
* [Chromium and WebKit implemented it for grid row gutters and grid row tracks](https://blogs.igalia.com/mrego/2018/08/10/changes-on-css-grid-layout-in-percentages-and-indefinite-height/)

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](https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/CJgcT4hR7Rk/_TBhjGLfAwAJ), 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.


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

Received on Tuesday, 19 May 2020 05:05:58 UTC