[css-grid] Decorative grid-cell pseudo-elements

[tabatkins]

@jensimmons proposes adding a grid-cell pseudo so you can add (responsive) decorative elements to grids without having to add empty elements to your page.

Syntax like:

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

Also some way of controlling whether or not that takes up auto-flow space. Might want to reserve space or not. Can we base this on 'content' or something? Or do we need a new property?

[jensimmons]

The slides from the presentation I just gave are at: https://speakerdeck.com/jensimmons/proposal-to-csswg-sept-2016

And actually, the syntax above is not what I proposed. This is what I proposed:

@region #grid-container foobar {
  grid: 3 / 1 / 4 / 2; 
}
foobar {
  background: yellow;
}

[MatsPalmgren]

If a pseudo-element solves this use case then why not allow multiple ::before/::after instead?

#grid-container::before(1) {
  grid: 3 / 1 / 4 / 2;
  background: yellow;
}
#grid-container::before(2) { ... }
etc

which would be useful for all elements, not just grid.

[fantasai]

@jensimmons The syntax Tab proposes here fits better into the CSS model, imho. Though I can see the case for wanting to have a name for the thing.

@MatsPalmgren Multiple pseudo-elements are a bit more problematic wrt cascading usability imho. It's easy to lose track of some and then have weird stuff appearing in your document or have styling pulled in from some rule that you have neglected to overrde. Tying it to grid and limiting it this way makes it easier to clear out and avoid such problems.

[gregwhitworth]

This seems like a merging of @apply and CSS being able to pierce the shadow DOM. I agree that the author should be able to style area boxes, but I'm not entirely sure we should be solve this problem specifically focused on grid. I think it would be best, and I know we've tried and failed, to provide a generalized solution for styling boxes that exist but don't have an element associated with them that is targetable via general selectors.

[SelenIT]

I believe that having a grid-specific way to style grid area boxes would be useful. Grid areas differ from other virtual/dynamic CSS boxes (like line boxes, column boxes in multicolumn layout etc.) because they 1) definitely exist regardless there is any content associated with them, 2) have clear mechanism to address them (by name, line numbers etc.) and 3) clear algorithm to calculate their size. Essentially we can use the same logic as for placing a ::before pseudo under the hood, though the syntax proposed by Tab looks less 'hacky' to me (what we usually want is to style the "virtual container" itself, not to place something there just to emulate this, which looks more like a workaround if there is no more direct way to do it). But pesonally I would be happy with multiple pseudos either.

[morganfeeney]

Use case:
a designer / developer / designoper is able to create a grid overlay which would act as design reference. Applying it using CSS could be as suggested in @tabatkins opening comment, a pseudo-element but with super Grid powers. This benefit of an overlay can then be gained by:

• Translating a design from a program like Sketch or Illustrator to the browser with accuracy.
• Being creative whilst using the browser as a device for laying-out content, new ideas can be applied once the design has been translated, through experimentation.

Otherwise grid alignment, and understanding the possible variations using a grid, is essentially 'by eye'. Other than being able to imagine the structure of a grid layout, or refer to a piece of paper with a grid drawn out on it whilst working, there inevitably needs to be a way to display a grid of this kind.

It would be also very cool if I could use Firefox's grid inspector to enable the view of this reference grid and allow me to use it in a way similar to how I have created my crude example here: https://interiorsystem.co.uk/ — toggle the overlay. Also if using Firefox you'll be able to see there is a difference between the grid of what is inspected and the reference, which is used to apply the design to.

Inspected grid
Note that when you inspect an implicit grid the cells fit the content.

Design reference
This example is agnostic of whether a grid is implicit or not.

This idea is not new, there are reference books which teach the use of grid layout, I haven't seen a single book that doesn't show a grid overlay as part of the process. Screen shots from a PDF on the book Grid Systems in Graphic Design written by: Josef Müller-Brockmann to demonstrate.

[o-t-w]

I have used grid on 3 websites and have need to selectively apply borders based on the row/column the item is in (e.g. border-bottom but not on items in the bottom row).

You can see an example here: https://www.nature.com/nplants/

In both cases I used overflow: hidden. It worked well but feels hacky. Any potential solution for that? e.g. ability to select elements by the column or row they are in? Using current nth-child solutions can get very complicated!

[g12n]

Hi @jensimmons ! I love the idea! It tackles a lot of current problems. I am currently writing a longer comment about the implications for paged media and it's relations to flexbox, grid and multicolumn-layouts. But before i can finish it, I would like to understand your proposal a little bit better.

In your presentation on slide 38 you use the grid property to place an grid-element in its grid-container. Is this new? Or did you meant grid-area?

Using my current grasp of grids, I would write something like this:

#grid-container{
    grid: repeat(3, 1fr) / repeat(3, 1fr);
}

@region #grid-container foobar {
  grid-area: 3 / 1 / 4 / 2; 
}

foobar {
  background: yellow;
}

Other examples

Use of named grid-template-areas defined in the grid container:

@region #grid-container foobar {
  grid-area: left; 
}

Selection of a whole column to style:

@region #grid-container left {
  grid-column: 1 2; 
}

Relation to named grid-template-areas

How does your proposal relate to grid-template-areas?
It feels to me like a second mechanism to name them. With the added bonus, that this way named areas could overlap.

Would something like this work:

@region #grid-container foobar {
  grid-area: 3 / 1 / 4 / 2; 
}
.childelement {
    grid-area: foobar
}

Though then I would suggest @area or @template-area for the keyword.

Maybe a different selector-syntax?

I am concerned about this part:

foobar {
  background: yellow;
}

Simple element-selector syntax for a named grid-area seems dangerous to me.

Because changes in the HTML-Spec might introduce elements that are identically named to areas named by CSS-authors and break the page. I guess that's the reason, why we have the two dashed at the beginning of css-custom properties.

Maybe a Pseudo-Selector, At-Rule or something similar to the custom-property syntax would work better.

I like the close alignment to the @keyframes syntax. But I am not sure about it. Keyframe Animations are quite global – a bit like custom-properties. Grid-Areas on the other hand are tightly bound to the Grid Container itself.

Can you point me to additional resources, where I can learn the formal definitions and differences between these mechanisms. Especially the formal difference between pseudo-selectors and at-rules are quite foggy to me at the moment.

[rachelandrew]

Article on CSS Tricks where the author is coming up with ways to add borders between cells, adding as another example of developers needing to do this https://css-tricks.com/techniques-for-a-newspaper-layout-with-css-grid-and-border-lines-between-elements

[SebastianZ]

As far as I understand it, this issue is rather about styling the the cells and areas, it's not meant for placing borders between them. Styling the grid gaps is covered in #2748.

Sebastian

[fantasai]

Referencing the original proposal in #499 (comment) here's a few details we'd want to specify:

• ::grid-area() pseudo-element takes the same values as the grid-area property, minus auto-placement values
• ::grid-area() arguments can also use nth-child syntax in place of <integer>. For example, ::grid-area( 1 / 2n / 3 / span 2 ) represents any grid area spanning the first and third row lines that starts on an even column line and spans two tracks.
• ::grid-area() with arguments that reference the same area have the same identity
• ::grid-area() without arguments matches every grid-area pseudo-element
• accepts all properties that apply to grid items, and content, except grid-placement properties
• content causes it to exist or not exist, same as ::before
• a grid-area pseudo takes up space for the purposes of the auto-placement algorithm the same as any other item
• effect on creation of implicit lines is the same as for other grid items with the given placement
• box order defined as a child before everything in the grid (including ::before/::marker/etc.)
• multiple child areas are ordered by grid-auto-flow
• overlapping child areas are ordered by size (number of cells), largest first, breaking ties by the grid-auto-flow order of the first non-shared cell
• originating element is the grid container

[astearns]

Process-wise, I think it’s OK to continue discussing all of the details above in this issue. But we should not need to resolve all of the details before deciding to take this feature up. A good outcome for this issue is to decide to start work on what we have managed to agree on here, and open new separate issues for remaining details.

[astearns]

Since there are use cases for both grid-areas that take up space in the placement algo and those that do not, perhaps declaring the pseudo-element would cause it to exist, and content could trigger whether the placement algo notices it?

[Loirooriol]

::grid-area() arguments can also use nth-child syntax in place of <integer>

If we go this way, I think there should be a way to specify multiple conditions. For example, I can use :nth-child(2n+4):nth-child(-2n+18) to select a range of children (even indices between 4 and 18, inclusive). This kind of things don't seem possible with the proposed ::grid-area

content causes it to exist or not exist, same as ::before

So, if I get it right, ::grid-area doesn't actually style grid areas. Instead, it creates anonymous grid items in a certain grid area with the specified content?

What happens with things like ::grid-area(1 / 1 / 1 / 1)? Is it no-op (empty area)? Does it create a grid item in the area 1 / 1 / 2 / 2 like in https://drafts.csswg.org/css-grid/#grid-placement-errors ?

[css-meeting-bot]

The CSS Working Group just discussed Decorative grid-cell pseudo-elements, and agreed to the following:

• RESOLVED: jensimmons and rachelandrew to write up use cases, examples, and syntax for this proposal

The full IRC log of that discussion

<astearns> topic: Decorative grid-cell pseudo-elements
<astearns> github: https://github.com//issues/499#issuecomment-926122734
<castastrophe> @fantasai This is largely prompting from @jensimmons going over use-cases for this
<castastrophe> @fantasai There was a syntax in the original context that was grid-area pseudo element as the grid area shorthand
<castastrophe> @fantasai so we asked what are the questions we need to answer in the spec to have somethign that works
<astearns> s/@fantasai/fantasai:/
<castastrophe> +1
<astearns> fantasai: (summarized comment)
<fantasai> [ fantasai summarizes comment https://github.com//issues/499#issuecomment-926122734 ]
<castastrophe> fantasai: would not accept the grid-placement properties
<castastrophe> fantasai : ...a whole pile of details that we think makes this into something we can possibly spec up
<castastrophe> :)
<emilio> q+
<Rossen_> q+
<castastrophe> jensimmons : the goal here is to create a pseudo element without having to place empty divs in a cell;
<rachelandrew> q+
<chrishtr> q+
<chris> rrsagent, here
<RRSAgent> See https://www.w3.org/2021/09/29-css-irc#T14-13-09
<castastrophe> jensimmons : this really is about creating a way to target a track an area or a cell directly and not need empty divs
<castastrophe> jensimmons : this felt like the simplest approach without having all the craziness
<castastrophe> Rossen_ : we'll go through the queue, circle back to the specifics and knock out some of the bullets
<Rossen_> ack emilio
<castastrophe> emilio : are they tree-abiding pseudo elements?
<castastrophe> fantasai : yes
<castastrophe> emilio : seems a bit weird, imagine you have a bunch of conditions ...
<castastrophe> (sorry missed some parts)
<castastrophe> emilio : need to go through all the grid area selectors independent of all the
<astearns> emilio: concerned about creating multiple boxes per selector
<castastrophe> emilio : it can possibly work, it's just weird to do that
<castastrophe> emilio : you can have a first-line style, if the page doesn't use them at all, just skip this mess
<castastrophe> emilio : I need to work out all the details
<fantasai> i/emilio : it can/fantasai: Not sure, but are you referring to how you need to do placement before deciding which/how many boxes you have?
<castastrophe> emilio : multiple of these selectors can match ; the fact that this happens before box construction
<castastrophe> iank_ this would invalidate layout potentially right?
<castastrophe> fantasai : placement first but then layout second
<castastrophe> fantasai just impacts box-tree and auto-placement
<fantasai> s/match/match, and their declarations need to cascade/
<fantasai> s/fantasai/fantasai:/
<fremy> @emilio: you mean like table backgrounds and borders ^_^
<castastrophe> jensimmons there are use-cases where it could be helpful to do more than borders and backgrounds
<Rossen_> q
<castastrophe> jensimmons if there's a hard limit, that would make things too many paints, too many cycles; then bring it in. I'd like to see if we can not limit it right out of the gate
<iank_> q+
<fantasai> s/jensimmons/jensimmons:/
<castastrophe> Rossen_ : feedback is creating grid cells starts off with this very simple and seemingly very easy expectation that oh we'll just put a background
<castastrophe> Rossen_ : then as soon as you go down the rabbit hole, you're talking about having user expectations that are matching that of focus-handling, all kinds of eventing and capabilities
<castastrophe> Rossen_ : for example focus and app development management that make sense, especially in the grid layout which can vary vastly
<florian> q?
<castastrophe> Rossen_ : as we approach this kind of solution, it is in a way that we are not ignoring everything coming down the line in expectations
<Rossen_> ack Rossen
<castastrophe> Rossen_ : multi-column columns where people want to be able to target and style individual columns
<castastrophe> Rossen_ : the difference there is that multi-column is a scoped use-case to grid
<castastrophe> Rossen_ : if we start going down the path again, if we don't have great answers from the get-go for the use-cases I enumerated, then all we are doing here is solving the easy use-case of "let's put a little bit of background"
<castastrophe> Rossen_ : I'm concerned about trying to fit functionality and user expectations of elements into pseudo-elements
<Rossen_> q?
<florian> q?
<castastrophe> rachelandrew : I like the idea of being able to do this; my concern if we don't solve the borders on grid-cells issues first
<castastrophe> rachelandrew : authors will use this to style the gaps
<astearns> Rossen's concerns all sound like separate issues to raise on spec text that we need to write - yes, this will be complicated, we shouldn’t minimize the effort. But it will be worth the work
<Rossen_> ack rachelandrew
<castastrophe> rachelandrew : I kind of like this idea, I understand where Rossen_ is coming from
<castastrophe> rachelandrew : We add all these pseduo-elements and authors use it to add borders because authors want to use them to style the gaps
<castastrophe> rachelandrew : that comes up for me far more often than trying to s tyle the grid
<jensimmons> I agree with rachelandrew 's point — let's make sure we spec styling gaps before finishing this... and encourage implementors to ship gap styling before or with cell styling.
<castastrophe> rachelandrew : if people can do this grid, why can't we do this with multi-column?
<castastrophe> rachelandrew : it's the same in their minds; is this not something we'll need to do in multi-column too?
<castastrophe> rachelandrew : for authors, it could reduce mental load
<Rossen_> ack fantasai
<Zakim> fantasai, you wanted to react to rachelandrew to respond to the concern about gaps
<castastrophe> fantasai : +1 to rachelandrew
<castastrophe> fantasai : gaps issue is coming
<castastrophe> fantasai: I agree with the prioritization of shipping order
<castastrophe> chrishtr : it sounds like this is a feature that allows you to do something you can already do in a more convenient way
<florian> q+
<castastrophe> chrishtr : it sounds like it would be quite - in addition to the issues Rossen_ mentioned, could be quite complicated - could slow down interactions on implementation in the browser
<castastrophe> chrishtr : does this use-case justify complexity
<Rossen_> ack chrishtr
<castastrophe> jensimmons : I think there are quite a few use-cases that this could solve for
<TabAtkins> I'm not sure what would slow things down more than adding those elements as real HTML
<castastrophe> Rossen_ : you can do that if you add elements there
<castastrophe> chrishtr : you can do all this with adding the elements
<Rossen_> ack iank_
<castastrophe> jensimmons : there's a big difference between having the space and targeting the space with CSS
<castastrophe> iank_ : I want to bring up how this interacts with a11y
<fremy> @tabatkins: you have to add them during layout, and their order in the "DOM" depends on the grid placement which can change depending on container queries etc...
<fantasai> s/having the space/having elements in the tree/
<castastrophe> iank_ : currently we have before and after markup, depending on the context
<castastrophe> iank_ : I'd be concerned that people would use the content property
<Rossen_> q?
<castastrophe> iank_ : to add more content in CSS
<chrishtr> Don't pseudo-elements affect layout and take up space?
<Rossen_> ack florian
<emilio> yeah, that's my understanding
<castastrophe> florian : from an author standpoint, this syntax seems spot-on
<castastrophe> florian : this makes it extremely learnable
<fantasai> s/spot-on/spot-on, once I've seen it can't think of anything else/
<castastrophe> florian : when you start thinking about pointer events, etc. - on the one hand yes, on the other, we're overdue on discussing these issues
<castastrophe> florian : I'd like to hear from jensimmons about use-cases that go beyond border and background
<castastrophe> florian : without needing a subtree or a pseduo-element
<Rossen_> q?
<castastrophe> jensimmons : <pulling up slides>
<castastrophe> jensimmons : I feel unprepared to answer this question
<castastrophe> jensimmons : it would be great to allow an element to tilt without an nth-child
<emilio> q+
<florian> q+
<castastrophe> jensimmons : there's this idea that content can flow automatically, especially with responsive design
<Rossen_> q?
<castastrophe> jensimmons : not wanting to write a bunch of breakpoints; need a way to separate particular areas on the grid without manipulating the way content is flowing
<castastrophe> jensimmons : this is not about creating more content, this is about styling
<astearns> ack emilio
<castastrophe> emilio : the example shared jensimmons, I thought the idea was creating boxes / grid-items and being able to style them
<castastrophe> emilio : what you showed was that these items would exist inside the grid
<castastrophe> fantasai : I don't think we can do that example in the proposal that we have
<castastrophe> fantasai : we could possibly do that if you didn't want the content to rotate
<castastrophe> fantasai : you could do that with the pseudo-items and have the grid-item on top of that
<castastrophe> emilio : if I understand, then you can do this with regular elements
<castastrophe> fantasai : the problem is that with a regular element, you would have to inject a bunch of empty divs
<rachelandrew> https://github.com//issues/1943 is more like that first use case
<castastrophe> emilio : i agree, I just wanted to wrap my head around it
<castastrophe> emilio : a syntax to inject a bunch of elements onto the grid in a particular order to style them
<castastrophe> fantasai : if we could select things by their placement in the grid, that would also be awesome
<florian> q-
<castastrophe> fantasai : that has a problem of the selection being dependent on a layout
<castastrophe> fantasai : change as the size of the page changes
<castastrophe> fantasai : part of what this is trying to solve is a handful of cases that don't involve styling the element itself
<castastrophe> iank_ : variable content types, want content on a diagonal, how does this work for that case? It seems like you want to insert pseudo-elements based on the size of the grid
<castastrophe> fantasai : block out the cells you want to block out by making them
<castastrophe> iank_ : wouldn't that expand out the grid
<castastrophe> fantasai : yes, you wouldn't use that when you only have a few items
<castastrophe> fantasai : a lot of these are cases where the author knows the minimum and maybe the maximum but doesn't know the number of columns because that depends on how wide the screen is
<castastrophe> iank_ : I'm a little suspicious of the "knows how many items". For that use-case where you want to skip grid areas
<castastrophe> iank_ : It seems like it's actually easier to inject DOM
<castastrophe> iank_ : Or a grid property that says, skip this grid area
<castastrophe> iank_ : dynamic size of content didn't mesh in my mind
<castastrophe> fantasai : I agree in that use-case it would be better to inject DOM
<fantasai> s/inject DOM/specify skipped cells in a property/
<fantasai> s/inject DOM/specify skipped cells in a property/
<castastrophe> astearns : Next steps to draw out use-cases and corner-cases so we can talk through code examples
<castastrophe> astearns : it doesn't sound like we're ready to say yes let's put this in a working draft
<florian> q+
<castastrophe> iank_ : I don't think we need an editor's draft, just writing down the examples in the issue
<castastrophe> astearns : I think this is getting too complicated for an issue
<castastrophe> astearns : spec text would be helpful; we wouldn't have to adopt the draft if we weren't happy with it
<castastrophe> jensimmons : if folks are willing to explore this area, this seems like something we want to solve
<castastrophe> jensimmons : yes, an editor's draft with real-world use-cases
<castastrophe> jensimmons : then we can point at items and identify what n eeds to be better
<astearns> ack florian
<castastrophe> florian : I support this for those who feel this is a bit early
<castastrophe> florian : I came in really liking it and wondering if it's an uncanny valley of too much and not enough
<castastrophe> florian : Want to see more examples to see if this comes close enough
<castastrophe> iank_ : use-cases written down clearly would be really useful; there might be multiple avenues we can explore
<castastrophe> iank_ : we've talked about styling columns and gaps, that could be a different selector
<castastrophe> iank_ : multiple avenues we could go down
<florian> s/those who feel this is a bit early/those who feel this is a bit early, think of that early spec as an explainer/
<fantasai> s/that could/the rotated item case, that/
<castastrophe> astearns : makes sense
<castastrophe> jensimmons I will help make use-cases
<castastrophe> jensimmons I can't help write the spec
<castastrophe> rachelandrew happy to help with this
<fantasai> s/jensimmons/jensimmons:/
<fantasai> s/jensimmons/jensimmons:/
<fantasai> s/rachelandrew/rachelandrew:/
<castastrophe> astearns : task jensimmons and rachelandrew to work through examples and syntax
<castastrophe> astearns: Resolved
<fantasai> RESOLVED: jensimmons and rachelandrew to write up use cases, examples, and syntax for this proposal
<TabAtkins> ScribeNick: TabAtkins

[MatsPalmgren]

@fantasai

* `::grid-area()` pseudo-element takes the same values as the `grid-area` property, minus auto-placement values

What are the reasons auto-placement is disallowed?

* `::grid-area()` arguments can also use nth-child syntax in place of `<integer>`.

n is ambiguous since it's also a valid line name.

* `::grid-area()` with arguments that reference the same area have the same identity

That's good, but web developers have expressed a need for multiple pseudos (#6169 etc). The additional effort to implement that is negligible, so I'm sad that use case isn't addressed. E.g. something like ::grid-area(ident-1, 1 / 2n / 3 / span 2) {...} ::grid-area(ident-2, 1 / 2n / 3 / span 2) {...} would create two separate pseudos in the same area(s).

* `::grid-area()` without arguments matches every grid-area pseudo-element

Presumably with lower specificity?
Does ::grid-area() { content:""; } by itself create a pseudo? If so, what's its area?

* a grid-area pseudo takes up space for the purposes of the auto-placement algorithm the same as any other item

That seems like a big mistake to me. I think most use cases would be better served if decorative pseudos don't mess with the grid layout at all. I think this should be optional, and the default should be that ::grid-area pseudos don't take up space in the grid (i.e. regular grid items are "placed on top" of the decorative items).

I think it would be useful to have a property for this, something like grid-fill: auto | none | fill, that can be used on non-pseudo grid items too (this has already been requested by web developers). Then you can make some child elements "decorative" with grid-fill: none and not be constrained to what can be produced with content. (auto would resolve to none for grid-area pseudos, and to fill for regular grid items).

* box order defined as a child before everything in the grid (including ::before/::marker/etc.)

That seems like an odd order to me. Is there a reason you want that order?
::marker, ::before, ::grid-area pseudos, children, ::after seems more natural to me. They should at least come after the grid container's ::marker (note that grid containers don't support ::marker yet though).

---

I don't understand how this proposal can be implemented though. Specifically, the nth-child syntax when combined with "a grid-area pseudo takes up space" seems like it could easily create an infinite number of pseudos. A pseudo that takes up space may create new tracks in the grid, i.e. new grid areas, creating a circular dependency. It would be great if you could explain what stops that from happening. (I need detailed and ordered steps of when to create the pseudo in relation to, and how it interacts with, establishing the implicit grid and the grid item placement steps.)

(A pseudo that doesn't take up space doesn't have that problem since it's constrained to only match the grid tracks created by other items that does.)

[MatsPalmgren]

@Loirooriol

So, if I get it right, ::grid-area doesn't actually style grid areas. Instead, it creates anonymous grid items in a certain grid area with the specified content?

That's exactly how I think this should be specced and implemented too. We already have specs and implementations for that, and authors already have an understanding of it, that we should leverage. It's also much more powerful than just doing some extra background painting. The only thing that's special here (IMO) is the pseudo selector and how that maps to, and interacts with the formation of, the grid. We should focus on solving that.

[SelenIT]

However, these anonymous grid items should be auto-placed independently of "natural" grid items (including those created from text nodes and ::before/::after), right? If auto-placement algorithm will consider grid areas with these new pseudos as "occupied" and authors will need to explicitly specify the grid area in order to overlap them, it seems to contradict the main idea of this proposal...

[MatsPalmgren]

Right, that's why I suggest they don't make grid areas occupied by default. I think it should be decoupled from being a ::grid-area pseudo though, with a grid-fill property or some such, to give the author the flexibility of opting in/out from that for any item.

One way of achieving that might be to do two separate placement runs. So first we run the whole grid item placement algo with the grid-fill:fill items to place those. Then you run it again with a new (initially empty) matrix of "occupied" bits with the grid-fill:none items. So it's basically two independent grids as far as placement is concerned. I'd like to hear why fantasai explicitly excluded auto-placed pseudos first though...

[MatsPalmgren]

@fantasai

::grid-area() arguments can also use nth-child syntax in place of <integer>.

So each n in ::grid-area(n/n/n/n) is an independently resolved variable?
We probably want some clamping/limits on this to avoid creating O(n^4) pseudos... ;-)

[rachelandrew]

"That seems like a big mistake to me. I think most use cases would be better served if decorative pseudos don't mess with the grid layout at all. I think this should be optional, and the default should be that ::grid-area pseudos don't take up space in the grid (i.e. regular grid items are "placed on top" of the decorative items)."

Agreeing with this thought. If we think it is useful for them optionally to take up space, then that would be a nice addition, but I feel the default should be purely decorative. I think that's what people will expect.

[MatsPalmgren]

I think the most important part of this new pseudo is to be able to conveniently address the actual grid areas in a grid layout. To do that we need a way to address the implicit grid rather than the explicit grid. I think this is crucial for decorative items, because implicit tracks (typically rows) are prevalent on the web. This suggests to me that we should probably solve #2402 before designing this feature. (Granted, the nth syntax covers some of that need, but I think authors still need a way to address the first and last lines of the implicit grid.)

[kitgrose]

I think the ::grid-area pseudo-element syntax feels natural to me, with the parameter for an area name or grid offsets being optional, and I agree with the others above that those pseudo-elements should be painted underneath any content in a grid.

That seems like it should allow authors to trivially create a grid and fill all its cells with placeholder fills, corner radii, hover states, etc. to allow selection of a grid cell interactively without having to manually create placeholder elements to fill each cell, with more specific styles for named areas or specific cells if so chosen.