, which pulls a word down to avoid a short last line. Turned back off here, and the reason is NOT the one that used to be written in this spot — that claim was that `pretty` changes the paragraph's height, and it does not. Measured both ways: 1440 wrap 3 lines h72 · pretty 3 lines h72 footer 1239.50 both 414 wrap 7 lines h154 · pretty 7 lines h154 footer 2015.25 both Height is identical. What changes is where the lines BREAK, and that is what actually matters, because the reference does no balancing and we are judged against it side by side. Line widths of the AFSL paragraph at 1440: reference 1194.09 1205.56 51.45 ours, wrap 1194.09 1205.56 51.45 <- exact, all three ours, pretty 1194.09 1185.20 71.81 <- lines 2 and 3 differ `pretty` pulls one word off line 2, so two of the three lines set differently from the reference. The cost of keeping `wrap` is a real one-word widow — the last line is 51.45px against a 1252.31px measure at 1440, and 45.44 against 381.75 at 414. That is fidelity chosen over craft, deliberately and in the one place it is the right trade. If the reference constraint is ever lifted, this is the first thing to turn back on: it costs nothing in layout and only improves the rag. */ text-wrap: wrap; } /* ========================================================================== 8. BREAKPOINTS All measured. Kept together so the steps are readable as one ladder. ========================================================================== */ /* The one place the footer changes shape below the phone breakpoint: at 320 and narrower the reference tightens the heading-to-list gap by 4px. Measured flat at 12px from 280 to 320 and flat at u/3 + 8 from 321 up. Worth having — it is 16px of height across the four stacked groups on the smallest screen anyone still ships. */ @media (max-width: 320px) { .br-footer__group { gap: calc(var(--br-flow-3xs) + var(--br-space-1)); } } @media (min-width: 576px) { .br-footer { --br-footer-gutter: var(--br-flow-md); } /* 4u/3 */ } @media (min-width: 768px) { .br-footer { --br-footer-gutter: var(--br-section-y); } /* 2u */ /* Stack → columns. `gap` no longer applies once this is a block box, so the rhythm between groups moves onto the group's own margin — which is also what lets a column end cleanly instead of carrying a trailing gap. */ .br-footer__primary { display: block; column-count: 2; column-gap: var(--br-section-y); } .br-footer__group { margin-bottom: var(--br-section-y); } .br-footer__secondary-list { display: grid; grid-template-columns: repeat(2, minmax(0, 1fr)); column-gap: var(--br-section-y); } .br-footer__marks { flex-direction: row; justify-content: space-between; align-items: flex-start; } } @media (min-width: 1200px) { .br-footer { --br-footer-gutter: calc(var(--br-u) * 10 / 3); } /* 93.85 @1440 */ .br-footer__primary { column-count: 3; } .br-footer__secondary-list { grid-template-columns: repeat(3, minmax(0, 1fr)); } } /* The reference's own fourth column appears somewhere in 1635–1639 — past the point where the content has already hit its 1440 cap, so nothing else moves across that band and the exact pixel is unobservable. Pinned at 1640. ONE DELIBERATE DIVERGENCE, and it lives entirely above 1640. Measured at 1920, our column block is 329px tall and the reference's is 349.328px, so the hairline and everything under it sits 20.328px higher in ours. Every declared input is identical: groups 320 / 320 / 228 / 208 both group x 240 / 615 / 990 / 1365 both group width 315 both margin-bottom 60 break-inside avoid both column-count 4 column-gap 60 both padding 0, border 0, no extra children both Our 329 is not an accident of ours either: 320+320+228+208 plus four 60px margins is 1316, and 1316 / 4 columns is 329.000 exactly — the balancer's ideal height. The reference's 349.328 is 20.328 above that, from the same inputs. It is stable in their tree (unchanged after a forced relayout, a detach/reattach, and across fractional block offsets), so it is Chrome balancing differently inside their box, not a value either of us wrote. Five constructions were tried at 1920 to reproduce their number: multicol, as shipped 329.000 padding-bottom instead of margin 380.000 break-inside: auto 329.000 column-fill: auto 1316.000 group as a block rather than flex 311.000 grid, 4 x minmax(0,1fr), margin 0 320.000 reference 349.328 None of them lands on it. So this is a choice, made and recorded: we keep 329. It is the mathematically balanced height, it is one pixel off 11u (330) where theirs is 11.64u, and it is deterministic in our tree. The grid alternative would pin the height to the tallest group and never vary by engine, but at 320 it is FURTHER from the reference than the multicol is, and it hard-codes one-group-per-column placement that breaks the moment a fifth group is added — so it was rejected on both counts. Cost of the choice, re-measured against the reference: the hairline, the policy links and the legal block all sit 19.91px high at 1640 and 20.31px high at 1920. Nowhere else. Everything from 320 to 1600 — including all four judged widths — matches on every anchor to 0.00px: width 320 390 414 768 1024 1200 1440 1600 | 1640 1920 delta 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 | -19.91 -20.31 DO NOT "fix" this by converting the multi-column to a grid. It was tried; it is further from the reference at 320, and it hard-codes one group per column, which breaks the first time a fifth group is added. The trial table above is the record — five alternatives, none reproduces 349.328. */ @media (min-width: 1640px) { .br-footer__primary { column-count: 4; } .br-footer__secondary-list { grid-template-columns: repeat(4, minmax(0, 1fr)); } }