[css-grid][css-contain] Clarify that `contain:size` affects track sizing

[MatsPalmgren]

Consider the following case:

<div style="display:inline-grid; contain:size;">
  <item style="background:red">Hello Kitty</item>
</div>

My understanding of the CSS Containment spec is that the intent of contain:size is that all size calculations should be done as if the element has no children:
https://drafts.csswg.org/css-contain/#containment-size
Chromium and Gecko agrees that the content-box size in the above case is 0x0, which is correct. I tend to think that the track sizes also should be zero and thus that it should render the same as:

<div style="display:inline-grid; grid:0/0;">
  <item style="background:red">Hello Kitty</item>
</div>

Neither Chromium nor Gecko does that currently, but I intend to fix this in Gecko (bug 1488878).

I can't find any spec text dealing with this case explicitly though, so I would like CSS Grid to clarify that when the Grid container has contain:size the Track Sizing Algorithm should be run as if the container has no items. This will have the effect that any intrinsic track sizes will be zero.

[MatsPalmgren]

(I've filed a Chromium bug.)

[bfgeek]

I don't believe that is the intent of the containment specification. From the spec:

When calculating the size of the containing box, including when computing its intrinsic size, it must be treated as having no contents.

This is effectively just an early out when computing the intrinsic sizes for an element.

Then, its contents must then be laid out into the containing box's resolved size.

Any layout algorithm should not then change its behaviour after the above step. E.g. these two cases should render the same:

<div style="display:inline-grid; contain:size;">
  <item style="background:red">Hello Kitty</item>
</div>

<div style="display:inline-grid; width: 0px;">
  <item style="background:red">Hello Kitty</item>
</div>

[Loirooriol]

Chromium and Firefox are not interoperable in these cases:

<div style="display: inline-grid; grid-auto-columns: 50px; height: 50px; contain: size; border: 5px solid">
  <div style="background: yellow"></div>
</div>

<div style="display: inline-grid; grid-template-columns: 50px; height: 50px; contain: size; border: 5px solid"></div>

In Chromium, the content area of the grid container is 50px wide, in Firefox it's 0px.

@MatsPalmgren, in https://bugzilla.mozilla.org/show_bug.cgi?id=1488878#c1 you say that what you want to implement is

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

This seems what Chromium is doing, i.e. step 1 can create implicit tracks, tracks may end up being bigger than 0px in step 2, and this affects the size of the grid container in step 3.

However, according to the CSS Grid spec, once we know the size of the grid container, it's laid out again "for real". So there are more steps:

4. place items into the grid as usual
5. run Track Sizing algo, this time taking the items into account

Then I'm not sure why you think that the tracks should be 0px in your example. Do you want to avoid laying the grid again if there is size containment?

[MatsPalmgren]

When calculating the size of the containing box, including when computing its intrinsic size, it must be treated as having no contents.

This is effectively just an early out when computing the intrinsic sizes for an element.

The "including when computing its intrinsic size" (my emphasis) seems to imply that it affects more size calculations than just the intrinsic size of the box itself. I don't see anything in the spec that supports the idea that it only affects the intrinsic box size.
You can think of the calculation of intrinsic track sizes as an "intrinsic sizing calculation" if that helps since it's based on the intrinsic sizes of the items (the chapter is even named Resolve Intrinsic Track Sizes).

<div style="display:inline-grid; width: 0px;">

Did you forget the height:0? The contain:size spec is pretty clear that the children shouldn't affect the size: "This ensures that the containing box can be laid out without needing to examine its descendants." so clearly you don't want the container to have its height sized by the item.

Anyway, the Containment spec already says that "this does not necessarily make the element zero-sized: properties set on the element itself, such as the columns property or the grid property, continue to be taken into account.". I read "taken into account" there as "run the TSA pretending that the grid container has no items", which is what I suggested in the OP. I don't think there is a way to take the grid properties into account in any other way.
IOW, what I'm suggesting is merely making concrete what the spec is already suggesting as I see it.

[frivoal]

My understanding is the same as @bfgeek and @Loirooriol here. The "inculding intrinsic size" bit means that if the layout of any parent of the size-contained element depends in some way on the intrinsic size of that size-contained element, then that input to its layout is the same as if that size-contained element was empty.

For instance, the size of a grid row depends on the intrinsic sizes of the elements in that row. Say you have a column which is sized to min-content, we look at the intrinsic min content size of the elements in the column, pick the largest, size the column that way, and then do the actual layout of the grid items in that column at that width. During that phase, if any of the grid items have size containment, they'll be treated as empty for the purpose of figuring out their min-content size.

However, setting size-containment on the grid itself would not affect the intrinsic size calculation of the grid items.

The "including when computing its intrinsic size" (my emphasis) seems to imply that it affects more size calculations than just the intrinsic size of the box itself.

No, it means that it's both the size of the box in actual layout, and the intrinsic size of the box if requested by its parent, that are calculated as if the box were empty. Not that other unspecified operations (such as track sizing) also treat it as empty. The spec tries to be explicit that once you've done this sizing step, everything else runs normally, with the following statement:

Then, its contents must then be laid out into the containing box's resolved size.

---

Anyway, the Containment spec already says that "this does not necessarily make the element zero-sized: properties set on the element itself, such as the columns property or the grid property, continue to be taken into account.". I read "taken into account" there as "run the TSA pretending that the grid container has no items", which is what I suggested in the OP. I don't think there is a way to take the grid properties into account in any other way.

For the purpose of finding how big the grid is, yes. Hence the grid in your example being sized to width:0; height:0; But then we do actual layout of the grid, and at that point everything behaves as usual, and so it's track aren't empty.

At least:

• that's what I meant when I phrased the spec that way
• doing what you suggest instead doesn't seem necessary to allow the kind of optimizations that size-containment is trying to enable. (to be fair, I don't think it would disable them either.)

That said, if it is not clear (which seems to be the case), the spec should certainly at least be clarified. If we have agreement that the behavior suggested here would be more useful, I suspect we could switch to that, but it's not clear to me that it is.

---

Chromium and Firefox are not interoperable in these cases:

<div style="display: inline-grid; grid-auto-columns: 50px; height: 50px; contain: size; border: > 5px solid">
  <div style="background: yellow"></div>
</div>

In Chromium, the content area of the grid container is 50px wide, in Firefox it's 0px.

Yeah, in that case, Chromium is right and Firefox is wrong. That is exactly what the note in the spec is about:

Even when the element’s sizing properties are auto this does not necessarily make the element zero-sized: properties set on the element itself, such as the columns property or the grid property, continue to be taken into account.

[frivoal]

Chromium and Firefox are not interoperable in these cases […]

WPT has (at least) two tests for that, which Firefox fails:
https://wpt.fyi/results/css/css-contain/contain-size-grid-002.html
https://wpt.fyi/results/css/css-contain/contain-size-grid-003.html

Interestingly, Firefox does pass the corresponding multicol tests:
https://wpt.fyi/results/css/css-contain/contain-size-multicol-001.html
https://wpt.fyi/results/css/css-contain/contain-size-multicol-as-flex-item.html

[MatsPalmgren]

The "including when computing its intrinsic size" (my emphasis) seems to imply that it affects more size calculations than just the intrinsic size of the box itself.

No, it means that it's both the size of the box in actual layout, and the intrinsic size of the box if requested by its parent, that are calculated as if the box were empty. Not that other unspecified operations (such as track sizing) also treat it as empty.

This is a fundamental misunderstanding of how Grid layout works. Track sizing isn't "other unspecified operations" unrelated to a grid container's size. It's literally the way you calculate its content-box size, per spec: "The max-content size (min-content size) of a grid container is the sum of the grid container’s track sizes (including gutters) in the appropriate axis, when the grid is sized under a max-content constraint (min-content constraint)." So suggesting that size-containment doesn't affect track sizing makes no sense because if it doesn't then it can't affect the grid container's size either.

To be concrete, here's how Gecko reports "the intrinsic size of the box if requested by its parent". I've highlighted the three salient steps there:

1. place items into the grid
2. run the Track Sizing Algorithm (TSA) in the relevant axis
3. return the sum of the track sizes + gaps

The spec tries to be explicit that once you've done this sizing step, everything else runs normally, with the following statement:

Then, its contents must then be laid out into the containing box's resolved size.

OK, so it seems what you're trying to say then is that contain:size only has an effect when the grid container is sized under a min-/max-content constraint, and has no effect otherwise?

[...] I read "taken into account" there as "run the TSA pretending that the grid container has no items", which is what I suggested in the OP. I don't think there is a way to take the grid properties into account in any other way.

For the purpose of finding how big the grid is, yes. Hence the grid in your example being sized to width:0; height:0; But then we do actual layout of the grid, and at that point everything behaves as usual, and so it's track aren't empty.

I'm guessing "how big the grid is" means "what the content-box size of the grid container is". (please try to use precise terms that are defined in specs or we're going to talk past each other).

doing what you suggest instead doesn't seem necessary to allow the kind of optimizations that size-containment is trying to enable.

Doing what you suggest means that we have to run the TSA twice: once without items to determine the grid container's content-box size and once with items to determine the track sizes to use for layout of the children. Always running the TSA without items, as I suggested in the OP, is an optimization (and a lot simpler to implement since running it once is what we're currently doing).

Yeah, in that case, Chromium is right and Firefox is wrong. That is exactly what the note in the spec is about:

Even when the element’s sizing properties are auto this does not necessarily make the element zero-sized: properties set on the element itself, such as the columns property or the grid property, continue to be taken into account.

Right, but the way you "take the grid property into account" is to run the TSA. So again, there is no other way to implement this but to run the TSA without items (at least under a min-/max-content constraint) and use the track sizes that falls out. If you're thinking of something else then please point to spec text that defines that alternative algorithm.

I can live with doing it twice I guess, if you all think it's important that intrinsic track sizes should be sized normally before laying out the children.

[Loirooriol]

@MatsPalmgren Can you clarify what's your proposal if you don't want to run the TSA without items when sizing the grid container under a min/max-content constraint, and then run the TSA with items when laying it out for real?

In your first comment you say that the track size should be 0, seemingly implying that you only want to run the TSA without items, never with items.

In your last comment you seem to mean that you want to ignore grid (so that you can avoid running the TSA) when sizing the grid container under a min/max-content constraint. And then run the TSA once with items when laying out for real.

So not sure I understand your proposal.

[MatsPalmgren]

In your first comment you say that the track size should be 0, seemingly implying that you only want to run the TSA without items, never with items.

Right, that's option A.

In your last comment you seem to mean that you want to ignore grid (so that you can avoid running the TSA) when sizing the grid container under a min/max-content constraint. And then run the TSA once with items when laying out for real.

No, I never said grid should be ignored. On the contrary, running the TSA is how you take grid into account. You can run it without items though. Then definite track sizes are still sized normally, but intrinsic track sizes will be zero. So option B (that I described in my last comment) is to run the TSA once without items for calculating the intrinsic content-box size of the grid container, and then a second time with items when "laying it out for real" (so that the final track sizes are sized normally as if contain:size weren't specified). The grid container's intrinsic size would still be taken from the first step though (the first step isn't needed if it has a definite size obviously). So for example:

<div style="display:inline-grid; contain:size; grid:auto 100px / auto 200px">
  <item><div style="width:300px; height:300px"></div></item>
</div>

with option A:
the grid container content-box size is 200px x 100px
the resolved track sizes are 0px 100px / 0px 200px
the item's content-box size is 0px x 0px
with option B:
the grid container content-box size is 200px x 100px
the resolved track sizes are 300px 100px / 300px 200px
the item's content-box size is 300px x 300px

So not sure I understand your proposal.

I've described two different options (so far). I hope they are clear now.

BTW, I'm assuming above that the grid item placement step in the Grid layout algorithm always occurs, also for contain:size. But this isn't at all clear from the CSS Containment spec. In fact, a strict reading of the spec implies that it shouldn't occur: "When calculating the size of the containing box, including when computing its intrinsic size, it must be treated as having no contents."

The "treated as having no contents" implies that implicit tracks should not be created (since there are no items if we treat it as having no contents), for example:

<div style="display:inline-grid; contain:size; grid-auto-rows:100px; grid-auto-columns:100px">
  <item></item>
</div>

Chrome makes the grid container content-box size 100px x 100px, i.e. clearly not treating it as empty when computing its intrinsic size, which contradicts what the spec text currently says.

So the spec needs to say explicitly which parts of Grid layout are supposed to be run with/without items, unless it means all of them.

I don't have a strong opinion on which option to choose. Option B seems to be close to what Chrome is currently doing and that seems to be the behavior you guys prefer, so that's fine with me. It needs to be clearly specified how it's actually supposed to work though, because the current spec text suggests something completely different.

[MatsPalmgren]

Also, the part about honoring grid etc is mentioned in a Note in the spec. The Conformance section says that notes aren't normative if I read it correctly: "All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes."

I assume honoring grid is supposed to be a normative requirement and thus it shouldn't (only) be mentioned in a note.