/*
* responsive.css
* Created: 2026-08-27
* Last change: 2026-09-03 20:20 — added `html { text-size-adjust:
* 100% }` (site-wide, plus the same rule in both book_global.css
* copies for the reader's content iframe). Real phones (not PC,
* not DevTools device emulation) auto-boost body-text font-size in
* narrow columns — Firefox for Android especially aggressively
* (Mitch found the AFOTB Contents page rendering ~2x size there,
* plus smaller title-page spacing drift on phone Chrome/Brave).
* DEFAULT SIZE's clamp() below already does this job deliberately;
* this turns the browser's own auto-boost off so it can't fight it.
* No-op on desktop (never had auto-boost) and DevTools mobile
* emulation (doesn't simulate it either) — untestable except on a
* real phone.
* ---- prior ----
* Last change: 2026-09-02 00:05 — Freedom Clock: form.formFClk
* transform translateY(-50%) -> none. Tonight's text-centre rework
* had started centring the white box's MIDLINE on the flag; the 2005
* design deliberately puts the box's TOP EDGE on the flag's 50% line
* (original top:5em in the 100px flag), so it sits lower — Mitch
* 2026-09-02: "the one thing that had a specific vertical position".
* ---- prior ----
* Last change: 2026-09-01 23:23 — book reader header: "SIFLAJ
* Freedom Media" (p.HdrTxtSec) hidden and its + the logo's + the
* title's top-push paddings zeroed so the book banner title centres
* the same way the plain pages now do (Mitch: "take out SIFLAJ
* Freedom Media and center the title"). (Separately: the AFOTB
* COVER-page title had the same "Arial Rounded MT Bold" problem —
* fixed in books/library/afotb/styles/afotb_0.css only, to a plain
* web-safe sans stack per Mitch, NOT the header's Nunito.)
* ---- prior ----
* Last change: 2026-09-01 22:28 — (a) Page Section Title
* (.TextFamilySecTitle.FontPt15) got its own clamp() so it stops
* rendering at a default- size on mobile; (b) Page Banner Title
* (p.HdrTxtTitle) now uses a self-hosted "Nunito" ExtraBold (800)
* web font (styles/fonts/Nunito-ExtraBold.woff2 + @font-face here)
* instead of the per-page CSS's fallback-less "Arial Rounded MT
* Bold", which was absent on every platform and rendered as each
* browser's own default serif — Mitch: "the font needs to look the
* same on PC and mobile". Self-hosting is the only guarantee (same
* as the signature font). Mitch wanted a rounded/friendly font,
* bold: first Varela Round, then Nunito 800 when Varela Round proved
* single-weight (no real bold). (c) The banner title + logo are now
* VERTICALLY CENTRED in the header (div.HdrContainerL2 -> flex
* align-items:center; the per-page top-push paddings + the 's UA
* margin zeroed) instead of top-anchored with padding-top:5em.
* ---- prior ----
* Last change: 2026-09-01 20:20 — Freedom Clock time value vertical
* centring. The value would not centre in its box because it was an
* (form-associated so
* document.time.tfield still resolves; .value still writes text —
* elapsed_time.js UNCHANGED). lays out like a .
* (2) Every line-box centring attempt (padding nudge / flex / grid /
* line-height) still looked HIGH, worse as the box shrank, because
* the string is descenderless and the font's reserved descender
* strip stayed blank below the glyphs. Fixed with
* `text-box: trim-both cap alphabetic` — trims the box to the real
* cap-height/baseline glyph metrics, then `place-items:center` (grid)
* centres the actual ink. Measured-equal gaps top/bottom at 7-15px
* font. Engines without text-box-trim fall back to line-box centring
* (graceful). No magic numbers.
* index.css + elapsed_time.js untouched; index.shtm changed (1 element).
* DEV ONLY.
* ---- prior ----
* Last change: 2026-09-01 18:30 — Freedom Clock: centre the whole
* clock assembly (left quote | flag+counter | right quote) on the
* banner. div.FClkContainerL2 is now a flex row filling the banner
* (height:100%; align-items:center); its inline-styled wrapper
* is display:contents so its margin-top:1em stops applying and the
* three pieces become L2's flex items; FClkContainerL3 goes
* position:relative (kept as the form's containing block); the em
* top-offsets on FClkContainerL3 / p.FClkTxtL / p.FClkTxtR are
* zeroed. Replaces the 2005 hand-tuned em offsets that drifted once
* the banner became fluid. No !important, index.css/index.shtm
* untouched. Also reverted the un-deployed 2026-08-31 02:38 "quote
* spill" dev edits (p.FClkTxt floor back to 0.7em; removed
* p.FClkTxtL/R cqw margins and div.FClkContainer overflow:hidden) —
* Mitch reported they made the banner worse. The red-text-in-box
* centring is a separate still-open task. DEV ONLY — not deployed.
* ---- prior ----
* Last change: 2026-08-31 02:38 — Freedom Clock: the flanking quote
* text spilled out the bottom of the banner as the viewport narrowed
* (banner height shrinks ~width/6.67; the quotes' em top-margins and
* 0.7em font floor stopped shrinking at body's font floor, and the
* text wraps to more lines when narrow). Fix in responsive.css only:
* p.FClkTxt floor 0.7em->0.55em; p.FClkTxtL/R margin-top em->cqw
* (2.275cqw / 3.9cqw); div.FClkContainer overflow:hidden as the hard
* backstop below ~330px. index.css/index.shtm untouched. Pre-existing
* bug (narrow-width behaviour was unaffected by the 01:11 DEFAULT
* SIZE change), surfaced by close review. DEV ONLY.
* Last change: 2026-08-31 02:02 — input.inputFClk font-size floor
* 0.7em -> 0.6em so the full elapsed-time string fits the fixed box
* at 320px (iPhone-SE) instead of clipping its last word; <=1px
* smaller in the 320-373px band, invisible elsewhere. DEPLOYED to
* searingtruth.org 2026-08-31 ~02:xx together with the 01:11 / 01:34
* / 2026-08-30 23:24 changes below (Mitch: "drop the floor a hair,
* then publish everything") + the two bkframe.shtm + two
* book_global.css changes.
* Last change: 2026-08-31 01:34 — book reader shell now scales with the
* viewport too (Mitch: the plain pages were fixed first, the books were
* then the last fixed-width thing). REMOVED the
* body:has(div.BookContainer) { font-size: 62.5% } pin — book pages
* inherit DEFAULT SIZE's clamp() like everywhere else now. Safe: the
* razor-thin LeftColumn+BookContainer fit the pin protected is no
* longer hardcoded — div.BookContainer's min(calc(100% - 13.3em),
* 73.05em) recomputes it at any font-size (verified: side-by-side, same
* row, at 768/1024/1366/1920/2560/3840). Header stays edge-aligned
* with the book page. Chapter text inside #pageFrame also scales —
* sizeBookPage() in both bkframe.shtm raised its cap 10px -> 22px, and
* both book_global.css raised the matching clamp() ceiling. DEV ONLY.
* Last change: 2026-08-31 01:11 — DEFAULT SIZE (body font-size) now keeps
* ramping with viewport width on wide screens instead of freezing at
* 14px past ~1500px. WHY: the whole layout is em/%-based off body
* font-size (WebPgeContainer max-width 80em, header img 100% of that,
* every content box em) — so when the font froze, the layout froze at
* 1120px and became a shrinking island on wide/HiDPI viewports
* (measured: 58% of a 1920px screen, 29% of a 3840px one). New clamp
* clamp(0.625rem, 0.125rem + 0.8vw, 1.375rem): floor 10px (≤~1024px
* viewports UNCHANGED — tested mobile/tablet layout), ~proportional
* 0.8vw ramp (holds content at ~71% of viewport), ceiling 22px at
* ~2500px viewport (content caps ~1760px so lines don't get absurd on
* ultrawide). Book pages were still pinned to 62.5% at this step —
* the 01:34 entry above then removed that pin and scales them too.
* Does NOT fix the Chrome-on-Linux/X11 no-HiDPI
* bug (that gives Mitch's Chrome a 2x-too-wide viewport, unfixable in
* CSS) but makes both the 1920 and 3840 cases look far less islandy.
* DEV ONLY. Every by-eye size tuning (wordmark, Freedom Clock, clamp
* ceilings) should be re-checked at wide widths in Firefox.
* Last change: 2026-08-30 23:24 — Freedom Clock time box: dropped the
* field-sizing:content approach for a FIXED box sized/positioned as
* percentages of the flag graphic (div.FClkContainerL3), reproducing
* the original design's fixed box exactly (orig: form top 5em/50px,
* left 5.1em/51px in the 434x100 flag, wrapping a 22em/330px-content
* (334.5px border-box) x 1em (22.5px border-box) input at 15px font).
* => form.formFClk { top:50%; left:11.75%; width:77.07%; height:22.5%;
* transform:none }; input.inputFClk fills it (width/height:100%,
* box-sizing:border-box, overflow:hidden as a clip guard). font-size
* stays clamp(0.7em,1.875cqw,1.5em) — 1.875cqw == the original 15px on
* an 800px-wide FClkContainer, so the text tracks the flag. WHY:
* field-sizing:content renders differently per engine (that's why no
* browser matched the original box) and on mobile Firefox it sized the
* box to auto-inflated text, spanning the whole clock over the
* borders. A fixed % box renders identically everywhere and matches
* the art. index.css / index.shtm untouched. DEV ONLY, not deployed.
* Last change: 2026-08-30 18:21 — post-launch: retune the "SearingTruth"
* wordmark size on index.shtm. It inherited FontPt17 (2.3em), a size
* meant for the old script font; with the PT Sans signature face that
* read as oversized/gaudy (Mitch). New rule .TextFamilyStSig.FontPt17
* { font-size: 1.6em } — just above the accompanying text. See the
* comment on that rule. Nothing else changed this edit.
* Last change: 2026-08-30 16:45 — Freedom Clock time box, consolidated
* after much iteration. input.inputFClk: field-sizing:content +
* width:auto so the white box hugs the time TEXT (Mitch's explicit
* ask); symmetric padding-left/right:0.9em for the "few chars of
* space" each side and to keep the text horizontally centred (an
* earlier asymmetric 0.5/1.1 to fix a right-edge clip pushed the
* text left of centre — 0.9 symmetric absorbs the field-sizing
* trailing under-measure without the shift); font-size is the
* original responsive value clamp(0.8em, 1.875cqw, 1.5em) — Mitch
* tried and rejected two smaller values (15px cap, 1.25em cap) as
* too small and asked for the original size back; height:auto for
* vertical (Mitch: "better, not exactly centred, but neither is the
* live site" — caps-only value, no descenders, always reads high).
* form.formFClk shrink-wraps (width:auto) + left:50% +
* translateX(-50%) to centre on the flag. index.css / index.shtm
* untouched. NOTE: don't verify
INTERNAL text position with
* headless Chrome — differs from real Chrome; box geometry is OK.
* Earlier same day, 14:53 — signature/wordmark font is now "PT Sans"
* italic (self-hosted at styles/fonts/PTSans-Italic.woff2), a plain
* friendly italic matching what Mitch remembers the true original
* being. Replaces a same-day trial of "Yellowtail" (brush script,
* rejected on sight) which had replaced "Nunito". One @font-face
* plus one --signature-font value changed here, mirrored identically
* in both books/library/{afotb,wwat}/styles/book_global.css.
* Prior history follows.
* Last change: 2026-08-28 20:05 (this session, 2026-08-28 — fixed
* three book-page-shell resize bugs that only appeared on a LIVE
* window resize (sizeBookPage() never re-ran on 'resize', only on
* chapter navigation; dyn_height.js's LeftColumn sync had the same
* load-time-only gap); fixed site-wide page-box centering at both PC
* width (div.WebPgeContainer had a fixed left margin, never auto) and
* mobile width (div.BookPageContent/BookPageMarg relied on
* margin:auto on FLOATED elements, which never works in any browser);
* moved "Total Pages" out of its own bar under the header and into a
* compact "N Pages" label on the chapter-selector bar itself, and
* fixed that selector's own multi-row wrapping to center every row
* instead of the float-default flush-left. Full reasoning for all of
* this is in each rule's own comment below, not repeated here.)
* Earlier — round 5 — normalized the FontPt8/
* FontPt9 body-text inconsistency flagged by the DEDUCED CONTENT
* ROLES map: plain body paragraphs that were FontPt8 are now FontPt9,
* an HTML class change in index.shtm/community_books.shtm, not a CSS
* rule — see the note under DEDUCED CONTENT ROLES for exactly what
* was and wasn't touched. Round 4 added the DEDUCED CONTENT ROLES
* map itself: the original site's font-family/size/color/weight
* utility classes compose into a real, consistent set of semantic
* roles — section title, sub-heading, quotation, signature, body
* text, page banner title — confirmed by auditing actual usage
* across every page, not guessed. Documents which roles already
* scale correctly by inheriting body's clamp() and which (only the
* page banner title, so far) need their own rule, so future
* scaling work has one place to look instead of re-deriving a fix
* per instance the way the banner title and hamburger icon each
* needed twice)
*
* Purpose: fluid scaling for narrower viewports (tablet down to phone),
* a normal-looking default (desktop) size on modern large screens, and a
* CSS-only mobile nav toggle (hamburger) — without touching any of the
* site's existing per-page layout CSS files. Loaded LAST in each page's
* , after every existing stylesheet, so these rules win the normal
* CSS cascade with no !important needed anywhere.
*
* TWO KEY IDEAS, worth understanding before editing this file further:
*
* 1. The entire original site is built in `em` units, both for layout
* (widths, positions) and for typography, all ultimately relative to
* body's own font-size (originally a fixed 62.5%, i.e. 1em = 10px).
* Raising body's font-size scales every em-based measurement in the
* whole site proportionally, with no per-file changes needed. See
* DEFAULT SIZE below. Round 2 did this with three stepped breakpoints
* (75%/100%/125%) — that produced visible jumps as the window crossed
* each boundary, and 125% was exactly double the original size (the
* literal "twice as big" you saw). This round replaces the steps with
* one continuous clamp(), capped much lower.
*
* 2. Any element positioned with a FIXED em width/offset inside an
* otherwise-fluid parent will not track that parent's size — it just
* sits at its original fixed size regardless of what's around it.
* Freedom Clock's three layers, and the header logo, are both cases
* of this. The fix in both cases is the same: convert the fixed em
* value to a PERCENTAGE of its own parent's width, so it scales
* proportionally no matter how wide that parent currently is —
* decoupled from font-size entirely, driven purely by the parent's
* actual rendered width.
*/
/* ============================================================
DEDUCED CONTENT ROLES
============================================================
The original 2005 CSS separates font-family / size / color /
weight / alignment / margin into independent, composable utility
classes instead of naming a semantic role on any single class.
The table below is the REAL pattern — confirmed by checking every
page's actual usage, not guessed — mapping each deduced role to
the compound class signature it always uses in the existing
markup. No HTML changes needed anywhere: these are exactly the
classes already on the elements.
Role Signature (as it exists in the HTML) Scaling
------------------ ----------------------------------------- -------
Page Section Title .TextFamilySecTitle.FontPt15 own clamp() rule below (see 2026-09-01 note)
In-Page Sub-Title .TextFamilySecTitle (other FontPt sizes) em/clamp — inherits, no override
In-Body Sub-heading .TextFamilyNorm.FontPt8.FontBold em/clamp — inherits, no override
Quotation .TextFamilyQuote em/clamp — inherits, no override
Signature/Wordmark .TextFamilyStSig em/clamp — inherits, no override
Body text .TextFamilyNorm em/clamp — inherits, no override
Page Banner Title p.HdrTxtTitle cqw — see its own rule below
Every role except the page banner title needs nothing here at
all: every FontPt* value is `em`, relative to body's own
font-size, so DEFAULT SIZE's single clamp() below already scales
all of them together, correctly, as one lever. The page banner
title is the one genuine exception — it lives inside a header
whose WIDTH drives its scale (see KEY IDEA 2 above), not body's
font-size, which is exactly why it needed its own cqw-based rule
instead of just inheriting like everything else. If a role above
is ever found to need its own scaling rule too, add it here,
under its own heading, the same way — not as an unlabeled
one-off discovered and fixed again from scratch.
NORMALIZED 2026-08-27: plain body-text paragraphs (TextFamilyNorm,
no FontBold/FontItalic) that were inconsistently FontPt8 are now
FontPt9 — the WWAT-section explanatory paragraph on index.shtm
("Community Book Auto Browsers"...) and six paragraphs on
community_books.shtm. This was an HTML class-attribute change, not
a CSS rule — done in the markup itself, so it holds regardless of
viewport. Deliberately NOT touched, since they're genuinely
different roles, not the same inconsistency: the four bold
sub-heading lines on community_books.shtm ("Legal Information"
etc., still FontPt8 — see In-Body Sub-heading above), the italic
dark-blue legal-notice quote block on community_books.shtm (a
Quotation-style treatment, not body prose), and the underlined
blog date-stamp caption on index.shtm ("Sunday, December 23,
2012") — a deliberately small metadata label, not paragraph text.
============================================================ */
/* Page Section Title — its own scaling rule (2026-09-01, Mitch: "the
mobile pages have the default giant font for 'A Vision of Hope, A
Plan of Action'"). global.css's .FontPt15 = 2.1em; against body's
10px mobile floor that is 21px next to 12px body text (ratio 1.75)
and it looks like an un-tuned default
— and the phrase wraps to
two lines on a phone. On desktop 2.1em is right, so this only pulls
it down on small viewports: clamp floor 1.5em (15px at the mobile
body floor — ratio ~1.3 to the 12px body text, fits on one line).
The fluid middle 1.25em + 0.8vw is body-relative in its base (so it
keeps tracking body on wide screens) and hits the 2.1em ceiling at
~1100px viewport — while body is still on its own 10px floor — so
every desktop width lands on 2.1em exactly as before (checked at
1400/1920: within a rounding px of the old size). Applies to all
four pages carrying this role (mission_statement / searingtruth /
forward_media / community_books). .TextFamilySecTitle.FontPt15
(0-2-0) beats global's .FontPt15 (0-1-0) regardless of load order —
same pattern as the wordmark rule below. */
.TextFamilySecTitle.FontPt15
{
font-size: clamp(1.5em, 1.25em + 0.8vw, 2.1em);
}
/* Self-hosted, not linked from Google's own CDN -- renders
identically for every visitor with no third-party request at all.
File lives at styles/fonts/PTSans-Italic.woff2, downloaded once
from Google Fonts' own public font file (the Latin-subset .woff2
actually served to a real Chrome UA -- PT Sans' italic/400 face,
the only style the signature role uses). Declared with
font-style:normal deliberately: the file IS the italic design, but
the .TextFamilyStSig / .sfCvrStSig rules request a plain
(normal-style) face and must NOT be modified, so this @font-face
is registered as the normal face for the "PT Sans Signature"
family -- an exact match with nothing to fall back through. The
book-cover pages need their OWN copy of this same @font-face (see
the note on --signature-font below for why), at
books/library/{afotb,wwat}/styles/book_global.css -- same font
FILE, referenced by its own relative path from each context. */
@font-face
{
font-family: "PT Sans Signature";
font-style: normal;
font-weight: 400;
font-display: swap;
src: url("fonts/PTSans-Italic.woff2") format("woff2");
}
/* Signature/Wordmark role's font, in ONE place for every outer site
page (index.shtm etc.). The book-cover pages have their own
separate copy of this same variable, in
books/library/{afotb,wwat}/styles/book_global.css (kept identical
between the two books) — a book cover's content loads inside an
iframe, an entirely separate CSS cascade from this page, so a
single :root here can't reach it; that split is a real constraint
of how iframes work, not something CSS alone can unify into one
file. To change the signature font everywhere, change the value
here AND in that book_global.css pair — not the individual
.TextFamilyStSig / .sfCvrStSig rules themselves, which now just
reference this variable.
Current value, 2026-08-30: "PT Sans" italic -- a plain, friendly
sans-serif italic, self-hosted per the @font-face above. This is
the direction Mitch has consistently described the true original
font as being (a plain friendly italic, never a script). Rejected
picks, in order: "Brush Script MT" (the original hardcoded name;
never actually installed on most systems -- decades of OS font
substitution is how that name got there), "Alex Brush" (Mitch:
"over the top flowery and silly"), "Nunito" bold italic (Mitch:
"doesn't look correct"), "Yellowtail" brush script (rejected on
sight, same day). Genuinely self-hosted, not dependent on any
visitor's OS having a specific font installed. */
:root
{
--signature-font: "PT Sans Signature", "PT Sans", "Trebuchet MS", sans-serif;
}
.TextFamilyStSig
{
font-family: var(--signature-font, sans-serif);
}
/* The "SearingTruth" wordmark (index.shtm, 3 uses, nowhere else on
the site — the book covers use .sfCvrStSig instead) carries the
class FontPt17 = 2.3em in global.css. That size was chosen in 2005
for "Brush Script MT", a script face that renders small and needs
sizing up. The current --signature-font is a normal-proportion
sans-serif italic, so 2.3em reads as oversized/gaudy (Mitch,
2026-08-30, post-launch). Retune it to sit just above the quote /
body text it accompanies (FontPt9 = 1.2em, FontPt10 = 1.5em):
still distinctive via colour + italic + the signature face, not by
size. .TextFamilyStSig.FontPt17 (0-2-0) beats global's .FontPt17
(0-1-0) regardless of load order. 1.6em is the one number to tune. */
.TextFamilyStSig.FontPt17
{
font-size: 1.6em;
}
/* ============================================================
TEXT SIZE ADJUST — real phones (Firefox for Android worst,
Chrome/Brave for Android more mildly) auto-boost body-text
font-size in narrow text columns to "help" readability, on top
of whatever font-size the CSS actually specifies. Desktop
browsers, and Chrome DevTools' mobile emulation, never do this —
which is why this project's testing never caught it. DEFAULT
SIZE's clamp() below is already a deliberate, tuned answer to
"what size should this be on a small screen" — the browser's own
heuristic just fights it, inconsistently per engine. Turning it
off makes every engine render exactly what the CSS says, same as
desktop already does. This document only — the reader's content
iframe (cover/Contents/chapters) is a separate document and needs
its own copy, in both book_global.css files.
============================================================ */
html
{
-webkit-text-size-adjust: 100%;
text-size-adjust: 100%;
}
/* ============================================================
DEFAULT SIZE — smooth, continuous scaling, no breakpoint
jumps. The WHOLE layout is em/%-based off this one value:
div.WebPgeContainer's max-width is 80em, the header image is
100% of that, every per-page content box is em — so this
font-size IS the site's zoom control. Keeping it roughly
proportional to the viewport holds the content at ~71% of the
screen at any desktop width, instead of freezing at a fixed
pixel width and shrinking to an island on wide / HiDPI screens
(measured 2026-08-31: the old 14px-ceiling clamp froze the
layout at 1120px past ~1500px viewport — 58% of a 1920px
screen, 29% of a 3840px one).
Floor 0.625rem (10px): viewports up to ~1024px are untouched —
the already-tested-and-approved mobile / tablet layout, the
floor wins there.
Ramp 0.125rem + 0.8vw: ~proportional to viewport width (0.8vw
alone holds a constant fraction; the small 0.125rem intercept
just smooths the hand-off off the floor). ~17px at 1920,
~22px at 2560.
Ceiling 1.375rem (22px): reached at ~2500px viewport; past
that the content holds near 1760px so lines never get absurdly
long on an ultrawide monitor.
Three numbers to tune: 0.625rem floor, 0.8vw slope, 1.375rem
ceiling.
============================================================ */
body
{
font-size: clamp(0.625rem, 0.125rem + 0.8vw, 1.375rem);
}
/* ============================================================
Fluid page/header — replaces fixed 80em with a cap, not a
forced shrink, so nothing overflows on a viewport narrower
than the design width.
============================================================ */
div.WebPgeContainer,
div.HdrContainer
{
width: auto;
max-width: 80em;
}
/* Every per-page stylesheet (index.css, mission_statement.css,
community_books.css, forward_media.css, searingtruth.css,
tech_problem.css) and book.css all give div.WebPgeContainer the
exact same original rule: margin-top:1.0em; margin-left:1.0em --
a small, fixed, LEFT-anchored gutter, with no matching right
margin and no centering. In 2005 that was fine: the box was a
plain fixed width and monitors weren't dramatically wider than
it, so the unused space this left on the right was minor or
nonexistent. Once max-width (above) let the box actually shrink
below the viewport's width on any modern, wide desktop monitor,
that same fixed 1em-left margin left the WHOLE PAGE sitting flush
against the left edge with a large, empty strip on the right --
confirmed 2026-08-28 as the real cause of Mitch's "text and
graphics on both pages are left of center" report (he was
describing the outer page box's own position in the viewport, not
any internal text-alignment problem -- nothing inside the page
was ever actually miscentered). margin-left/right:auto centers
the box within the body once it's narrower than the viewport, and
simply has nothing to distribute (behaves like 0) once the
viewport is at or below max-width, so mobile/narrow layouts are
unaffected. Deliberately only overrides left/right here, not
margin-top -- the original 1em top margin from each page's own
CSS is untouched. Covers every page site-wide, book and
non-book alike, in this one shared rule -- no page-specific CSS
file needed a change. */
div.WebPgeContainer
{
margin-left: auto;
margin-right: auto;
}
/* Some pages (mission_statement/forward_media/community_books/
searingtruth/tech_problem) set HdrContainer's height to a fixed
em value matching their banner image's ORIGINAL height. Once
that image is fluid (below), a fixed parent height stops
matching the image's actual rendered height. auto lets the
container follow the image again, on every page — a no-op on
pages that never set a fixed height here (they were already
auto by default). */
div.HdrContainer
{
height: auto;
container-type: inline-size;
}
img.HdrBkgrnd
{
width: 100%;
height: auto;
}
/* The 5 book-style pages' banner was ALWAYS a deliberate fixed stretch
(width AND height both set independently, 800x114 — not the image's
true intrinsic ratio, which is slightly different at 835x114) — the
logo and title below were positioned and sized to match that EXACT
stretched box, not the image's natural proportions. My earlier fix
(height:auto) used the image's true aspect ratio instead, which is
close but not identical — enough to slowly drift the logo out of
alignment with the banner as the width changes. aspect-ratio
reproduces the original fixed-stretch box exactly, derived from
width instead of hardcoded, so it stays correct at any size.
Scoped with :has() to ONLY the pages that actually have this
logo/title overlay structure — index.shtm's HdrContainer holds a
plain banner with no overlay and a completely different image, and
forcing the same aspect-ratio onto it would badly distort it. */
div.HdrContainer:has(div.HdrContainerL2)
{
aspect-ratio: 800 / 114;
}
div.HdrContainer:has(div.HdrContainerL2) img.HdrBkgrnd
{
height: 100%;
}
/* Decorative separator lines used throughout page content — fixed at
64.5em (645px) with no responsive handling at all, wider than most
phone screens. Same fix as the banner images above. Deliberately NOT
applying this broadly to every UA margin (1em top+bottom,
~44px each at this font-size) — harmless under the old
top-padding layout, but as a flex item under the new
align-items:center it made the title's box far taller than the
banner and pushed the text low. Zeroed so the flex item is just
the text height and centres cleanly. */
margin: 0;
}
/* ============================================================
General wrapping safety net. Nothing in the actual page
content is unbreakable right now (checked directly — no long
URLs or single unbroken strings), so this doesn't change
anything visible today. It's cheap insurance for anything
added later: without it, one sufficiently long unbreakable
word or link text can force a container wider than its
parent, the same overflow class of bug as the fixed-width
images and the 40em quote block elsewhere in this file.
============================================================ */
div.RightColumn,
div.LeftColumn
{
overflow-wrap: break-word;
word-wrap: break-word;
}
/* ============================================================
Homepage content sections — a full sweep of every fixed-em
width declaration on the site (checked every stylesheet, not
just this page) found four more live, in-use instances of the
exact same bug as the 40em quote block: a content box with a
fixed width wider than a narrow viewport, so it overflows
instead of shrinking, which reads as "text doesn't wrap" even
though the wrapping itself is fine — it's the BOX that doesn't
fit, not the text inside it. Same fix each time: keep the
original width as the preferred/desktop size, add max-width:
100% so it can never exceed its actual available space.
div.MisState (60em) and div.UnfVoicesContainer exist in the
CSS but are never referenced by any page's HTML — left alone,
dead code, not a live bug.
============================================================ */
div.StdContainerIndex,
div.AboutFClk,
div.FpBrowser,
div.FpControlContainer
{
max-width: 100%;
}
/* One MORE live instance of the exact same bug that the sweep above
missed, found 2026-08-28 when Mitch reported Forward Media's
paragraphs "not wrapping" on a real phone-width test -- the text
WAS wrapping, just at this div's fixed 60em (600px), which is
wider than the visible screen, so every line ran off the right
edge instead. div.FredmMed is genuinely live on TWO pages
(forward_media.shtm and tech_problem.shtm, confirmed by grepping
each page's actual HTML, not assumed) -- both define their own
identical copy of this rule in their own per-page stylesheet, so
fixing it once here in the shared file covers both. Checked
div.MisState (mission_statement.css AND searingtruth.css) and
div.CommBkMed (community_books.css) the same way, by grepping
for the class in each page's real markup, not trusting the
earlier sweep's note above at face value a second time -- both
are confirmed still genuinely unused (those three pages build
their body text from plain TextFamilyNorm/FontPt9 utility-class
divs with no fixed-width wrapper at all, so they were never
affected by this bug in the first place). box-sizing:border-box
is required here (not just max-width) because FredmMed has real
left/right padding (3em each side) -- without it, 100% width plus
6em of padding would overflow past 100% regardless of the cap,
the same padding-vs-fluid-width gap already fixed elsewhere in
this file. */
div.FredmMed
{
width: 100%;
max-width: 60em;
box-sizing: border-box;
}
/* Same root cause as div.FpBrowserBox's fix, one level up: each of
these has left/right padding and/or a border, which the default box
model adds OUTSIDE the declared width rather than inside it — so
even with max-width:100% capping the width itself, the actual
rendered box (width + that padding/border) could still be wider
than its parent, overflowing slightly regardless of the cap. This
is exactly what was happening to the WWAT section's own outer
bordered box (StdContainerIndex's 1em+1em padding plus
StdContainerIndexBorder's 0.2em border) — the right quote box's
border getting cut off wasn't only FpBrowserBox's own fault, it was
also its grandparent overflowing by a couple of em. Checked every
container touched anywhere in this file for the same gap
(left/right padding or a border, combined with a now-fluid width)
and fixed all of them here, not just the one that was reported. */
div.WebPgeContainer,
div.RightColumn,
div.StdContainerIndex,
div.AboutFClk,
div.FpBrowser,
div.FpControlContainer
{
box-sizing: border-box;
}
/* ============================================================
WWAT quote browsers ("Historical Figures" / "Citizens of the
Earth") — originally a fixed height:45em box holding two
floated boxes side by side. A fixed height is its own separate
bug from width: it doesn't adapt to how much room the actual
text needs, so content can visually overflow past the box's
bottom edge at any scale where it needs more room than 45em
happened to provide. Switched to flexbox instead of a fixed
height + floats: the container now sizes itself to whatever
its content actually needs ("scale by the text"), and
flex-wrap handles "sit side by side if there's room, otherwise
stack, centered" automatically — no hardcoded width breakpoint
to guess at and get wrong. flex:1 1 20em lets each box grow up
to its original 30em size when there's room, shrink down to a
20em floor before wrapping, and wrap onto its own (centered)
row once even that doesn't fit.
============================================================ */
div.WwatContainer
{
height: auto;
display: flex;
flex-wrap: wrap;
justify-content: center;
gap: 1em;
}
/* min-width:0 fixes the cutoff: flex items default to a hidden
min-width:auto, which means "never shrink below my content's own
natural minimum width" — a well-known flexbox trap. Without this,
the right-hand box couldn't actually shrink as far as flex-wrap's
own math expected it to, so instead of cleanly wrapping to its own
row, it stayed put and got visually clipped at the container's edge.
min-width:0 (see below) is what actually fixed the box's own
scaling — the text inside it is deliberately left tracking body's
font-size unmodified (FontPt10's plain 1.3em, unchanged), the exact
same mechanism every other piece of body text on the site uses. An
earlier round tried making this text track the box's own width via
cqw instead, which fixed one mismatch (text vs. its own box) but
introduced a worse one (this text no longer scaling in step with
the REST of the page, since the box's width and body's font-size
don't grow in exactly the same proportion as each other across the
whole viewport range) — removed once the box's real problem (the
flexbox min-width trap, not text sizing) was actually found. */
div.FpBrowser
{
display: block;
float: none;
flex: 1 1 20em;
max-width: 30em;
min-width: 0;
}
/* The bordered box inside each FpBrowser has padding (0.5em) and a
border (0.2em) but no width of its own — under the CSS default box
model, padding and border are added OUTSIDE the computed width
rather than counted within it, so this box was always rendering
1.4em wider than its actual available content width, no matter how
much that content width shrank or grew. That fixed 1.4em overflow
is exactly "scales, but the border gets cut off, and it's not
scaling like the rest" — it genuinely wasn't. box-sizing:border-box
makes padding/border count as part of the declared width instead of
adding to it, so the box now correctly fills exactly 100% of its
parent at any size. */
div.FpBrowserBox
{
box-sizing: border-box;
}
/* ============================================================
Right column — fills whatever space remains beside the fixed
13em left column. (A floated element with width:auto shrinks
to fit its content instead of filling remaining space, so
this needs an explicit calc() rather than just "auto".)
13.1em = LeftColumn's 13.0em width + RightColumn's own
0.1em border-left.
============================================================ */
div.RightColumn
{
width: calc(100% - 13.1em);
}
/* ============================================================
Freedom Clock (homepage only) — three absolutely-positioned
layers (background image, left/right quote text, flag+
counter) originally sized in fixed em widths that summed to
exactly the original 80em design (18.2 + 43.4 + 18.2 = 79.8em)
— a fixed composited graphic, not built to shrink. Converted
here to the equivalent PERCENTAGES of FClkContainer's own
width, so the whole composition scales together proportionally
at any width, the same technique as the header logo above.
The counter input's position (top/left, originally in em) is
converted the same way, as a percentage of the flag+counter
box's own now-fluid size, so it should stay aligned to the
same spot on the flag graphic at any scale — this one part is
my best-effort conversion from the original fixed numbers and
is the most likely thing to need a small manual nudge once you
can actually see it rendered.
============================================================ */
/* container-type:inline-size is the real fix for the "graphics scale,
text doesn't" problem. Root cause: the graphic elements (image,
layout boxes) scale by tracking FClkContainer's own rendered width,
which can range widely as the viewport resizes. The TEXT was still
scaling via `em`, which tracks body's font-size — a SEPARATE
mechanism, deliberately capped to a much narrower 1.4x range so the
rest of the site doesn't get oversized. Those two mechanisms move at
different rates, so text visibly falls behind the graphics almost
everywhere except right at the exact width where they happen to
coincide. Declaring FClkContainer a query container lets its
descendants size themselves in `cqw` units (1cqw = 1% of THIS
container's own width) — the text then tracks the exact same width
the graphics already track, not a separate, independently-moving
value. */
div.FClkContainer
{
width: auto;
max-width: 80em;
container-type: inline-size;
}
img.FClkBkgrnd
{
width: 100%;
height: auto;
}
/* ---- Vertical centring of the whole clock assembly on the banner ----
The banner image (img.FClkBkgrnd) sits in flow and gives
div.FClkContainer its height. Everything else is an overlay:
div.FClkContainerL2, positioned over the banner, holding an
inline-styled wrapper
(index.shtm, style="margin-top:1em") that
in turn holds the three pieces — left quote | flag+counter | right
quote.
The 2005 design top-anchored each piece with hand-tuned em offsets
(FClkContainerL3 top:0.9em; the wrapper's inline margin-top:1em;
p.FClkTxt margin-top 1.4em/2.4em). Those only lined up at the single
fixed 800x120 / 10px-body size it was built for. Once the banner
became fluid (tracks viewport width) while those offsets stayed em
(track body font-size), the two drifted apart and the whole assembly
slid toward — and on small screens / wide HiDPI off — the bottom of
the banner (Mitch, 2026-09-01). The DEFAULT SIZE ramp (14px->22px
body ceiling) widened that gap.
Fix — one flex container, no !important, no HTML change:
- the wrapper
is set display:contents, so it stops generating
a box (its inline margin-top:1em no longer applies) and its three
children become direct flex items of L2;
- L2 fills the banner (height:100%) and is the flex row:
align-items:center vertically centres all three pieces on the
banner's midline at ANY size; widths 22.8/54.4/22.8% +
space-between reproduce the left / centre / right placement;
- every per-piece em offset is then zeroed — nothing is
hand-positioned any more, so it stays centred at every width and
renders the same in every engine. */
div.FClkContainerL2
{
width: 100%;
height: 100%;
display: flex;
align-items: center;
justify-content: space-between;
}
div.FClkContainerL2 > div
{
display: contents;
}
/* Left / right quote columns: flex items now, not floats. */
div.FClkTxtContainer
{
width: 22.8%;
flex: 0 0 22.8%;
float: none;
}
/* The two hand-tuned quote offsets are replaced by align-items:center. */
p.FClkTxtL,
p.FClkTxtR
{
margin-top: 0;
}
/* 1.625cqw reproduces the original ratio exactly: the quotes were
1.3em (13px) inside an 800px-wide container at the original
design's font-size, and 13/800 = 1.625%. clamp() keeps a readable
floor and never exceeds the original 1.3em ceiling, even on a very
wide container. */
p.FClkTxt
{
font-size: clamp(0.7em, 1.625cqw, 1.3em);
}
/* Middle column (flag GIF + time-value form). position:relative (was
absolute) so it sits in the flex row as an ordinary item while
staying the containing block for form.formFClk. top/left cleared —
flex handles placement now. */
div.FClkContainerL3
{
position: relative;
top: auto;
left: auto;
width: 54.4%;
flex: 0 0 54.4%;
}
img.FClkFlag
{
width: 100%;
height: auto;
}
/* ================= Freedom Clock time value ==================
THE BOX is the