v157 · css · scroll snap · compatibility
clip vs hidden migration
The behaviour change rides entirely on the difference between overflow: hidden and overflow: clip. hidden is still a two-axis scroll container (you can scroll it from script), so it keeps trapping snap areas — by design, forever. clip is a pure clip, and once single-axis containers are active it propagates the unscrollable axis instead. If you were relying on the trap, the migration is one keyword: hidden, or a per-axis scroll-snap-align: … none.
Computed-value inspector
Each row declares an overflow pair on a fresh element and reads back getComputedStyle(). Pre-single-axis engines coerce a scrollable value paired with clip into hidden — the exact coercion this feature family removes.
| declared | computed overflow-x | computed overflow-y | verdict |
|---|
Side-by-side trap test
Identical rigs: an outer y mandatory scroller around a horizontal lane whose cards declare scroll-snap-align: start. Left lane uses overflow-y: clip, right lane overflow-y: hidden. The measured check nudges each outer scroller 37px past the lane and reports whether it re-snaps to the cards’ edge.
overflow-x: auto; overflow-y: clip
the migration in one block
/* You had this, and relied on the cards NOT snapping the outer feed: */
.lane { overflow-x: auto; overflow-y: clip; }
.card { scroll-snap-align: start; }
/* After Chrome 157, pick ONE: */
.lane { overflow-y: hidden; } /* stay a 2D container — traps forever */
.card { scroll-snap-align: start none; } /* keep clip, opt the y axis out */The explainer calls the trapped configuration “generally not quite correct to begin with” — an alignment declared on an axis the lane cannot scroll was almost never intentional. The opt-out syntax already parses today (), so you can ship it ahead of the behaviour change.