Some experiments with CSS-grid.
See _o-g--example-curo.scss for good example / walkthough
The grid names we pick can be unique to each project, or shared, or expanded as needed. Maybe closely aligned to the areas in a wireframe mockup. So we could make a wireframey responsive mockup to test/show/explore how things collapse down to smaller device screen sizes.
.o-g--curo {
// Prevent IE11 from trying to implement it's ancient version of grid
@supports (display: grid) {
display: grid;
}
height: 100%;
grid-template-columns: auto;
grid-gap: 0;
Then we list all the base names of the sub-items of the grid that we’re arranging (works well for hooking to floating for fallbacks)
If we have wireframes or a reasonable design of most of the content - we can make a list of all the names of content items, and generalise them - makes it easier to visualise what the content is. Where there might be more than one body content, or media, we can still denote with media2, media3 or something else appropriate. This list was based on Curo designs:
- hero
- header
- caption
- actions
- intro
- media
- caption
- gallery
- caption
- spacer
- media
- social
- band
- intro
- feed
- roomhire
- header
- body
- media
- actions
- roomhire
- header
- body
- media
- actions
- roomdetails
- body
- whatson
- band
- body
- cafe
- band
- body
- media
- location
- band
- body
- team
- band
- body
The element name is the same as the grid area:
// Predefine all the grid area names - generic container-purpose
// Would be harder to keep track of gridcell1 gc2, gc3, gc4 - but is more generic...
.o-g__actions {
grid-area: actions;
}
.o-g__band {
grid-area: band;
// Because all bands in Curo will be light on dark...
background-color: #444444;
color: #ffffff;
}
.o-g__body {
grid-area: body;
}
.o-g__caption {
grid-area: caption;
}
.o-g__head {
grid-area: head;
}
.o-g__intro {
grid-area: intro;
}
.o-g__media {
grid-area: media;
}
.o-g__spacer {
grid-area: spacer;
}
And then we layout the grids with CSS-grid. Note we don’t want to add non-grid elements in here - that way we can do fallbacks per-grid.
.o-g--intro {
grid-template-areas:
"... ..."
"media ..."
"caption caption"
"caption caption";
grid-template-columns: 1fr 30px;
grid-template-rows: 30px 2fr 1fr 1fr;
@include media(screen, ">medium") {
grid-template-columns: 5fr 2fr 2fr 1fr;
grid-template-rows: 80px 1fr 2fr 2fr;
// Where grid cells overlap, we can still specify tracks
.o-g__caption {
grid-column: 2 / 4;
grid-row: 3 / -1;
}
.o-g__media {
grid-column: 1 / 3;
grid-row: 2 / -1;
}
}
}
o-g__element is the sub-item of the grid. Even if we use a grid inside grid, there won’t be a conflict as we’re setting (or re-setting) the layout in the o-g--variant everytime.
<div class="o-g o-g--curo o-g--intro">
<div class="o-g__media">
<picture class="c-picture">
<img src="https://pic.jcmserv3.net/640x16:9/cc8800/c77e00.png&text=IMG" alt="" />
</picture>
</div>
<div class="o-g__caption">
<p>Body content</p>
</div>
</div>
The components can then live inside or part of the grid - important we don’t overlap grid properties with component ones (eg, padding defined in each). Here we’ve moved c-picture as part of the grid object - as object and components can live together without conflicts (most of the time).
<div class="o-g o-g--curo o-g--intro">
<picture class="o-g__media c-picture">
<img src="https://pic.jcmserv3.net/640x16:9/cc8800/c77e00.png&text=IMG" alt="" />
</picture>
<div class="o-g__caption">
<p>Body content</p>
</div>
</div>