A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Default Grid Columns, Rows, and Areas

zzzzbov
2019-03-06

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.

zzzzbov
2019-06-04

I have moved this discussion to the CSSWG repo. Any replies should be posted there.