CSS Grid: Named Lines and Areas for Readable Layouts

1. Why Named Structures Produce More Readable CSS

CSS Grid numbers lines automatically, starting at 1 at the left or top edge. An element with grid-column: 2 / 4 can be positioned precisely this way, yet nobody can tell from that line whether it is the main column, a sidebar or a header. Named grid lines and grid-template-areas solve exactly this comprehension problem by giving the grid itself semantic labels that immediately explain, right in the stylesheet, which region is meant.

The difference is especially noticeable in teams with multiple developers. Numeric lines require every contributor to mentally reconstruct the entire layout, or check it in the browser, to safely judge a change. Named grid lines and named areas make that same information visible directly in the code, which speeds up reviews and noticeably reduces mistakes when changing layouts. This article demonstrates both techniques on two realistic examples: a dashboard and a form.

2. Syntax for Named Grid Lines

Named lines are defined directly inside grid-template-columns or grid-template-rows in square brackets, right before the track size they refer to. A line can carry several names at once, separated by spaces, for example [main-end aside-start] for the line where the main area ends and the side column begins. Elements then reference these names through grid-column or grid-row instead of numbers.

What matters with named grid lines is that the name itself has no meaning for the grid algorithm, it is pure documentation for humans. Still, a consistent naming convention across the whole project pays off, for example always using -start and -end as suffixes, so everyone on the team shares the same expectation about what a name means. Without that convention, named lines quickly lose their clarity again.

/* Named lines defined directly inside the track list */
.dashboard {
  display: grid;
  grid-template-columns:
    [sidebar-start] 240px
    [sidebar-end content-start] 1fr
    [content-end];
  grid-template-rows:
    [header-start] 64px
    [header-end body-start] 1fr
    [body-end];
}

.widget {
  grid-column: content-start / content-end;
  grid-row: body-start / body-end;
}

3. grid-template-areas: Dots and ASCII Art as Documentation

grid-template-areas goes a step further than named lines: instead of individual boundaries, the entire grid surface is described as a text pattern, in which each area name is repeated exactly as many times as it occupies cells. A dot . marks an empty cell with no assigned element. This text pattern works like ASCII art: anyone reading the source code sees the visual arrangement of the layout without needing to render a single line in the browser.

For grid-template-areas to stay valid, every area name must form a contiguous rectangle, L-shaped or interrupted forms are not allowed and lead to a parser error the browser silently ignores. This restriction is rarely a problem in practice, since most layout regions are rectangular anyway, but it does force developers to deliberately solve more complex shapes with named lines instead of areas.

/* grid-template-areas as readable ASCII art */
.dashboard {
  display: grid;
  grid-template-areas:
    "sidebar header  header"
    "sidebar stats   activity"
    "sidebar stats   ."; /* the dot marks an empty cell */
  grid-template-columns: 240px 1fr 1fr;
  grid-template-rows: 64px auto auto;
  gap: 1.5rem;
}

.sidebar  { grid-area: sidebar; }
.header   { grid-area: header; }
.stats    { grid-area: stats; }
.activity { grid-area: activity; }

4. Practical Example: A Dashboard With Named Areas

An admin dashboard with a sidebar, a header, stat tiles and an activity feed is a typical use case for grid-template-areas. Instead of computing a separate numeric position for every widget, you describe the entire dashboard as a single text pattern, and every widget only references its own name. If the arrangement changes later, for example because the activity feed should become wider, adjusting the pattern is enough, without touching a single HTML element.

The advantage over named lines alone shows most clearly with irregular grids: a widget spanning two rows and two columns is simply represented in grid-template-areas by repeating its name multiple times in the pattern, while the same structure with pure line indexes would need noticeably more lines of CSS and be harder to keep track of.

5. Practical Example: A Form Layout With Named Lines

Forms with a label and an input field side by side benefit more from named grid lines than from areas, because every form row essentially repeats the same two column pattern, just with different content. A column structure with the lines [label-start], [label-end input-start] and [input-end] establishes once where labels end and input fields begin, and every form row afterward only references these names.

This technique pays off especially when a form should look consistent across multiple components. Instead of guessing the label column's pixel width anew in each component, all form rows reference the same named lines from a shared grid container, which makes the entire form appear visually cohesive.

/* Form layout using named lines for label/input pairs */
.form {
  display: grid;
  grid-template-columns:
    [label-start] minmax(120px, 200px)
    [label-end input-start] 1fr
    [input-end];
  row-gap: 1rem;
  column-gap: 1.5rem;
}

.form-row {
  display: grid;
  grid-template-columns: subgrid; /* inherit the parent's named columns */
  grid-column: label-start / input-end;
}

.form-row label { grid-column: label-start / label-end; }
.form-row input { grid-column: input-start / input-end; }

6. repeat() With Automatically Repeated Line Names

Once a grid consists of many similar columns, for example a card list with twelve identical columns, manually naming every single line becomes impractical. repeat() supports named lines directly: repeat(12, [col-start] 1fr) creates twelve columns where every start line carries the same name, col-start. Since multiple lines may carry the same name, grid-column: col-start 3 specifically references the third line with that name.

This combination of repeat() and named grid lines is especially useful for systems with a fixed column grid, similar to what is known from Bootstrap or other grid frameworks, but it can be implemented natively in CSS without generating extra classes for every possible column position.

/* repeat() with a repeated named line for a twelve column system */
.grid-system {
  display: grid;
  grid-template-columns: repeat(12, [col-start] 1fr);
  gap: 1rem;
}

.card-wide {
  grid-column: col-start 1 / col-start 5; /* spans columns 1 to 4 */
}

.card-narrow {
  grid-column: col-start 5 / col-start 9; /* spans columns 5 to 8 */
}

7. Combining Negative Line Indexes and span

Besides positive lines counted from 1, CSS Grid also supports negative indexes that count from the opposite end of the explicit grid, with minus 1 always denoting the last line. Combined with named grid lines, this reliably stretches an element to the end of the grid without knowing the exact number of columns ahead of time: grid-column: content-start / -1 reaches from the named start to the last column, regardless of how many columns the grid has in total.

span complements named lines with relative positioning: grid-column: sidebar-end / span 2 starts at the named line and extends across two additional tracks, regardless of where the next named line actually sits. This flexibility makes named lines usable for dynamic layouts as well, where the exact column count is only known at runtime.

8. Redefining Areas per Breakpoint

The biggest practical advantage of grid-template-areas shows up in responsive layouts: a media query simply defines a new text pattern for a breakpoint, while every element continues to reference only its area name via grid-area. Not a single rule on the child elements needs to change even when the visual arrangement changes completely, for example when the sidebar should appear below rather than beside the main content on narrow screens.

This decoupling between structure definition on the container and assignment on the child elements is the core of what makes grid-template-areas so maintainable. A layout refactor often reduces to rewriting a single ASCII pattern, while the rest of the project's code stays unchanged.

9. Named Areas, Named Lines and Subgrid Compared

All three techniques solve different facets of the same underlying problem: making numeric grid positions readable and maintainable. The following table shows which technique fits which situation best.

In practice, well structured projects combine all three techniques: grid-template-areas for the rough page structure, named lines for recurring patterns such as forms, and subgrid for the fine alignment of nested components. None of the three techniques fully replaces the others, they complement each other depending on the use case.

10. Summary

Named grid lines and grid-template-areas solve the same underlying problem from two different angles: replacing numeric position references with self documenting labels. Named lines suit recurring patterns such as forms and column systems especially well, while grid-template-areas, with its ASCII art approach, describes irregular grids like dashboards most clearly. Both techniques combine with repeat(), negative line indexes and span to produce layout definitions that stay flexible yet readable.

The biggest practical payoff shows up in responsive layouts and in teams: a media query that only redefines the text pattern of grid-template-areas is understandable at a glance, with no need to touch child elements. Anyone who consistently relies on named structures instead of numeric lines in a project noticeably reduces both onboarding time for new developers and the error rate during later layout changes.

11. FAQ: Named Grid Lines and Areas