OK, so it looks like the problem here is that Chrome includes the entire grid in the scrollable overflow area (in the vertical dimension; not horizontal), whereas Firefox only considers the areas occupied by content. Simplified Testcase

I think we should fix that. I think authors would expect the entire grid to be included in the scrollable overflow area, content or no, and also in both dimensions. (Grid layout should be symmetrical.)

CC @MatsPalmgren @javifernandez @mrego @jensimmons @rachelandrew @tabatkins

A couple of extra notes for you, @charbelnicolas:

• I would recommend learning about the align-content and justify-content properties. When set to center on grid container, they will center the grid. See https://www.w3.org/TR/css-align-3/#align-justify-content You might also want to use padding and gap to create the 2rem spaces. I think this will be easier than having to create extra rows just to add such space. (I suspect there are good tutorials for grid and gaps and alignment properties online somewhere... I'm pretty sure e.g. Rachel Andrews has articles and videos on it. Or you can read the specs or MDN and just play with the property values to see what they do. https://developer.mozilla.org/en-US/docs/Web/CSS/gap https://developer.mozilla.org/en-US/docs/Web/CSS/align-content)

• The grid-template-area names, whether they are null or not null, don't affect how those cells are sized. They're just names. The only power they have in sizing the grid is to create an extra row or column if there wasn't one in specified by grid-template-rows/columns.

• Thanks for copying your message over. Codepen is a useful tool, but as a standards organization we need to make sure all relevant discussion is archived for future reference, so it's important that it be copied here.

I think we should fix that. I think authors would expect the entire grid to be included in the scrollable overflow area, content or no, and also in both dimensions.

I'm strongly opposed to such a change, fwiw. The grid is NOT a box and should not affect the overflow.
FYI, Chrome is agreeing that their layout is a bug and that Firefox is correct.

Thanks for the suggestions @fantasai, even though I'm a newbie, I am well aware of various ways to center content, I'm just really annoyed that this method doesn't work on all major browsers because of the current CSS spec apparently.

@MatsPalmgren Other than the grid not being a box, would this functionality hamper/impede you from doing CSS coding in your own way? Or would you say it allows more options for the developers/users? Not everyone thinks alike you know, and seeing how beautifully it works on Chrome, I'd say it would be a nice addition to the spec.

Options are always good, even more so when it's something that doesn't really stop you from doing things the way you are already used to. The spec can always evolve.

Anyways, that's my 2 cents. I hope this gets in.

I agree with @MatsPalmgren, from the implementation point of view is strange than an abstraction like the grid can contribute by itself to the grid container's overflow area. As a matter of fact, we have just fixed the bug while we don't agree on a good reason to define such change in the layout behavior.

Yeah, I'm with Mats too. The grid lines are a layout abstraction, not content; we don't rely on the grid itself for anything in layout besides helping us figure out which element to look at (for things like baselines, etc).

I don't know for how long this "bug" has been on chrome, maybe a year or more, who knows, but if it's been there for this long and it really didn't bother anyone, why not go the other way and add it to the spec.

Saying that you won't add it because the spec says a grid is only for layout abstraction and so and so.... Is self-defeating.

Make the grid more powerful, don't limit it just because "the grid is not a box".

And like I said, being able to use null cell tokens at the top but not at the bottom is counter-intuitive.

What's the worst thing that can happen if this gets added?

Please let whitespace be a first class citizen in css grid layouts.

I have sympathy for this use case - if you're using the grid for spacing content it's annoying that it's not symmetrical (top and left offsets add to the scrollable area, but right and bottom offsets do not). Adding empty divs to 'contentize' the abstract grid lines is really clunky.

When we get to the point of being able to style grid areas/gaps in CSS that may or may not have content in them, perhaps the areas with boxes from content OR boxes from styling should be considered in the scrollable area? This at least would be a CSS-only fix.

Saying that you won't add it because the spec says a grid is only for layout abstraction and so and so.... Is self-defeating.

Heh, I'm not arguing circularly; I wrote the original text, so I'm stating my original intentions for the spec. ^_^

And like I said, being able to use null cell tokens at the top but not at the bottom is counter-intuitive.

CSS is asymmetric with respect to left vs right and top vs bottom in many ways, all linked to the fact that the origin of the coordinate system is in the top-left corner (for English/etc). Auto-placement only runs downward and rightward, for instance; scrollable area only extends downward and rightward.

"Being able to use null cell tokens at the top" is just because the scrollable area always extends up to the zero point, but only extends downward to the last scrollable content. I understand that's not a particularly satisfying answer, tho. ^_^ But the use-case you've presented is already doable in other, better ways: use padding on the grid container, and then center the grid with align-content; this will center your grid without affecting your use of fr units elsewhere in the grid.

If there are other use-cases where empty right/bottom tracks should be included in the scrollable area, that aren't already possible with existing properties (and, hopefully, in a non-hacky way), then it's a good reason to consider changing.

When we get to the point of being able to style grid areas/gaps in CSS that may or may not have content in them, perhaps the areas with boxes from content OR boxes from styling should be considered in the scrollable area? This at least would be a CSS-only fix.

Boxes from pseudo-elements are boxes, so they'd definitely be counted there, yes. That's definitely not in question.

CSS is asymmetric with respect to left vs right and top vs bottom in many ways

Yes, and wrt scrollable overflow, this is really annoying to authors. You know that. We've been trying to fix it with the align properties in https://www.w3.org/TR/css-align-3/#overflow-scroll-position

I agree with @MatsPalmgren, from the implementation point of view is strange than an abstraction like the grid can contribute by itself to the grid container's overflow area.

Padding, gaps, and boxes are also abstractions. I don't think authors see grid lines as particularly more abstract than these things, even if implementations do.

I think empty tracks should be taken into account because those tracks are used when sizing the other tracks (percentages, fr units, etc...) so it would seem logical that they contribute space in the end.

The CSS Working Group just discussed Empty grid tracks should contribute to scrollable overflow.

@MatsPalmgren @javifernandez We just had a very short discussion on this topic in the CSSWG meeting, and will likely get to it again next week. One thing that came up is that the explicit grid tracks are included in sizing the grid container, so it would be reasonable (and consistent) to use that size in determining the scrollable area. We also heard emphatic support for doing this from the author perspective.

If I'm not missing anything, the spec defines quite clear in the 5.2. Sizing Grid Containers section how a grid container should be sized. The only reference to the tracks being used in the grid container sizing logic is the following one:

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).

The statement above determines how to compute the grid container's intrinsic size (lets assume for simplicity that we have such concept of intrinsic height), which as far as I know, it's the size we can compute without performing a layout.

I couldn't find any other reference about tracks being used to size the grid container. The example of paddings doesn't fit in this case because they contribute to the box's size but not to the box's content, like this new behavior seems to imply with the tracks.

Lets consider the following example:

<div style="display: grid; grid: 100px 100px / 200px 200px; overflow: auto; width: 300px, height: 100px; background: grey"></div>

Do we really want to show both vertical and horizontal scrollbars even there is no item inside the grid ? Even the horizontal bar ?

What if we add an item in the cell (1,1) ?

<div style="display: grid; grid: 100px 100px / 200px 200px; overflow: auto; width: 300px; height: 100px; background: grey">
   <div style="width: 50px; height: 50px; background: blue;"</div>
</div>

The scrolls would indicate that there are items in the grid areas out of the scrolling area, but that's not the case.

If we add an item i the cell (1,3) we really want to show the vertical scroll, since the item is bellow the scrolling area's height.

<div style="display: grid; grid: 100px 100px / 200px 200px; overflow: auto; width: 300px; height: 100px; background: grey">
   <div style="width: 50px; height: 50px; background: blue; grid-row: 3"</div>
</div>

However, we already would have both scroll bars visible because of the tracks. A similar example could be done in for the horizontal bar.

Yeah, the argument (as @astearns summarized) is that if the intrinsic size of the grid container is 200x400 as in your example, why wouldn't it show scrollbars if you explicitly sized it to smaller than that? This might be the only case in CSS where the scroll size is smaller than the intrinsic size.

I will just leave this here:

https://youtu.be/YfIjFeBLhyA

;)

This seems somewhat analogous to #129. You can use padding in start sides in order to add some space between the inner border edges and the start of the scrollable content, but you cannot do this for the end sides. Or at least that's what happens on Firefox, Chromium adds the space in the block-end side, and sometimes in the inline-end one.

I don't have a strong opinion about what should happen, but it would probably be better to be consistent and treat end padding and end empty grid tracks the same way in this regard.

@fantasai

Padding, gaps, and boxes are also abstractions.

All CSS concepts are abstractions, but that doesn't imply they are created equal. Margin-, padding-, border- and content-boxes are included in the CSS box model and the overflow falls out from that. Tracks, lines, gaps and other concepts are not included. So, if you want to include the extent of the grid in the scrollable overflow you are changing the CSS box model. That's fine of course, but it's not something that should be taken lightly. It could quite easily open up a can of worms both in specs and implementations. Before we do changes of this fundamental nature we should have a very strong motivating use case.

So, the use case at hand is that we want to distance the block-end border edge of the last grid item to the end of the container by at least 2rem. Fortunately, it turns out that CSS already has a feature for exactly this use case. (Concretely for the given testcase: remove the last track size and add #text { margin-block-end: 2rem; } - problem solved.). I can think of numerous other ways that would also solve this use case using existing CSS features only. Conclusion: the motivating use case is weak.

(FYI, I filed #3653 to sort out the exact definition of how child margins should contribute to the scrollable overflow. I intend to change Gecko so that is compatible with Chrome in Grid and Flexbox layout here, assuming the CSSWG agrees on that.)

@tabatkins

the intrinsic size of the grid container is 200x400 ...

The grid container has height: 100vh; width: 100vw so it is not intrinsically sized at all. You're saying that its hypothetical intrinsic size should contribute to overflow, to be precise.

The CSS Working Group just discussed Empty grid tracks should contribute to scrollable overflow, and agreed to the following:

• RESOLVED: Include space in empty explicit grid tracks in the scrollable overflow area

Thank you guys, I really appreciate it. I think this will make web design more straightforward.

One grid to rule them all.

Alright, fixed in the spec. Thanks for the report, @charbelnicolas ! That triggered some follow-up discussions/fixes for both Flexbox and Grid in #3665 and #3653 as well, fwiw.

Implementation bugs:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1532383
• https://bugs.chromium.org/p/chromium/issues/detail?id=1108097

Testcase: http://wpt.live/css/css-grid/grid-model/grid-overflow-padding-002.html