Potential Grid Improvements

Table of Contents

As part of my work on Container Queries, I’ve been taking a broad look at the state of “responsive components” – especially in relation to grid & flex layouts. Are there ways we can improve the tools we have, to help address the goal of “container queries” inside the layout tools themselves?

Auto-fit and auto-fill grids can be particularly helpful for adjusting grid layouts to fit available space – but they come with several limitations.

This is a collection of potential improvements, linked to Github issues where appropriate.

Auto-flow issues

Even when auto-flow is sparse, most elements backfill. The logic here is very unclear to authors. See a demo on codepen. It would be useful to control that with some more clarity.

Responsive track spanning

Some of the most common grid issues stem from the difficulty of placing items in relation to implicit or auto-fit/auto-fill grids. There are several useful ideas here:

We often want to span multiple columns/rows only when they are available in the explicit, auto-generated grid. That would require the ability to clamp track spanning (#5852) with a syntax like the proposed span-minmax(1, 3).

When mixing explicit & implicit grids, it would be useful to align with (span from or too) the first or last line – which could be explicit (1/-1), but might also be implicit. That is discussed some in span to last track… (#2402).

That problem gets even larger when you consider aligning the -end value, while maintaining auto-placement for the -start value. All of these issues are addressed together, with an initial prototype, by indefinite spans (#388).

Styling grid abstractions

There have been many requests to style the individual grid cells/tracks/areas, as well as the gaps between them.

Grid/flex/multi-column gap-rules

Fantasai opened a large thread to discuss the styling gaps/gutters (#2748) – using or building on column-rule. This approach would ideally be generic, applying to grid, flexbox, and multi-column layouts. (This was discussed by the Working Group in May 2020, with a request for more “white-boarding” of options)

Grid cells, tracks, and areas

There are multiple issues related to styling cells, tracks, and areas. This can take various forms, and overlap with a number of other issues. One idea is to select grid-items based on their auto-placement (track or cell) – see target items in nth-row of implicit grid (#1943) – but that might cause recursion issues.

More directions are explored in the issue thread for decorative grid-cell pseudo-elements (#499).

Jen Simmons has proposed an @region rule, with named areas that feel over-complicated for this narrow use-case, but she expands on it to solve other issues, more aligned with “regions” generally.

@@@ link to other region-like issues

For the simpler use-case of decorative styling on cells/tracks/areas, I like Tab Atkins proposal of a ::grid-area() pseudo-element:

#grid::grid-area(1 / 2 / 3 / 4) {
  background-color: red; /* etc */
  /* grid-positioning properties are blacklisted */
}

But it does raise a few questions for me:

Managing grid flow and areas

@@@ Flesh out the rest of these

Regions & fragmentation

There’s a real interesting Working Draft of CSS Overflow that includes fragmentation as an overflow value. That could be combined with various layout modules, to create a very flexible approach to CSS Regions.

The spec authors are David Baron & Florian Rivoal. It might be good to check with them about the status of the spec.

Defining Grids

Sub-grid improvements

Improving grid gaps

Notes

enhancements to level 1: