Notes on CSS Grid Layout

In preparation of the Grid Layout Workshop in Amsterdam this Friday, I read the grid spec. I highly recommend doing this.

This specification is a great read, even for those not familiar with reading CSS specs. It first introduces all the concepts with comprehensible examples, and then dives into the syntax in more detail (including diagrams that show exactly which properties can be used how, available shorthand syntaxes and the algorithms used to decide about sizing and alignment).

Why?

“We already have many clever combinations of HTML, CSS and JavaScript to do layout”, I hear you think, “so what do we need Grid Layout for?” All layout mechanisms we have used to date come with specific problems. Floats need clearing, inline-block grid elements need comments to remove spaces and make widths work, and tables misused an HTML element for layout. CSS Grid Layout addresses our layouting problems, and lets us ‘divide available space for layout into columns and rows using a set of predictable sizing behaviors’. Yeah!

New terminology

The grid spec introduces a number of new terms. A grid is a set of lines that divides the grid container. Within the grid container, columns or rows exist between the lines. Columns and rows can both be referred to as grid tracks. On the grid, each cell is called a grid cell. One or more cells can form a grid area, which can be occupied by grid items.

I found it a bit confusing at first to see the difference between grid areas and grid items, but as I understand it, grid items are the bits of content that authors can specify to live in a specific grid area.

More alignment options

Some of the best new CSS properties that were introduced in flexbox, also work on grid containers (justify-items, align-items), grid items: (justify-self, align-self) and the grid itself (justify-content, align-content).

Naming lines and areas

With grid-template-columns and grid-template-rows you can not only specify how much space each grid cell takes up, you can also give the lines surrounding them names. So for a 3 column layout with a width of 25%, 50% and 25% respectively, you do something like:

grid-template-columns: 25% 50% 25%

And if you want to lines surrounding the 50% area, you do:

grid-template-columns: 25% [start-main-area] 50% [end-main-area] 25%

so that you can set a specific bit of content to live in the 50% area between ‘start-main-area’ and ‘end-main-area’.

You can also define names for the areas themselves, using the ASCII art method (if a word appears multiple times, it means it spans multiple columns/rows):

grid-template-areas: "header header header"
                     "main main sidebar";

so that you can set a specific bit of content to live in the ‘header’, ‘main’ area or ‘sidebar’.

fr

The fr unit can be used to define flexible lengths and represents a fraction of the free space in the grid container. I think this is how it relates to auto: if all lengths are set auto, that would be equivalent to them all having 1fr, but if they have different amounts of fr, the fr unit gives more control as they can give some grid tracks more space than others.

Changing visual order

The grid spec frequently talks about the order keyword, which lets you visually change the order of your document (this property also exists in flexbox).

This makes that there are now two different orders to keep in mind:

document order / source order (this is what you see when you view source)
order-modified document order (this is the document order with all the ‘order’ properties in your stylesheet(s) taken into account)

Browsers are supposed to paint in the order-modified document order (this is also good to know for if you’re setting z-index).

The spec emphasises that order will only change your visual order, and not update speech order (for people that have your page read out to them) or navigation order (for people that use keyboards to navigate). Therefore it is important that the source order is sensible (this is an important accessibility concern).

Auto

Lots of things within grids can happen automatically. This is a bit complex to get your head around, but it is rather exciting (if you have not seen it, I can recommend fantasai’s CSS Day talk on defining auto). The good news is: to use grids, you do not need to know how the auto algorithms work, they just do.

With grid properties, you can set your grid exactly how you want it to be (‘explicit grid’). If you forget something or position an element outside of the bounds of your grid, the grid algorithm will create ‘implicit’ grid tracks.

Grids in grids

Grid items can be grids themselves (they are then ‘subgrids’), but this is still being discussed by the CSS Working Group. With display: subgrid, the subgrid would be able to inherit the cols/rows of its parent.

Thoughts

This is exciting! I really look forward to using CSS grids in my daily work.

I do think the transition to actually using the new properties for page layout will come with some problems, especially around giving grid areas names that can be shared across everyone working on the same site, and letting grid areas be occupied by components (as component libraries are the deliverable of many front-end developers these days).

And if that all works, should we give content managers controls to set content to flow in specific columns (perhaps the CMS would show a representation of the grid on various different viewports?).