[css-grid] Default Grid Columns, Rows, and Areas

[zzzzBov]

I’ve run into some scenarios where it would be convenient for parent nodes using display: grid to be able to control the grid placement properties of their child grid items.

As a simplified example, the main element of a page might have the following CSS:

main {
  display: grid;
  grid-template-columns: [wide-start] 1fr [normal-start] 500px [normal-end] 1fr [wide-end];
}

Child elements would then have grid-column: normal to be centered on the page. For elements that should stretch full-width, grid-column: wide could then be used:

p {
  grid-column: normal;
}
pre {
  grid-column: wide;
}

If specific elements are used, this will quickly become difficult to maintain as each new element needs to be added to the list:

div,
dl,
ol,
p,
ul,
... {
  grid-column: normal;
}

pre {
  grid-column: wide
}

Clearly this already has a simple solution, use a child selector with a universal selector:

main > * {
  grid-column: normal;
}

pre {
  grid-column: wide;
}

So what’s the problem?

The problem comes up once you start building with large amounts of components. Ideally with component code each component can be kept in isolation from each other, so they can be added and removed as a unit without causing breaking changes elsewhere in a site.

If we instead have an example of:

_Sass

.Page {
  display: grid;
  grid-template-columns: [wide-start] 1fr [normal-start] 500px [normal-end] 1fr [wide-end];

  > * {
    grid-column: normal;
  }
}

...

.Code {
  grid-column: wide;
}

The cascade starts to become a problem for child elements.

If I’ve imported my components in say, alphabetical order:

@import 'Code';
...
@import 'Page';

.Page>* will always override .Code due to the cascade.

Now certainly this example is easily fixed by switching the source order of the two components, but in large-projects with potentially hundreds of components, this becomes harder to see the inter-component dependencies.

With recursively nestable components, it may not even be possible to properly reorder the components without splitting them across multiple files, or increasing specificity:

:root .Code { //blegh
  grid-column: wide;
}

Instead, I think there’s a simple solution to this that already has some precedent in CSS grid:

I think we should introduce separate rules for the grid parent nodes to manage the same functionality so that the defaults can be specified but then the child nodes can override the behavior explicitly.

We’ve already got this with align-self/align-items and justify-self/justify-items.

I think it would be helpful to have something along the lines of grid-column-items, grid-items-column, or default-grid-column (the name doesn’t matter all that much, let’s not bikeshed).

Having a matched property for each of:

• grid-row-start
• grid-row-end
• grid-column-start
• grid-column-end
• grid-row
• grid-column
• grid-area

Would help solve this problem easily:

pre {
  grid-column: normal;
}

main {
  display: grid;
  grid-items-column: normal;
  grid-template-columns: [wide-start] 1fr [normal-start] 500px [normal-end] 1fr [wide-end];
}

Anonymous Grid Item Placement

Introducing default grid placement for child nodes also opens us up to being able to specify placement for anonymous grid items as well.

I was surprised when I found out most of a year ago that plain text nodes have no way of being placed within a grid currently.

Having default grid placement managed from grid parents opens up the ability to place pieces of text without needing to introduce additional, potentially unsemantic, wrapper elements.

---

I originally posted this on WICG discourse but I am migrating this to the CSSWG repo per the expert advice of @rachelandrew (thanks Rachel!)

[Loirooriol]

Would :where fix your specificity problem?

:where(main > *) { /* 0 specificity */
  grid-column: normal;
}

About not being able to style text nodes/runs, #2208 would be a more general solution.

Though your proposal would make it simpler when the grid items are a mix of ::before, ::after, ::text, children elements, descendant elements (via display: contents), etc.

[zzzzBov]

:where would fix the specificity issue. I had considered proposing an !unimportant flag for parity with !important, but :where is clearly superior in a variety of ways, so thank you for sharing that with me.

Your second point still stands that there are a variety of complexities that would prevent

main > * {
  grid-column: normal;
}

from behaving the same as

main {
  default-grid-column: normal;
}

I have a gut feeling that adding the default variants for grid placement might be faster to specify and implement than the more abstract :where pseudo-class and ::text pseudo-element. But this is just a hunch.

Any of the grid-placement properties that have a value of auto would fall back to the default value specified on their grid (or subgrid) container. Default values for all of the properties would be auto.