[css-grid] Better cell placement controls.

[Westbrook]

An author is able to apply any (I think 😉) of the following (and more) values to grid-template-columns/rows:

.grid {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(100px, 1fr));
    grid-template-columns: repeat(auto-fit, minmax(100px, 200px));
    grid-template-rows: repeat(auto-fill, minmax(100px, auto));
    grid-template-rows: repeat(auto-fill, minmax(100px, auto));
    /* ... etc ... */
}

And, in doing so, the author is ceding to the page the management of how many rows or columns will display at any one time. Which inversely means that at any one time the author is currently unable to know for sure how many columns or rows are being displayed to the visitor of their site. If said author wants to put something in the 5th cell (starting from the top/left) of the grid, how could they know for sure at any one time that the content is in that location?

Currently, authors can do this with fixed amounts of columns or rows by doing something like:

.grid {
    display: grid;
    grid-template-columns: repeat(var(--column-count), 100px);
    grid-template-rows: repeat(var(--row-count), 100px); 
    --column-count: 3;
    --row-count: 3;
}

.cell-5 {
    --cell: 5;
    grid-column: calc(mod((var(--cell) - 1), var(--column-count)) + 1);
    grid-row: round(down, calc((var(--cell) - 1) / var(--column-count) + 1));
}

Does CSS support authors in being responsive while also being exact?

Sort of...

See the fascinating work of @Noleli in this area: https://codepen.io/noleli/pen/QwjBWqz It really is quite amazing what we're able to do with the diversity of primitives the CSSWG has brought to life, but the specifics of this feel like more work that is appropriate for an author to need to manage. To make this work, we have all of the following intervening levels of complexity:

• a grid element
• a containing element for it on which to apply container queries
• some advanced algebra
• and 5 custom properties

That's just too much, right?

After creating Noah, he agrees:

The thing that suggests to me that maybe the CSSWG should consider something is that I as an author had to re-solve the same math that the layout engine does under the hood. Sure, it’s possible, but an author has to figure out the math and then the browser has to do it twice.

Options

I see two useful paths towards supporting authors in delivering content in this way. One is maybe more direct, the grid-cell property, while another maybe opens a broader array of capabilities over time, the grid-columns() and grid-rows() functions.

grid-cell

A grid-cell CSS property could work much like grid-column or grid-row but traverse multiple rows or columns to resolve it's location. In that way a flexible version of our target layout could be achieved with something like:

.grid {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(100px, 200px));
    grid-template-rows: repeat(auto-fill, minmax(100px, auto));
}

.cell-5 {
    grid-cell: 5;
}

Grid cell counting could/should follow text direction counting allowing the author to build off of the large flow of their content when targeting a specific cell to place their content in.

grid-columns() and grid-rows() functions

In line with the recently added sibling-count() CSS function, surfacing the actual number of columns or rows for use in the larger CSS construction could not only support the specifics of the example above, but possibly unlock various others that grid-cell may otherwise preclude. The CSS to leverage these properties is closer to the manual implementation, without the actual manual application:

.grid {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(100px, 200px));
    grid-template-rows: repeat(auto-fill, minmax(100px, auto));
}

.cell-5 {
    --cell: 5;
    grid-column: calc(mod((var(--cell) - 1), column-count()) + 1);
    grid-row: round(down, calc((var(--cell) - 1) / column-count() + 1));
}

Point of use resolution here would likely be important so that it would be possible to leverage compound grids and their column/row counts without context bleed:

<div class="grid-ancestor">
    <div class="cell-5 grid-descendent">
         <div class="cell-5"></div>
    </div>
</div>
<style>
.grid-ancestor {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(100px, 200px));
    grid-template-rows: repeat(auto-fill, minmax(100px, auto));
}

.grid-descendent {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(50px, auto));
    grid-template-rows: repeat(auto-fill, minmax(100px, 150px));
}

.cell-5 {
    --cell: 5;
    grid-column: calc(mod((var(--cell) - 1), column-count()) + 1);
    grid-row: round(down, calc((var(--cell) - 1) / column-count() + 1));
}
</style>

In this case for .grid-descendent.cell-5 the values of column-count() and row-count() would need to resolve to those created by .grid-ancestor, while for .grid-descendent > .cell-5 the value would need to resolve to those created by .grid-descendent.

The same should likely hold true to their application to CSS Custom Properties:

<div class="grid-ancestor">
    <div class="grid-descendent">
         <div class="cell"></div>
    </div>
</div>
<style>
.grid-ancestor {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(100px, 200px));
    grid-template-rows: repeat(auto-fill, minmax(100px, auto));
    --ancestor-column-count: column-count();
    --ancestor-row-count: row-count();
}

.grid-descendent {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(50px, auto));
    grid-template-rows: repeat(auto-fill, minmax(100px, 150px));
    --descendent-column-count: column-count();
    --descendent-row-count: row-count();
}

.cell {
    /* some magic incantation that relies on the discrete values of `--ancestor-column-count`, `--ancestor-row-count`, `--descendent-column-count`, and `--descendent-row-count`, while understanding the `--ancestor-column-count` vs `--descendent-column-count` and `--ancestor-row-count` vs `--descendent-row-count` will be specific to the realities of `.grid-ancestor` vs `.grid-descendent` and the respective grids that they deliver. */
}
</style>

Thanks for your conscideration! 🙇🏼‍♂️

[Noleli]

Interesting, thanks for kicking this off, @Westbrook. I’m still taking this in, but my initial thoughts:

On grid-cell

Maybe this should be embarrassing, but the funny thing is that I intuitively expect grid-area to behave like the proposed grid-cell when given a single integer rather than as the shorthand it is 🫣. I can certainly see it being useful to be able to place something in the Nth grid area regardless of its row/column coordinates.

Something that could get hairy is how it interacts with implicit grid areas. If I have

.grid-parent {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(10rem, 1fr));
}

and my grid parent is wide enough for 3 columns, I know what I expect to happen if I have one child and set grid-cell: 5: it’ll add a second row and place it in the middle column. That’s because, as you say,

Grid cell counting could/should follow text direction counting allowing the author to build off of the large flow of their content when targeting a specific cell to place their content in.

But might that behavior depend on the value of grid-auto-flow? Maybe I’m overthinking it because that behavior has already been worked out for regular auto-fit/fill cases, but someone smarter than me may need to give that some thought. It also feels like it introduces some ambiguity around what are implicit vs explicit grid tracks, but again, that has already been worked out when directly specifying grid-row and grid-column with values beyond the explicit tracks, so I’d anticipate the same behavior here.

On column-count() and row-count()

The main things I’m thinking about here are:

Is there a risk of cyclicality?

If I do

.grid-item {
    grid-column: column-count() span 2;
}

I have now created an additional column beyond column-count(). Using *-count() in a calc could also land you in this situation, like setting grid-cell: calc(row-count() * column-count() + 1). This type of thing would have to be disallowed if not deemed a blocker in the first place.

Could you allow cutom idents for grids to query other grids?

You say,

Point of use resolution here would likely be important so that it would be possible to leverage compound grids and their column/row counts without context bleed

which should definitely be the default behavior when passed no arguments.

But it reminds me of #2530, where the idea of custom idents to refer to specific grids would allow placing elements arbitrarily into any grid on a page. That’s obviously quite different from what you’re proposing, but if grids had custom idents, I could imagine being able to pass them into column-count([<custom-ident>])/row-count([<custom-ident>]) to get columns and rows for the specified grid (c.f., #7858 for similar precedent).

[tabatkins]

See the fascinating work of @Noleli in this area: codepen.io/noleli/pen/QwjBWqz

Ah, it took me a while to realize what was going on here, since the calc() syntax doesn't work in Chrome yet so I was just seeing what looked like a perfectly normal Grid ^_^. It's setting the height of output and the background color of the lis based on how many columns are in the grid, determined by doing some math on CQ units.

---

A row/column count function isn't cyclic in Grid so long as it refers only to the explicit grid (what's defined by grid-template). If you want it to refer to the implicit grid (extra columns/rows created by placement, defined by grid-auto-*), then yes, it's cyclic, as you can put an element into the N+1th column. In this example, then, one could potentially count the number of columns, but there's always 0 explicit rows.

However, in Masonry it's potentially cyclic in all cases, because resolving the repeat() is allowed to depend on the heuristically-determined size. You'd need some handling similar to how we treat width: 50% on children when the parent is content-sized (basically, just treating the counting value as 0 (or maybe 1) while figuring out how many tracks there are, then letting it resolve properly afterwards). (We can't fix the Grid cycle in this way, however, as it's cyclic in a different, "larger" fashion.)

---

A grid-cell CSS property could work much like grid-column or grid-row but traverse multiple rows or columns to resolve it's location.

This is, again, potentially workable if it counts based on the explicit grid, at least when determining what index it wraps at. (So, for the standard grid-auto-flow: rows, it would just need to care about grid-template-columns.) However, I wonder how useful that really is. Do you have some examples of how this would be used? It could also be done by relying on grid-auto-flow and using order to, say, put 4 of the auto-flowed items before it and the rest after it.

---

Outside of any solution in pure CSS, I've had an action item to actually define a Grid Information API in JS for years now, so you can just ask an element how many rows/columns it ended up with, their sizes and positions, and what grid areas the items ended up in. Would that help here?

[Westbrook]

The actual use case that I am leveraging this for is virtualized scrolling. The act of having a fixed scrolling area and content that is taken on and off of the DOM as the specific area they fill comes close to the viewport (for background).

For a "grid list" (fixed content size, one dimensional grid) it is working excellently. As noted in the OP grid-column or grid-row are great for placing the content where it needs to go and grid-template-columns: repeat(var(--item-count), 100px); does the magic of holding the content open without needing placeholder elements.

For a "fixed grid" (fixed content size, fixed delivery size, two dimensional grid) the math is pretty easy to do, and the intersection of grid-column and grid-row work pretty well. I previously prototyped that, but will be moving into a more serious implementation later this week.

It's the responsive sizing of the content that is a little tricky. I'd love for something like grid-cell to "just work". It's 100% in the explicit grid, for my use cases. And, I'd be totally fine with it being grid-area and it an integer being the part that signs the contract on "exactly where to go". Great suggestion on that Noah!

I like the pure CSS solution, because it theorizes the ability to do less at large, but in that JS is involved in this process, I would not be opposed to it being a Grid Information API in the JS, either. Feels like a larger lift at the browser level; maybe the perception of a deeper investment in CSS advancements by browser vendors is purely experiential 🤞🏼. Have you thought of what that sort of API might look like at all?

Which ever path felt most likely, I'd be happy to help work through possibilities. 🙇🏼