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