Re: [csswg-drafts] [css-grid] Better cell placement controls. (#12658)

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

```css
.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

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

I have now created an additional column beyond `column-count()`. In fact, if you have an explicit grid template without auto-fit/fill rows and columns, setting `grid-cell` to anything greater than row-count × column-count will land you in this situation. 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).

-- 
GitHub Notification of comment by Noleli
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12658#issuecomment-3224506388 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 26 August 2025 14:51:15 UTC