Fix mobile page-nav sizing and print stylesheet regressions - #207
Merged
Conversation
Two issues reported on mobile, both traced to nav.page-nav's sizing: - Day-nav text was hard to read: font-size: clamp(0.65em, calc(3.2cqw), 1.1em) was hitting its floor (13px, given the 20px root) at common phone widths, since the container-query-based scaling term shrinks below that floor there. Raised the floor to 0.8em (16px). - The two segmented controls (tradition/calendar toggles) were wrapping onto separate lines at common phone widths -- confirmed via a byte-for-byte diff against the pre-session CSS baseline that this specific behavior already existed before today's changes, not a regression from the CSS refactor or dark theme work. Raising the text floor above shifted the wrap threshold from ~385px to ~400px (larger text needs more room), which now lines up with the existing 400px breakpoint that already wraps day-nav away from the toggle row. Added justify-content: center to .toggle-row at that breakpoint so the two controls stack as a centered pair instead of the uncontrolled flex-end wrap, which left a lone wrapped-down control sitting oddly right-aligned under the row above it. Verified across 320-500px via a same-origin iframe (window resize doesn't affect the actual rendering viewport in this environment) at each of the breakpoint's edges plus representative phone widths -- wraps and centers correctly at <=400px, single row and correctly sized above it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hf6j2xXQXywHVh3HAVRxB3
Following up on the mobile page-nav sizing fix (day-nav text floor), the tradition/calendar toggle groups were still wrapping onto separate lines at common phone widths. Brian confirmed this was undesired -- they'd never stacked before -- so rather than accept the wrap and just style it better, this makes them actually fit on one line down to the narrowest realistic phone width (verified to 320px): - Removed the three "New" status badges (Greek tradition toggle x2, translation picker) entirely, across all breakpoints, not just narrow ones -- Brian's call, since those features have been live for a couple weeks and the badges were the single largest contributor to the toggle row's width (~35px). - Removed the now-fully-unused .status-badge CSS rule. - Tightened .toggle-row's gap (1rem -> 0.5rem) and .segmented-control label's padding (3px 14px -> 3px 9px). Verified via a same-origin iframe harness (measuring true content width vs. available width, independent of the wrap CSS itself) that this fits down to 320px with a small but real margin, and confirmed it doesn't look cramped at desktop widths either. - Removed .toggle-row from the 400px flex-wrap media query -- .day-nav still wraps onto its own line there when it doesn't fit alongside the toggle row, but the toggle row itself now stays nowrap and correctly sized instead of wrapping internally. Also: the date heading (main#orthocal > header h1's own text, e.g. "Thursday, August 20, 2026") was a flat 1.5em with no responsive scaling at all, while the day-title span below it already scaled fluidly via clamp(1em, calc(5cqw + 15px), 1.5em). At narrow widths the title's floor (1em, relative to h1's fixed size) equaled the date's fixed size, so they read as the same size -- and since everything else on the page shrinks on mobile, the unshrinking date increasingly stood out as oversized. Gave h1 its own clamp(1.1em, calc(4cqw + 12px), 1.5em): unchanged at desktop widths (still resolves to the same 1.5em/30px, verified), scales down at narrow ones. This also fixed a secondary side effect: since the title span's own clamp is relative to h1's (its parent) font-size, shrinking h1 correctly shrinks the title's floor too, restoring title-bigger-than-date hierarchy at every width instead of the two converging to equal size on mobile. Verified across 320-1400px via the same iframe harness used in the prior mobile-nav PR. Full test suite (162 tests) passes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hf6j2xXQXywHVh3HAVRxB3
Brian reported print output had degraded since the site redesign and asked to restore it to how it looked around June 18. Compared print.css and main.css against the commit current on that date (86579fe) to find what actually changed: - body's grain-texture background-image and gradient (main.css) are screen-only additions from PR #169 ("warm up the parchment color scheme", Aug 10) -- didn't exist June 18, never had a print reset, and were bleeding straight into print output, wasting ink. Added `background: none` for print. - #orthocal-content > header::before's gradient/shadow band (behind the date and day title) is a similarly new screen-only addition, also never reset for print. Hidden entirely for print. - The print-only 200% font-size boost on the date heading (`main#orthocal > header h1`) had gone silently dead: the #orthocal-content wrapper added in the Safari scroll-jump fix (#204) moved header out from being main#orthocal's direct child, and this selector was never updated to match. Fixed to `#orthocal-content > header h1`. - Two now-fully-dead border-zeroing rules removed: main#orthocal and .readings-columns/section.readings both had real borders back in June (`border-top: 8px solid #eee` and `border-top: 3px solid #ddd` respectively) that print correctly zeroed out. Neither element has a border at all anymore -- the two-column redesign uses grid gap for spacing instead -- so both print overrides were inert cruft. Verified via a static snapshot of the live rendered page (cache- busted to route around the local dev server's stale-ETag caching, same class of issue hit earlier this session) with print.css's media forced to apply normally: confirmed the texture and gradient band are gone and the date heading's 200% boost is active again. The two- column readings grid was not a regression -- it already collapses to one column via the existing 800px screen breakpoint at realistic print page widths, verified separately. One pre-existing, unchanged-since-June quirk noted but not chased: table.month's negative-margin bleed trick (`margin: -1in -1in -1in 0in`) only makes sense inside real @page pagination, so it can't be verified by forcing print.css to apply in normal screen rendering (and actually triggering print preview means a system dialog, which we avoid automating). Not a redesign regression since the technique is identical to June's. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hf6j2xXQXywHVh3HAVRxB3
brianglass
changed the title
Brian recalled readings used to flow in multiple columns, from before the redesign, and wanted that back -- and confirmed it should apply to screen too, not just print: back on June 18 (86579fe) main.css set `.passage { columns: 3 20em; column-gap: 2em; column-rule: 1px solid #ddd; }` unconditionally, with print.css only overriding column-rule to invisible. The redesign dropped multi-column entirely in favor of today's two-side-by-side-sections grid, and this session's earlier print.css restoration (previous commit) had reintroduced it as a print-only rule -- moved it back to being main.css-authoritative (screen included) with print as a thin override, matching how it actually worked in June. Used var(--color-border-subtle) for the column-rule instead of the original literal #ddd, so it stays dark-mode-correct instead of reintroducing an untokenized value the earlier refactor had eliminated. Also addressed Brian's report that readings were landing on page 2 instead of under the title on page 1: added `break-before: avoid` on .readings-columns as a page-break hint (not a guarantee -- the engine can still break there if content genuinely doesn't fit) alongside the column restoration, which should already substantially help just by shrinking the readings' own vertical footprint. Separately: removed the translation <select>'s border and native dropdown caret (appearance: none) -- print-only. First implementation mistakenly put this in main.css (affecting screen too); reverted that and moved it to print.css once corrected. Verified via the same cache-busted static-snapshot technique used in the previous print.css commit: confirmed 3-column layout active on both a normal screen load and forced-print rendering (column count via getComputedStyle, not just visual inspection), confirmed the select's border/appearance is unaffected on screen and correctly stripped under forced-print. Full test suite (162 tests) passes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hf6j2xXQXywHVh3HAVRxB3
Diagnosed a real cross-browser inconsistency Brian hit testing this live: the collapse-to-one-column behavior for .readings-columns relies on main.css's @media (max-width: 800px), but print engines don't agree on what width that evaluates against for a page box -- Chrome collapsed it at print, Safari kept the side-by-side grid. Brian's call once he saw that: keep the printout matching the screen layout exactly (side by side), rather than collapsing it. Re-asserts the grid's actual column values (1fr 1fr, 3em gap) directly in print.css so it no longer depends on that breakpoint matching -- guarantees the same side-by-side layout regardless of how any given browser's print engine computes page width. Verified via the same cache-busted static-snapshot technique used in prior commits: confirmed grid-template-columns computes to two equal columns under forced-print rendering. Full test suite (162 tests) passes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hf6j2xXQXywHVh3HAVRxB3
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Mobile page-nav
Three mobile issues, all traced to
nav.page-nav's sizing rules:font-size: clamp()floor from 13px to 16px.clamp()instead of a flat1.5em-- unchanged at desktop widths, scales down at narrow ones, restores title-bigger-than-date hierarchy at every width.Print stylesheet
Compared
print.css/main.cssagainst the commit current on June 18 to find what actually regressed since the redesign, then iterated live with Brian against real Safari/Chrome/Firefox print output:body's grain-texture background and#orthocal-content > header::before's gradient/shadow band are screen-only additions from the redesign that never got a print reset -- were bleeding into print output. Both reset/hidden for print.#orthocal-contentwrapper landed in Fix Safari scroll jump on day-nav/toggle navigation #204). Fixed..readings-columns's collapse-to-one-column behavior depends on@media (max-width: 800px), and print engines don't agree on what width that evaluates against for a page box (Chrome collapsed it, Safari didn't). Re-asserted the side-by-side grid values directly in print.css so it doesn't depend on that breakpoint at all -- Brian's explicit call to match the screen layout for print..passage { columns: 3 20em; ... }(screen and print both), but once the side-by-side section split was locked in, Brian decided the outer split was columns enough -- the nested per-section multi-column flow was removed from both screen and print as unnecessary.break-before/page-break-before: avoid, trimming the header's print padding for real headroom, and removing the nested multi-column fragmentation context -- none of it changed Firefox's behavior. Conclusion, confirmed by process of elimination: Firefox treats the.readings-columnsgrid as atomic for print pagination (fits entirely on the page, or moves entirely to the next one), and the day's full readings/stories content is essentially always taller than one page, so it always moves. Chrome and Safari don't have this limitation. Brian's decision: accept it rather than give up the side-by-side layout (declined both alternatives -- CSS multicol instead of grid, or single-column stacking -- to keep it matching the screen).<select>: removed its border and native dropdown caret for print only (appearance: none) -- inert on paper. Screen is untouched.Verification
print.css's media forced to apply normally, checked viagetComputedStyle(grid columns, background resets, select stripping).docker compose run --rm tests-- 162 tests, all passing (re-run after every round of changes).Test plan
🤖 Generated with Claude Code
https://claude.ai/code/session_01Hf6j2xXQXywHVh3HAVRxB3