1488878 - Make CSS grid with "contain:size" take grid-template-rows/grid-template-columns into consideration for sizing (but not children)

Status: NEW

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

Description

[Daniel Holbert [:dholbert]]

I'm spinning off this bug to cover bug 1470462 comment 2 "phase 2".

The idea is:
 - bug 1470462 covers making a contain:size CSS Grid only honor the "width" & "height" properties (and ignore children & grid properties) when sizing/baseline-aligning itself. This happens to be what Chrome does right now.

 - This followup bug covers implementing something more subtle so that we honor non-child-dependent sizes in grid-template-rows & grid-template-columns when computing the grid's size.

 - Ultimately (once this bug here is fixed), a size-contained grid's frame-size & baseline alignment should simply be determined as if it had no children -- and then the children should be laid out as normal, as if the grid simply had "width: [whatever-width-it-ends-up-with]; height: [whatever-height-it-ends-up-with]"

(Incidentally, this might mean that we could treat the grid size as "definite" in some scenarios where we might otherwise not do so, because by definition it won't be influenced by its children's sizes.)

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase #1

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

• Ultimately (once this bug here is fixed), a size-contained grid's
  frame-size & baseline alignment should simply be determined as if it had no
  children -- and then the children should be laid out as normal

The problem with that is that the mere act of placing items
into the grid affects which tracks exist, which in turn
affects the grid container's size.

I guess we could run a separate track sizing step, without
placing any items first, just to determine the container's
size but I'm not sure if that's actually beneficial to authors.

That is, the two alternatives I can think of are:

1. place items into the grid as usual
2. run Track Sizing algo but pretend we have no items
3. calculate the container's size from the track sizes as usual

or:

1. without placing any items first, run Track Sizing algo
   and pretend we have no items
2. calculate a size from those tracks
3. place items into the grid as usual
4. run Track Sizing algo but pretend we have no items
5. use the size from step 2 as the container's size

The first alternative would be slightly more efficient,
and also easier to implement. The second alternative likely
leads to overflow when the placement creates tracks as in
this example.

I'm leaning towards the first alternative. I'll start with
implementing that, given that it's a subset of the second and
thus needs to be done anyway.

Comment 2

[Mats Palmgren (inactive)]

I've implemented the first alternative: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d8eee8c41b3f9fc6e029298789220414301a7460

I don't think the second alternative (in comment 1) makes much sense. I filed a spec issue to make CSS Grid explicitly point out that intrinsic track sizing is affected by contain:size too.

Comment 3

[Oriol Brufau [:Oriol]]

I think that this should only happen with contain-intrinsic-size: none (the default value).
Other values should probably ignore grid-template and gaps.
So basically the bug is that contain-intrinsic-size: none behaves as contain-intrinsic-size: 0px.
But to be clarified in https://github.com/w3c/csswg-drafts/issues/7520

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: mats' patch from comment 2

(In reply to Mats Palmgren (inactive) from comment #2)

I've implemented the first alternative: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d8eee8c41b3f9fc6e029298789220414301a7460

Here's that patch, for archival purposes.

Comment 6

[Daniel Holbert [:dholbert]]

FWIW, this bug is the reason that we fail this WPT test:
https://wpt.fyi/results/css/css-contain/contain-size-grid-002.html
http://wpt.live/css/css-contain/contain-size-grid-002.html

Comment 7

[Daniel Holbert [:dholbert]]

...and I think it's also the reason for our failures in these tests:
https://wpt.fyi/results/css/css-contain/contain-size-grid-003.html
https://wpt.fyi/results/css/css-contain/contain-size-grid-004.html
https://wpt.fyi/results/css/css-contain/contain-size-grid-006.html

Comment 8

[Florian Rivoal]

I think that any variant of an approach where you compute the number of tracks taking into account how many children you do have will run into problems, because how many children you have is something you can vary, maybe adding some using ::before or ::after, removing some using display: none, or turning one into several using display: contents on a child that has multiple children.

If doing such things changes the size of the sized-as-if-empty grid, that breaks the promises of size containment, and the whole thing is at risk of logical inconsistencies.

It is true that this makes grid less powerful and less useful, but I think that's unavoidable: containment trades away some of the normal layout capabilities in exchange for stability guarantees, and this seems like a case where you cannot get both.

Which means, that you have to size the grid based on the number of tracks it would have if it had no children, with those tracks sized as if the grid had no children. Then you lock the size of the grid container, and redo the track building / track sizing / full grid layout. And yes, that may lead to overflow.

I believe that's what the spec already calls for. Do you see any ambiguity in the spec that allows for alternatives?

Comment 9

[Daniel Holbert [:dholbert]]

I agree. I think that calls for the second alternative from comment 1 here.