Repository navigation
[css-grid] Default Grid Columns, Rows, and Areas #4002
Description
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-startgrid-row-endgrid-column-startgrid-column-endgrid-rowgrid-columngrid-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.
I originally posted this on WICG discourse but I am migrating this to the CSSWG repo per the expert advice of @rachelandrew (thanks Rachel!)
Activity
Loirooriol commentedon Jun 5, 2019
Would
:wherefix your specificity problem?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 commentedon Jun 5, 2019
:wherewould fix the specificity issue. I had considered proposing an!unimportantflag for parity with!important, but:whereis 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
from behaving the same as
I have a gut feeling that adding the default variants for grid placement might be faster to specify and implement than the more abstract
:wherepseudo-class and::textpseudo-element. But this is just a hunch.Any of the grid-placement properties that have a value of
autowould fall back to the default value specified on their grid (or subgrid) container. Default values for all of the properties would beauto.