store: cart summary total overflows the viewport at a 24px root font (WCAG 1.4.10) #93

New issue

Closed

opened 2026-09-06 12:34:43 +00:00 by yuris · 0 comments

yuris commented

2026-09-06 12:34:43 +00:00

Owner

Found while verifying #91 across root font sizes. Pre-existing on main, and confirmed not caused by that PR: neutralising its cart-line rules leaves the overflow in place, and no element inside .co-line overflows at all.

Symptom

At a 24px root font (Chrome's largest built-in setting, roughly 400% zoom territory) on a 320px viewport, /cart scrolls horizontally.

The single offender

Exactly one element overflows the document:


element	`span.price` in the summary panel
text	`Rp 13.070.000`
rendered width	261px
right edge	353px against a `clientWidth` of 320px
`documentElement.scrollWidth`	353

It is the order total, not a cart line. .summary .price renders large and bold, and at a 24px root a 13-million total simply exceeds the panel's content box.

Why it matters

WCAG 1.4.10 Reflow asks for no two-dimensional scrolling at a 320px-equivalent width. A user at 400% zoom on a narrow phone gets exactly that, on the screen where they confirm what they are about to pay.

Scope note

This is the summary panel, so it is independent of the cart-line work in #91 and of the sticky-bar occlusion in #89. It reproduces on main.

Suggested direction

The total is the one string on the page guaranteed to be both large and long. Options, cheapest first:

Let it wrap: it has a space after Rp, so overflow-wrap or simply allowing two lines in the total row would resolve it without changing type size.
Clamp the total's type size with min() or a small @media (max-width: 390px) step, the way .sticky-buy .sb-price .price already steps down.

Deriving the behaviour from the string's own length is better than a fixed breakpoint, since the digit count is what varies.

Verification for whoever takes it

Set the root font to 24px at a 320px viewport on /cart with a total in the tens of millions, then assert document.documentElement.scrollWidth === document.documentElement.clientWidth. It fails today at 353 vs 320.

Sharpened after a 1px sweep by a second reviewer. The extent is two bands of different character, not two points, and the onset depends on the cart total — so a reproduction needs the total stated.

Two bands, only one of which fails the criterion

band	widths	worst overflow	what it is
320–352	33	33px	the substantive failure: the stacked summary's content box is 256px against a 261.14px string
901–1120	220	1px	rounding-level: the sticky summary's content box is 272px against the same 261.14px. Clears at 1121 when the summary widens 320 → 400px

Clean from 353–900, because the stacked summary has the full width.

Only the first band matters for WCAG 1.4.10, which tests at 320 CSS px. The second is the same element with a 1px symptom — naming it separately so nobody spends a day on it thinking it is the 33px one.

It needs both a large total and a large root

Rp 13.070.000 measures 174.09px at a 16px root and 217.67px at 20px — neither overflows. It takes roughly a 24px root to reach 261.14px.

And the onset width scales with the total: with a four-item seed totalling Rp 2.630.000 (238.56px) the band shrinks to 320–329. So this should not be filed as a fixed-320px bug.

Reproduction

Seed a cart whose total is in the tens of millions, set the root font to 24px, and set the viewport to 320px. Then:

document.documentElement.scrollWidth === document.documentElement.clientWidth

fails at 353 vs 320, with span.price in .summary as the single overflowing element.

Found while verifying #91 across root font sizes. Pre-existing on `main`, and confirmed not caused by that PR: neutralising its cart-line rules leaves the overflow in place, and no element inside `.co-line` overflows at all. ## Symptom At a 24px root font (Chrome's largest built-in setting, roughly 400% zoom territory) on a 320px viewport, `/cart` scrolls horizontally. ## The single offender Exactly one element overflows the document: | | | |---|---| | element | `span.price` in the summary panel | | text | `Rp 13.070.000` | | rendered width | **261px** | | right edge | 353px against a `clientWidth` of 320px | | `documentElement.scrollWidth` | 353 | It is the order total, not a cart line. `.summary .price` renders large and bold, and at a 24px root a 13-million total simply exceeds the panel's content box. ## Why it matters WCAG 1.4.10 Reflow asks for no two-dimensional scrolling at a 320px-equivalent width. A user at 400% zoom on a narrow phone gets exactly that, on the screen where they confirm what they are about to pay. ## Scope note This is the summary panel, so it is independent of the cart-line work in #91 and of the sticky-bar occlusion in #89. It reproduces on `main`. ## Suggested direction The total is the one string on the page guaranteed to be both large and long. Options, cheapest first: - Let it wrap: it has a space after `Rp`, so `overflow-wrap` or simply allowing two lines in the total row would resolve it without changing type size. - Clamp the total's type size with `min()` or a small `@media (max-width: 390px)` step, the way `.sticky-buy .sb-price .price` already steps down. Deriving the behaviour from the string's own length is better than a fixed breakpoint, since the digit count is what varies. ## Verification for whoever takes it Set the root font to 24px at a 320px viewport on `/cart` with a total in the tens of millions, then assert `document.documentElement.scrollWidth === document.documentElement.clientWidth`. It fails today at 353 vs 320. --- Sharpened after a 1px sweep by a second reviewer. The extent is **two bands of different character**, not two points, and the onset depends on the cart total — so a reproduction needs the total stated. ## Two bands, only one of which fails the criterion | band | widths | worst overflow | what it is | |---|---|---|---| | **320–352** | 33 | **33px** | the substantive failure: the stacked summary's content box is 256px against a 261.14px string | | 901–1120 | 220 | **1px** | rounding-level: the sticky summary's content box is 272px against the same 261.14px. Clears at 1121 when the summary widens 320 → 400px | Clean from 353–900, because the stacked summary has the full width. **Only the first band matters for WCAG 1.4.10**, which tests at 320 CSS px. The second is the same element with a 1px symptom — naming it separately so nobody spends a day on it thinking it is the 33px one. ## It needs both a large total and a large root `Rp 13.070.000` measures 174.09px at a 16px root and 217.67px at 20px — neither overflows. It takes roughly a 24px root to reach 261.14px. And the onset width scales with the total: with a four-item seed totalling `Rp 2.630.000` (238.56px) the band shrinks to **320–329**. So this should not be filed as a fixed-320px bug. ## Reproduction Seed a cart whose total is in the tens of millions, set the root font to 24px, and set the viewport to 320px. Then: ```js document.documentElement.scrollWidth === document.documentElement.clientWidth ``` fails at 353 vs 320, with `span.price` in `.summary` as the single overflowing element.

yuris referenced this issue from a commit

2026-09-28 20:50:38 +00:00

fix(store): prevent cart summary total overflow at 24px root font (#93)

yuris referenced this issue from a pull request that will close it,

2026-09-28 20:50:42 +00:00

fix(store): prevent cart summary total overflow at 24px root font #120

yuris closed this issue

2026-09-28 20:51:06 +00:00

yuris referenced this issue from a commit

2026-09-28 20:51:07 +00:00

fix(store): prevent cart summary total overflow at 24px root font (#93) (#120)