amadan
Fix what a real browser found in the ruler: two ways it was wrong
Both caught by scripts/browser-drive.sh, neither visible to any test that does not lay out a page. The gate was green through both. THE RULER WAS BESIDE THE PAGE, NOT ABOVE IT. [docs-canvas] is `display: flex; justify-content: center`, which centred the one child it had ever had; a second child laid the two out in a row. The drive measured the ruler at 16..606 and the page at 606..1249 — not a subtle misalignment, two boxes side by side. It is a column with align-items: center now, which is the same result for a lone [docs-page] and the only arrangement in which "above the paper" means above the paper. THE INCH LABELS SCROLLED THE DOCUMENT SIDEWAYS AT 320px. They are absolutely positioned at 1in..6in from the column's left edge; absolute positioning does not size the parent but does extend the scrollable overflow area, so in a narrow viewport they stuck out past the page. scrollWidth 655 against a 320 viewport, with three marks ending at 367, 463 and 559. That is WCAG 2.2 SC 1.4.10, which this app allows no exemption from — and it is the second time this branch has been the one to introduce that failure rather than find it. Two fixes, because one of them is a threshold and the other is an invariant. [docs-ruler] gets `overflow: hidden`, so nothing inside it can ever extend the page's scroll width whatever the width is. And the ruler hides below 54rem, where a full 8.5in sheet no longer fits and the labels would be measuring a page that is not there. The breakpoint did nothing at first, and the drive said so. It sat with the other media queries, two hundred lines above the `display: flex` rule it was overriding, at exactly the same specificity (0,3,0) — so source order decided and the later rule won. The marks were still measured at 390, 486 and 582 on the next run, past a page whose scrollWidth had by then been fixed by the clip. It is immediately after the rule it overrides now, and the comment says why that placement is the fix rather than a tidiness. 58/58 in the browser, including the fourteen new checks: the File menu panel's scrollWidth against its clientWidth (Paul's screenshot), the rename reaching the server rather than only the field, the ruler's alignment and its aria-pressed moving, and find-and-replace opening non-modal, highlighting real matches and closing on Escape.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DoVTH3jZqj9svgt2UD9t1p
1 file changed,
+56
−1
internal/docs/views/show.html+56 −1
CI passed — run details
Intent
Attributed to this commit: 1110 g CO₂e (138007288 tokens). This is an attribution, not a measurement — usage counted from this commit's own marker forward to the next one on docs-finish, never backward from it. A turn that produced more than one commit books all of its tokens to the last one, and a concurrent session on this branch can add to the same figure. Some of it was priced using the shared default rate, because no model-specific factor row exists yet for at least one model involved. The Carbon view has the repo total, which is never derived from this attribution.
diff --git a/internal/docs/views/show.html b/internal/docs/views/show.html| index 7f9d1bf..8269e71 100644 |
| --- a/internal/docs/views/show.html |
| +++ b/internal/docs/views/show.html |
| @@ -264,7 +264,20 @@ |
| [docs-canvas] { |
| color-scheme: light; |
| display: flex; |
| - justify-content: center; |
| + /* A COLUMN, and it was a row until the ruler arrived. |
| + `display: flex; justify-content: center` centred the one child |
| + this ever had. With a second child it laid the ruler and the |
| + page side by side: the browser drive measured the ruler at |
| + 16..606 and the page at 606..1249, which is not a subtle |
| + misalignment, it is two boxes in a row. |
| + flex-direction: column with align-items: center is the same |
| + result for a lone [docs-page] — centred across, stacked down — |
| + and the only arrangement in which a ruler above the paper is |
| + above the paper. justify-content is gone with the row: on a |
| + column it centres VERTICALLY, which is not what any of this |
| + wants. */ |
| + flex-direction: column; |
| + align-items: center; |
| /* Less air above the sheet than below it. The tray used to carry |
| --rst-sp-6 on both block edges and sat under a page header that |
| had already spent --rst-sp-5 of its own below the rule; with the |
| @@ -779,6 +792,22 @@ |
| inset-block-start: 5.5rem; |
| z-index: 2; |
| display: none; |
| + /* NOTHING HERE MAY EXTEND THE PAGE'S SCROLL WIDTH, and this line |
| + is what guarantees it rather than a breakpoint. |
| + The inch labels are absolutely positioned at 1in..6in from the |
| + column's left edge. Absolute positioning does not size the |
| + parent, but it does extend the scrollable overflow area — so in |
| + a viewport narrower than the ruler's own geometry the labels |
| + stick out past the page and the whole document scrolls |
| + sideways. The browser drive measured exactly that: scrollWidth |
| + 655 against a 320 viewport, with three [docs-ruler-mark]s ending |
| + at 367, 463 and 559. That is WCAG 2.2 SC 1.4.10, which this app |
| + allows no exemption from. |
| + The rule below also hides the ruler at narrow widths, which |
| + fixes the same failure — and is not enough on its own, because |
| + it is a threshold and this is an invariant. A clip cannot be |
| + wrong by a breakpoint. */ |
| + overflow: hidden; |
| inline-size: min(100%, 8.5in); |
| margin: 0 auto var(--rst-sp-2); |
| block-size: 20px; |
| @@ -793,6 +822,32 @@ |
| [docs-canvas][data-ruler="on"] [docs-ruler] { |
| display: flex; |
| } |
| + /* The ruler needs a full 8.5in page to mean anything: it measures |
| + one, and below the width where the whole sheet fits, the labels it |
| + draws are measuring a page that is not there. 54rem (864px) is |
| + 8.5in of paper plus the tray's own padding either side. |
| + |
| + A higher threshold than the 36rem at which the paper gives up |
| + looking like paper, and deliberately so: between the two the page |
| + is still a sheet and is simply too narrow to rule. |
| + |
| + IMMEDIATELY AFTER THE RULE IT OVERRIDES, and that placement is the |
| + fix rather than a tidiness. This sat up with the other media |
| + queries first and did nothing: it has exactly the same specificity |
| + as the rule above (0,3,0), so source order decides, and the |
| + display: flex two hundred lines further down won. The browser |
| + drive caught it — the ruler marks were still measured at 390, 486 |
| + and 582 in a 320px viewport, past a page whose scrollWidth was by |
| + then correct. |
| + |
| + This is the readable half of the SC 1.4.10 fix. The load-bearing |
| + half is [docs-ruler]'s own `overflow: hidden`, which cannot be |
| + wrong by a breakpoint. */ |
| + @media screen and (max-width: 54rem) { |
| + [docs-canvas][data-ruler="on"] [docs-ruler] { |
| + display: none; |
| + } |
| + } |
| /* The two margins, shaded so the text column reads as the part you |
| can type in — which is the first thing anybody looks at a ruler |
| to find out. 1in each, matching [docs-page]'s padding. */ |