skip to content

In a CSS Grid, why can `align-content: center` make part of the content permanently unreachable, and what does the `safe` keyword change?

level: seniorimportance: nice to knowfreq 28%

answer

  1. negative free space is still split evenly
  2. scroll containers cannot scroll backwards
  3. the spec calls it data loss
  4. one keyword in front of center
  5. looks fine until the window shrinks

basics

~20 s

Centering splits any overflow evenly on both sides, and overflow past the start edge of a scroll container cannot be scrolled to, so that part is lost. align-content: safe center tells the browser to fall back to start alignment whenever the tracks overflow, keeping everything reachable.

solid answer

~50 s

Centering distributes free space evenly, and when the free space is *negative* — the tracks are taller than the container — that means the overflow spills equally past both edges. A scroll container can only scroll toward its end edge, so whatever spills past the block-start edge is unreachable: no scrollbar position will ever reveal it. The Box Alignment spec calls this data loss, and gives you an overflow modifier: `align-content: safe center` centers normally, but the moment the content overflows the alignment container the browser behaves as if you had written `start`, so the top stays reachable. `unsafe center` is the explicit opt-out that honours centering regardless, which is also what a bare `center` does. As of 2026 the modifiers are supported in current Chrome, Firefox and Safari, but they landed later than the core alignment properties, so check them against your support matrix.

code

css · 10 lines
css
.dialog-viewport {
  display: grid;
  max-height: 100vh;
  overflow: auto;

  /* fallback for engines without the overflow modifiers */
  align-content: start;
  /* centers when it fits, top-aligns when the content overflows */
  align-content: safe center;
}

go deeper

for a junior

Know that centering a container's content can push part of it off the top where scrolling cannot reach, and that this is a real failure mode rather than a browser quirk.

for a middle

Explain the mechanism: centering splits negative free space evenly, and a scroll container's scrollable region does not extend before its start edge, so the start-side overhang is lost.

for a senior

Show the production instinct — flag centered scroll containers and max-height boxes in review, reach for safe center, and reject transform or negative-margin workarounds that do not restore scrollability.

for a principal

Make it systemic: bake safe alignment into the dialog and page-shell primitives, and add small-viewport and long-content cases to the visual regression matrix so the failure is caught before users hit it.

## What centering does with negative free space Content alignment distributes the free space between the grid's tracks and the container's content box. `center` splits it evenly. Nothing in that definition requires the free space to be positive: if the row tracks total 900px inside a 400px-tall container, the free space is −500px, and centering splits it into −250px on each side. The track group now overhangs the container by 250px at the top and 250px at the bottom. ## Why the start-side overhang is unrecoverable A scroll container's scrollable overflow region extends toward its end edges, not before its start edges. Content laid out past the block-start (or inline-start) edge sits outside the region you can scroll into, so it is clipped with no way to bring it back — the scrollbar is already at position zero when the content begins above the viewport of that box. The end-side overhang is fine; you scroll down and see it. That asymmetry is what makes centering risky and start alignment safe. The same trap exists with `justify-content: center` on the inline axis, and it bites hardest in right-to-left contexts and in horizontally scrolling galleries, where the "start" edge is not where people expect. ## The overflow alignment modifiers CSS Box Alignment defines two keywords that can precede a positional alignment value: ```css .viewport { display: grid; overflow: auto; align-content: safe center; /* center, but degrade to start on overflow */ justify-content: unsafe center; /* always center, overflow be damned */ } ``` - **`safe`** — if the alignment subject overflows the alignment container, the alignment mode is treated as `start` instead. - **`unsafe`** — the requested alignment is honoured no matter the relative sizes. With no modifier, browsers honour the requested alignment, i.e. you get the unsafe behaviour. That default is deliberate for compatibility, which is why the failure mode is so easy to ship: everything looks perfect until content grows or the viewport shrinks. The modifiers apply to the self and items properties too — `align-items: safe center`, `align-self: safe center` — so you can protect a single overflow-prone item inside its area rather than the whole track group. ## Where this actually shows up Three recurring cases: 1. A modal or dialog body centered in the viewport with `place-content: center`. On a short window (a laptop in landscape, or a phone with the keyboard open) the top of the dialog — usually the title and the close button — goes above the scroll origin and cannot be reached. 2. A full-page "empty state" or login card centered with `min-height: 100vh; place-content: center`. Add long validation error text and the top of the card disappears. 3. A horizontally scrolling row of cards centered with `justify-content: center` so it looks nice when there are three cards. With ten, the first card is unreachable in the scroll direction. ## Fixes, in order of preference **Use the modifier**: `align-content: safe center` expresses the intent exactly — center when it fits, top-align when it does not — in one declaration. **Avoid centering the overflow axis**: if the container scrolls, `start` alignment on that axis is never wrong, and you can center the *inner* content instead when it is smaller than the box. **Do not reach for negative margins or transforms** to "pull it back": they move the painted box without changing the scrollable region, so the content stays unreachable and you have added a second bug. Because the failure is invisible at comfortable sizes, treat it as a review checklist item rather than something QA will catch: any `center` on a container that scrolls, or that has a `max-height`, deserves a look at whether it should be `safe center`. ## Version and support caveat The `safe` and `unsafe` keywords are part of CSS Box Alignment Level 3 and are supported in current Chrome, Firefox and Safari as of 2026, but they shipped considerably later than `align-content`/`justify-content` themselves and later than Grid. If you must support older engines, an unrecognised `safe center` makes the whole declaration invalid at parse time, so put a plain fallback first and let the cascade pick the better one where it is understood: ```css .viewport { align-content: start; } .viewport { align-content: safe center; } ```

  • Why does the end-side overflow not cause the same problem as the start-side overflow?
    Because the scrollable overflow region extends toward the container's end edges. Content past the block-end edge is inside that region, so scrolling down reveals it. Content laid out before the block-start edge is outside it — the scroll position is already at zero there — so no amount of scrolling brings it back. Centering creates both, and only one is recoverable.
  • What does `unsafe center` mean, given that a bare `center` already overflows?
    It states the intent explicitly. A bare `center` behaves unsafely today, but `unsafe center` documents that the overflow is deliberate — for example a decorative element you genuinely want bleeding past both edges — and guards against a future change of the default or a linting rule that flags unqualified centering on scroll containers.
  • Can you get the same protection without the safe keyword?
    Approximately. Align to `start` on the scrolling axis and center the content only while it fits — for instance by centering an inner wrapper whose size is content-based, or by switching alignment inside a media or container query. It is more code and more places to get wrong, which is exactly the case the `safe` modifier was added to remove.

saying these in an interview costs you the question

  • Says overflow is always reachable by scrolling
  • Blames the browser or the scrollbar instead of the alignment
  • Reaches for negative margins or transforms to recover the content
  • Thinks center only splits space when the space is positive
  • Assumes safe is the default behaviour for center

context

resolving links…