1530097 - [css-grid] Implement the "Increase sizes to accommodate spanning items crossing flexible tracks" step

Status: NEW

(Core :: Layout: Grid, enhancement, P3)

Description

[Mats Palmgren (inactive)]

The Grid spec has been changed to include item intrinsic
sizes also in flexible tracks, by adding:
"Step 4. Increase sizes to accommodate spanning
items crossing flexible tracks":
https://drafts.csswg.org/css-grid/#algo-spanning-flex-items

Original commit:
https://github.com/w3c/csswg-drafts/commit/25e3f631310207ed83746530b4066b6278c3234f
for:
https://github.com/w3c/csswg-drafts/issues/2177

Comment 1

[Mats Palmgren (inactive)]

I filed a Chrome bug here: https://bugs.chromium.org/p/chromium/issues/detail?id=935102

Comment 2

[Oriol Brufau [:Oriol]]

Mats, do you plan to implement this? I did it in Chromium but we already got some issues from people who thought that the new behavior was a bug. It would be good if other browsers implement the change too.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

https://github.com/w3c/csswg-drafts/issues/4783 and https://bugs.chromium.org/p/chromium/issues/detail?id=1051039 indicate that this change was reverted in Chromium.

Comment 4

[Cameron McCormack (:heycam)]

There were resolutions in https://github.com/w3c/csswg-drafts/issues/4783 on how to deal with this (and a related) issue:

• RESOLVED: The auto minimum size is zero for grid items that span multiple tracks when at least one of those tracks is flexible.
• RESOLVED: When destributing the intrinsic contribution of a grid item, if it spans flexible tracks, excess size is distributed to those tracks and not to fixed/auto sized tracks.

Comment 7

[Daniel Holbert [:dholbert]]

Mats is no longer active; closing needinfo.

This bug (and bug 1708884 which I've just duped) seems to be gradually accruing webcompat.com reports of sites-that-are-broken-due-to-it. This might be a good bug for someone to get up-to-speed on grid layout internals.

Comment 8

[Daniel Holbert [:dholbert]]

(bumping webcompat priority to P2 to match bug 1708884 which I've now duped here)

Also, note that at least one WPT test already exists for this bug, here:
https://wpt.fyi/results/css/css-grid/layout-algorithm/flex-and-intrinsic-sizes-002.html

And that test was included under the compat2021 umbrella, per https://github.com/Ecosystem-Infra/wpt-results-analysis/blob/2532ef7dab0bc85fc007f7c978b22626e480d602/compat-2021/css-grid-tests.txt#L825 , so I'll mark this as blocking that metabug too.

Comment 10

[Frank Griffith Jr]

Included in Jira Epic FFXP-1761

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Cameron McCormack (:heycam) from comment #4)

There were resolutions in https://github.com/w3c/csswg-drafts/issues/4783 on how to deal with this (and a related) issue:

• RESOLVED: The auto minimum size is zero for grid items that span multiple tracks when at least one of those tracks is flexible.

FWIW, the spec text that corresponds to this is the third bullet point (and the following "Otherwise") here:
https://drafts.csswg.org/css-grid-1/#min-size-auto

(This part might be worth fixing as a "part 1" here; hopefully it's pretty straightforward, and it's the main webcompat-related part of this, I think.)

Comment 12

[Tiaan Louw]

Attachment: Bug 1530097 - Don't apply auto min sizing when spanning flexible tracks. r=#layout-reviewers

This is the first part of the bug. A clarification in the spec states
that a grid item spanning multiple tracks, which include a flexible
track, should not participate in auto min sizing calculation and should
have a width of 0.

https://w3c.github.io/csswg-drafts/css-grid-1/#min-size-auto

Comment 13

[Phabricator Automation]

Comment on attachment 9301312 [details]
Bug 1530097 - Don't apply auto min sizing when spanning flexible tracks. r=#layout-reviewers

Revision D160900 was moved to bug 1799111. Setting attachment 9301312 [details] to obsolete.

Comment 14

[Karl Dubost💡 :karlcow]

Daniel,
there was this discussion on https://bugs.chromium.org/p/chromium/issues/detail?id=1293302
with multiple cases with different renderings.

Tested on macOS 13

Safari Technology Preview 16.4 18615.1.11.2
Firefox Nightly 108.0a1 10822.11.5
Google Chrome Canary 109.0.5403.0 5403.0

https://jsbin.com/boviduruve/3/edit?html,css,output
Firefox, Safari Agree
Chrome Different

https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10933
Everyone disagree on the final rendering, but Chrome gives something which "looks nicer"

https://wpt.fyi/results/css/css-grid/layout-algorithm/flex-and-intrinsic-sizes-002.html?label=master&label=experimental&aligned
Safari, Chrome agree
Firefox different

And somehow the chromium bug points to here as the relevant bug for firefox.
Maybe missing WPT tests.

Comment 15

[Tiaan Louw]

Attachment: WIP: Bug 1530097 - Part1 - Create separate list of spanning data for items crossing flexible tracks r=#layout-reviewers

As a first step for implementing step 4 when resolving intrinsic track
sizes, we create another list for items crossing flexible tracks and
then apply the same steps as in step 3. This still doesn't grow
flexible tracks, but its a start.

https://drafts.csswg.org/css-grid-1/#algo-spanning-flex-items

Comment 16

[Tiaan Louw]

Attachment: WIP: Bug 1530097 - Part2 - Add step 4 for sizing intrinsic tracks r=#layout-reviewers

todo

Depends on D162608

Comment 17

[Daniel Holbert [:dholbert]]

[I still need to circle back to comment 14; leaving needinfo open]

Good news: I just went through all of the webcompat.com reports that are listed in the "see-also" list here, and I confirmed that they're all fixed, presumably due to the part that we spun off as bug 1799111. I left comments over on the webcompat.com github issues with notes. In one or two cases, the site had been fixed and the issue wasn't reproducible in any Firefox version; in the rest, Firefox 108 reproduces the issue but Nightly (currently v110, but really anything post-bug 1799111 probably) does not reproduce the issue.

Comment 18

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #17)

Good news: I just went through all of the webcompat.com reports that are listed in the "see-also" list here, and I confirmed that they're all fixed

Similarly: the bugs that were marked as duplicates are also fixed in Nightly, so I updated them to be dupes of bug 1799111 (which is almost certainly what fixed them).

Comment 19

[Daniel Holbert [:dholbert]]

I still need to circle back to see what implementation work might remain here. But given comment 17 and comment 18, I think we can transfer the WebCompat priority:P2 to (fixed!) bug 1799111. There's no associated webcompat issues that are still broken here at this point.