+1 This is one of the many things I think we want in order to be able to style the Grid, or style based on a position on the Grid. nth-row would be great — or really, nth-track (row or column). Also to be able to target a specific cell. To make the one cell where the 2nd row and 3rd column intersect, for example.

I think this is related to being able to style a cell. To target the second row and give it a background color. Ir to put a border around the cell where the 2nd row and 3rd column intersect. If we can target the cell or track, we can either style it, or style the content within it.

Thanks for opening this - here are a few use cases in which I'd fine it useful:

Styling elements that spill onto the second row or column:

Tiger Striping rows/columns

I like @jensimmons's suggestion to selecting the track as I could see the need to doing specific TRBL grid-gap on each of those.

The trouble with this is that selectors can be used to set the placement properties (grid-area), which can change which row the item is in. :) For tables we work off of the markup only: the selector works even if you style the table as a list, so we don't have this cyclic problem.

The use case makes a lot of sense, but I don't see how to make it work...

Adding to @fantasai's point, in @wesbos's 2nd example if there were some boxes that were n x m rather than 1 x 1 how should selecting nth-row/nth-column/nth-track affect boxes in multiple tracks? e.g. the 'facebook' element in the image below.

option 1

option 2

@fantasai wrote:

The trouble with this is that selectors can be used to set the placement properties (grid-area), which can change which row the item is in. :) For tables we work off of the markup only: the selector works even if you style the table as a list, so we don't have this cyclic problem.

The cyclic problem could be solved by applying the selector to the grid tracks, not to the grid items themselves, so grid-area and Co. do not apply.
Having said that, it sounds like it might be solved by using pseudo-elements rather than pseudo-classes, similar to what's described in #499.
So, @rachelandrew's example might be achieved like this:

nav {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(150px, 1fr));
}

nav::nth-row(1n+2) {
  background-color: red;
}

@kartikadur wrote:

Adding to @fantasai's point, in @wesbos's 2nd example if there were some boxes that were n x m rather than 1 x 1 how should selecting nth-row/nth-column/nth-track affect boxes in multiple tracks?

Like the :nth-col() pseudo-class described in Selectors 4, the selector also applies to items spanning over several tracks. I.e. when several selectors match the same area, the normal specificity and cascading rules apply.

Sebastian

This feature would be very useful!

@SebastianZ - The title of this issue is about nth-row and I see only nth-column in Selectors 4 draft..

yes nth-row would be really awesome

@SebastianZ - The title of this issue is about nth-row and I see only nth-column in Selectors 4 draft..

Right. That should have read nth-row. I've updated my example.

Sebastian

Would a fix for this! :D

Another use case would be a bookshelf sort of layout - i.e. adding a border or background image to go across all the rows

Would be so nice to create a checkered background for a calendar/planboard.
To be able to style the rows and column(tracks) independent of it contents(items)
for weekends for example (yellow line). Maybe add the ability to hover/active tracks.

In addition to be able to target the nth-row and nth-column for styling it would also be great to be able to target a row or a column with a hovered or focused cell. I.e.

nav::row-hover, nav::row-focus-within {
  background-color: red;
}

I could use this feature as well. Would be great to have it!

The trouble with this is that selectors can be used to set the placement properties (grid-area), which can change which row the item is in. :) For tables we work off of the markup only: the selector works even if you style the table as a list, so we don't have this cyclic problem.

The use case makes a lot of sense, but I don't see how to make it work...

Stab in the dark, but is there any precedent for ignoring certain properties declared in certain selectors?

Unfortunately, not possible. You can make it work once, but as soon as you have a second feature where a property can affect a selector, you can create loops by using one selector to set the other's properties, then the other selector to set the first's properties. You end up having to ban all properties that can affect any selector from being used in any of them, which is (a) annoying and weird, and (b) prevents us from ever adding more selectors that depend on existing properties (because we might break code currently validly using those properties with other property-affected selectors).

I’m also needing this becuase there is no collapse border for css grids.

So I have to only add border on right and bottom except for last row and column because parent container will have a border.

It's been 5 1/2 years. Is there any progress on this?

why does this not exist after so many years? There still is no solution.