/*
* responsive.css
* Created: 2026-08-27
* 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 em/clamp — inherits, no override
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.
============================================================ */
/* 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;
}
/* ============================================================
DEFAULT SIZE — smooth, continuous scaling, no breakpoint
jumps. Stays at the original 10px baseline for any viewport
at or below 42em (~672px) — unchanged from the already-tested
mobile layout — then ramps up smoothly, capping at 14px
(1.4x original, not 2x) for wide/large-monitor viewports.
The two numbers worth tuning if this still isn't right:
0.875rem is the ceiling (currently 14px); 0.45rem + 0.4vw is
the ramp itself.
============================================================ */
body
{
font-size: clamp(0.625rem, 0.45rem + 0.4vw, 0.875rem);
}
/* ============================================================
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 on the site: the nav/panel
buttons use a JS-driven sprite technique (3 stacked states shown by
shifting the image's own `top` by a fixed pixel amount) that depends
on the image staying at its exact declared size — making those fluid
too would misalign the sprite shift. These two are plain decorative
dividers with no such dependency. */
img.SepLineMed,
img.SepLineSmall
{
width: 100%;
max-width: 64.5em;
height: auto;
}
/* ============================================================
Header logo + title (the 5 "book-style" pages, not the
homepage). HdrLogoContainer/HdrTxtContainer were fixed em
widths (25.2em/50em out of an assumed 80em header) — converted
to the equivalent percentages (31.5%/62.5%) so they scale with
whatever width HdrContainer actually has. img.HdrLogo was
fixed 24em/10.2em regardless of its container's size — this
was "the image that doesn't shrink" — now fluid within its own
(now percentage-based) container.
============================================================ */
/* padding-top/bottom percentages are a real, well-established CSS
quirk worth knowing: they ALWAYS resolve against the containing
block's WIDTH, never its height, even though they're vertical
properties. That's exactly what's needed here — these paddings push
the logo/title down from the top of a WIDTH-driven header, so
expressing them as plain percentages keeps that vertical offset
proportionally correct as the header's width changes, no container
query units needed. The original 0.6em (6px) and 5.0em (50px), both
measured against the original 800px-wide header, become 0.75% and
6.25%. Before this fix, both were fixed em values tracking body's
separately-capped font-size instead of the header's actual width —
the same mismatch as everything else in this file, and the direct
cause of the title appearing to "move down" as the window narrowed:
the header shrank a lot (width-driven), the padding barely shrank
at all (font-size-driven), so the gap between them grew. */
div.HdrLogoContainer
{
width: 31.5%;
padding-top: 0.75%;
}
div.HdrTxtContainer
{
width: 62.5%;
padding-top: 6.25%;
}
/* 24em logo inside a 25.2em container = 95.24%, not 100% — the
original had a small margin around the logo (it's centered via
text-align), filling the container edge-to-edge would make it
render slightly larger than intended. */
img.HdrLogo
{
width: 95.24%;
height: auto;
}
/* Role: Page Banner Title (see DEDUCED CONTENT ROLES above) — the one
role that doesn't just inherit body's clamp(). Same "graphics scale,
text doesn't" problem as Freedom Clock, same fix: the title was
3.5em (35px) in the original 800px-wide header, 35/800 = 4.375%.
Tracks HdrContainer's own width now instead of body's
separately-capped font-size. */
p.HdrTxtTitle
{
font-size: clamp(1.5em, 4.375cqw, 3.5em);
}
/* ============================================================
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;
}
div.FClkContainerL2
{
width: 100%;
}
div.FClkTxtContainer
{
width: 22.8%;
}
/* 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);
}
div.FClkContainerL3
{
left: 22.8%;
width: 54.4%;
}
img.FClkFlag
{
width: 100%;
height: auto;
}
/* The white box hugs the time text (see input.inputFClk below), so
the form just shrink-wraps it (width:auto) and is centred on the
flag graphic. Original design positioned it with a fixed left
offset; centring is the fluid equivalent and keeps it on the flag
at any width. */
form.formFClk
{
top: 50%;
left: 50%;
transform: translateX(-50%);
width: auto;
}
/* field-sizing:content makes the input size to its VALUE, so the
white box is only as wide as the current time string plus the
left/right padding below — it follows the text as the value and
the (cqw) font-size change, instead of being pinned to a fixed em
or a percentage of the flag. width:auto is required for
field-sizing to take effect.
font-size: cqw-based so the value shrinks with the flag graphic
and still fits on a phone.
height:auto so Chrome sizes the box to the text and vertically
centres it (index.css's height:1.0em is too short at the
fractional cqw font-size and clips the text to the top).
padding-left/right give the "few characters of space" each side
of the text that the original fixed-width box had by slack.
max-width keeps it inside the flag on a very narrow screen. */
input.inputFClk
{
width: auto;
field-sizing: content;
max-width: 92%;
font-size: clamp(0.8em, 1.875cqw, 1.5em);
height: auto;
padding-left: 0.9em;
padding-right: 0.9em;
}
/* ============================================================
Book reader shell (bkframe.shtm, shared verbatim by every book —
confirmed byte-identical between afotb and wwat except for two
script filenames). Reuses the SAME header/logo/title/left-column
classes as the 5 book-style main pages, but books/styles/book.css
declares different absolute dimensions for them: 86.4em page width,
not 80em, and a 25.2em/61.0em logo/title split, not 25.2em/50.0em —
the reader shell's WebPgeContainer is a wider bordered box than the
plain content pages. Same technique as everywhere else in this file
(percentage/cqw conversion of what book.css hardcodes in em), just
recalculated against book.css's own real numbers instead of reusing
the plain-page ratios, which would be visibly wrong here. Scoped to
:has(div.BookContainer) so none of this leaks onto the 5 plain
book-style pages, which don't have a BookContainer at all.
Kept the "book" name matching Mitch's own naming (a simulated open
book page, not to be confused with this file's own KEY IDEA 1 about
body's font-size "clock").
============================================================ */
/* The book reader shell's LeftColumn (13.2em) + BookContainer
(73.05em, capped below) sum to 86.25em -- fitting inside this
86.4em WebPgeContainer with only 0.15em to spare, a razor-thin
fit book.css's own author clearly hand-tuned against a FIXED
10px-per-em baseline (body's original, unconditional 62.5%).
The moment body's font-size varies at all -- exactly what
DEFAULT SIZE's clamp() does, deliberately, for every other page
-- every untouched em value in book.css (LeftColumn's width
chief among them) scales right along with it, and that tight
fit breaks: the two floats stop fitting side by side, so
BookContainer gets pushed entirely below LeftColumn -- often
over 1000px down, reading as "the page is blank" since nothing
below the fold is visible without scrolling that far. Pinning
body's font-size back to the fixed baseline, ONLY for pages
with a BookContainer, keeps book.css's own internal math
exactly as its author designed it. This doesn't undo any of
the actual responsive work above -- the header and book-page
composition were deliberately converted to percentages/
aspect-ratio, neither of which cares what body's font-size is. */
body:has(div.BookContainer)
{
font-size: 62.5%;
}
div.WebPgeContainer:has(div.BookContainer)
{
max-width: 86.4em;
}
/* div.HdrContainer MUST get this same wider cap too, not just its
parent WebPgeContainer -- the generic rule near the top of this
file (div.WebPgeContainer, div.HdrContainer { max-width: 80em })
caps BOTH of them together at the plain-page width, correctly,
for every OTHER page. Book pages need a wider 86.4em budget so
BookContainer (73.05em) actually fits beside LeftColumn (13.2em)
-- but leaving HdrContainer capped at the old 80em while
WebPgeContainer/BookContainer grow to 86.4em is exactly what let
the book page graphic render up to 62px wider than the header
sitting above it, on a real desktop width (confirmed via
getBoundingClientRect: BookContainer's right edge at 873px,
HdrContainer's at 811px, at a 924px window). Both need the wider
cap together, matching each other exactly, or they drift apart. */
div.WebPgeContainer:has(div.BookContainer) div.HdrContainer
{
max-width: 86.4em;
}
div.WebPgeContainer:has(div.BookContainer) div.HdrContainer
{
aspect-ratio: 864 / 114;
}
div.WebPgeContainer:has(div.BookContainer) div.HdrContainerL2
{
width: 100%;
}
/* 25.2em / 86.4em and 0.6em / 86.4em — same padding-top-resolves-
against-width quirk as the plain book-style pages, different base. */
div.WebPgeContainer:has(div.BookContainer) div.HdrLogoContainer
{
width: 29.17%;
padding-top: 0.694%;
}
/* 61.0em / 86.4em and 2.0em / 86.4em */
div.WebPgeContainer:has(div.BookContainer) div.HdrTxtContainer
{
width: 70.6%;
padding-top: 2.315%;
}
/* 35/864 = 4.05cqw, not the plain pages' 4.375cqw (35/800) — a real,
if modest (~8%), difference since this header is wider by design. */
div.WebPgeContainer:has(div.BookContainer) p.HdrTxtTitle
{
font-size: clamp(1.5em, 4.05cqw, 3.5em);
}
/* "SIFLAJ Freedom Media" — only exists on the reader shell, not the
plain book-style pages, so no existing rule to conflict with; same
graphic-tracks-width reasoning: 27/864 = 3.125cqw. */
p.HdrTxtSec
{
font-size: clamp(1.15em, 3.125cqw, 2.7em);
}
/* ============================================================
The simulated open-book page itself (BookContainer and
everything inside it). book.css fixes this as one big absolute
composition — a page-texture background image, an overlay layer
with header/content/footer bands, decorative left/right margins,
and the real chapter text loaded via an iframe.
WIDTH and HEIGHT are deliberately decoupled here, corrected after
Mitch caught a real architectural mistake: an earlier version of
this tied height to width via a fixed aspect-ratio, on the
reasoning that it would keep the page graphic's true shape intact
as it shrinks. What that actually did was force the CONTENT area
(the iframe, sized as a percentage of this same aspect-ratio-driven
box) to shrink right along with the graphic — but the chapter
text inside the iframe is real, fixed-size content, not something
that shrinks with the page. At any width where the aspect-ratio's
height became shorter than what the content actually needed, the
iframe couldn't show all of it, and a scrollbar appeared -- inside
what's supposed to look like a single page, so it read as the page
itself being broken. Mitch's own diagnosis was exactly right: the
graphic and the content are logically separate sections, and
tying the graphic's shape to a ratio that has nothing to do with
how much text a given chapter page actually contains was the
mistake -- not a necessary trade-off.
WIDTH still shrinks fluidly with the viewport (unchanged, capped
at 73.05em) -- that's what actually preserves "the graphic on
mobile" the way Mitch asked. HEIGHT is now content-driven: the
iframe's real height is measured directly from its own loaded
content (see the new pageFrame 'load' listener in bkframe.shtm's
appInit()) and applied to it directly, and every ancestor above it
uses height:auto so it naturally grows to contain that real
height, instead of a percentage computed from a fixed ratio. This
means the page's proportions are no longer locked to an exact
73.05:96 shape at every width -- it gets visibly taller relative
to its width as the viewport narrows, since the content itself
doesn't shrink -- but it now genuinely never needs to scroll,
and the graphic and the content are correctly independent, the
way they should be.
============================================================ */
/* BookContainer needs to fit BESIDE LeftColumn (13.2em + its own
0.1em border-left = 13.3em) on desktop, not just under some
width cap -- min(calc(100% - 13.3em), 73.05em) guarantees that
fit exactly, the same technique already used for the main site's
div.RightColumn (width: calc(100% - 13.1em)) below. A plain
max-width:73.05em was tried first and looked right on paper
(13.2em + 73.05em = 86.25em, fitting inside this shell's own
86.4em WebPgeContainer with 0.15em to spare) but that margin is
too thin to survive real box-sizing/border accounting -- it lost
the fit by a fraction of a pixel, and BookContainer, unable to
fit beside LeftColumn, wrapped below it entirely (the actual
cause of "blank on a regular page, fine once the hamburger menu
appears" -- mobile stacks instead of competing for width, so it
never hit this at all). calc() computes the real remaining space
directly instead of hoping two independently-chosen numbers add
up under whatever box model is in effect.
width:100% (not auto) matters for the SAME reason on
BookPageContainer/BookPageContainerL2 specifically because both
are float:left (set by book.css, unchanged) -- on a floated
element, width:auto means "shrink to fit content," not "fill
available space," unlike the plain block-level WebPgeContainer
above where auto+max-width already works correctly. Without an
explicit 100%, these collapse to near-zero width -- and, since
aspect-ratio is applied below, near-zero height right along with
it. */
div.BookContainer
{
width: min(calc(100% - 13.3em), 73.05em);
height: auto;
}
div.BookPageContainer,
div.BookPageContainerL2
{
width: 100%;
max-width: 73.05em;
height: auto;
}
img.BkPageBkgrnd
{
width: 100%;
height: 100%;
}
/* Fixed, simple em values, matching book.css's own original absolute
numbers -- these are small decorative bands (page title, footer
text/page number), not something that needs to track content
height the way the iframe area below does. */
div.BookPageHdr,
div.BookPageFtr
{
height: 3.6em;
}
/* auto, not a percentage -- BookPageContainerL2 no longer has a
fixed, aspect-ratio-driven height for a percentage to resolve
against. This grows to contain whatever height its own children
(BookPageContent/BookPageMarg below) actually need, which
ultimately traces back to the iframe's own real, JS-measured
content height. */
/* book.css floats BookPageMarg/BookPageContent side by side, then
tries to center each of them individually with margin:auto -- the
exact same broken pattern as WebPgeContainer's fixed margin-left
(see the note above div.WebPgeContainer's own margin fix): margin:
auto has NO effect on a floated element in any browser, so this
was silently doing nothing, at every width, the whole time. It
went unnoticed on desktop because the three children (91.03% +
4.24% + 4.24% = 99.51%) happen to fill nearly the entire row
regardless of how they're positioned within it -- but at mobile
width, confirmed via direct measurement, BookPageMarg's own
left edge and BookPageContent's left edge landed at the exact same
x-position (fully overlapping) instead of sitting side by side,
leaving the real gap unused on the right instead. display:flex
replaces the float+ineffective-margin:auto combination with a
layout model where percentage widths and ordering both work
correctly and predictably -- the same fix already used elsewhere
on this site (the WWAT quote-browser section, the Total Pages
bar) for exactly this class of legacy-float problem. */
div.BookPageContentContainer
{
display: flex;
height: auto;
}
/* Same reasoning -- auto instead of a percentage, growing to fit
real content instead of a fraction of a fixed ratio. */
div.BookPageContent,
div.BookPageMarg
{
height: auto;
}
/* 66.5em / 73.05em and 3.1em / 73.05em, both relative to
BookPageContentContainer's own now-100%-of-BookContainer width --
div.BookPageContent's real parent for width purposes. WIDTH is
unaffected by the height decoupling above -- these stay exactly
as they were. */
div.BookPageContent
{
width: 91.03%;
}
div.BookPageMarg
{
width: 4.24%;
}
/* width still fills its parent, same as before. No CSS height here
at all now -- the iframe's real height is set directly, in px, by
the 'load' listener in bkframe.shtm's appInit(), measured from its
own actual content each time a chapter page loads. An inline style
set by JS always wins over any CSS rule regardless, so a CSS
height here would just be dead weight. */
iframe.BookIFrame
{
width: 100%;
}
/* Header/footer text and page number — same "graphic scales, text
doesn't" fix as everywhere else. 1.33em was already tracking
body's font-size clock, same as ordinary body text — left as-is,
NOT converted to cqw, since these sit in a fixed-height band
whose own height is already tracking the page graphic via the
percentage rule above; only genuinely-graphic-relative offsets
(margin-right, pushing the text in from the page's right edge)
need the width-tracking fix here. 1.46em / 73.05em = 2%. */
p.BookPageHdrTxt,
p.BookPageFtrTxt
{
margin-right: 2%;
}
/* 72.5em / 73.05em and 55em / 72.5em (BookNavBtns' real parent is
BookNavPanel, not BookContainer directly).
clear:left is the real fix, not the width alone -- book.css's own
navCreate() JS writes this panel as a SECOND float:left sibling of
BookPageContainer, with no clear property at all. Two floats with
no clear either sit side by side (if they both fit) or wrap to a
new line (if they don't) -- book.css's original numbers happened
to make it just barely too wide to fit beside BookPageContainer,
so it wrapped correctly by coincidence, the exact same kind of
fragile near-exact fit that already broke once above (LeftColumn +
BookContainer). clear:left makes the wrap unconditional instead of
width-dependent -- it always starts on its own line below the book
page, regardless of how close the numbers happen to land at any
given viewport width. */
/* display:flex here does two things at once, 2026-08-28: lays the
page-count label (below) out on the same line as the button group
with the label pinned left and the buttons taking the rest of the
row, AND (via flex-wrap) lets that whole row drop the button block
to its own line if there isn't room for both side by side --
Mitch's own call, moving the page count out of the label-first
design this file used before and into a compact "N Pages" tag on
the selector bar itself. */
div.BookNavPanel
{
clear: left;
width: 99.25%;
height: auto;
display: flex;
align-items: center;
flex-wrap: wrap;
gap: 0.4em;
}
/* A small badge instead of plain text -- the first version (plain
Tahoma bold, sized like the old tiny status caption it replaced)
worked correctly through every resize but read as an afterthought
next to the button row, per Mitch's own call ("too inocuous").
Background/border colors are ones already used elsewhere on this
site (#EDF1FC/#C1D4E9 -- the same pair as the mobile nav-menu
cards), not new ones invented for this. font-size in em, not its
own px clamp, so it scales directly off body's own clamp() like
the rest of the outer page -- 1.1em roughly matches the button
labels' own 1.15em (nav_panel.css), so the badge reads as a real
companion to the selector rather than a differently-scaled label
next to it. Never stretches or shrinks (flex-shrink:0) -- it
always sits at its own natural size at the left edge of the bar. */
p.BookNavPagesLabel
{
margin: 0;
flex-shrink: 0;
white-space: nowrap;
font-family: Tahoma;
font-weight: bold;
font-size: 1.1em;
color: #21488C;
background-color: #EDF1FC;
border: 0.1em solid #C1D4E9;
border-radius: 0.3em;
padding: 0.3em 0.6em;
}
/* BookContainer's own height was collapsing to near-zero -- book.css
never gave it a clearfix, and its only children (BookPageContainer,
BookNavPanel) are both float:left, which don't contribute to a
plain block parent's auto height at all. This didn't break
anything visually in the one specific case tested (a floated
child still paints in its normal position even when its parent's
own box collapses around it), but it meant BookContainer's real
footprint was never actually correct -- anything relying on it
(this shell's own dynHeight.js height-matching between
BookContainer and LeftColumn chief among them) was working by
accident, not by design. overflow:hidden is the standard fix --
it gives BookContainer a new block formatting context, which
correctly grows to contain its floated children's real height. */
div.BookContainer
{
overflow: hidden;
}
/* flex:1 (not a fixed percentage) -- this block now shares its row
with p.BookNavPagesLabel (above), so its real available width
varies with however much room the label leaves, not a constant
fraction of BookNavPanel. min-width:0 is the standard fix for
flex's own "won't shrink below content's natural minimum" trap,
the same pattern already used elsewhere in this file. */
div.BookNavBtns
{
flex: 1;
min-width: 0;
}
/* The actual fix for "the selector splits, but the split rows aren't
centered" -- book.css's own navCreate() JS writes every button as
a plain float:left div with no wrap-centering logic at all (see
nav_panel.css). Floats that wrap when they run out of room always
start the new row flush left; there's no float-based way to center
a wrapped row. display:flex + flex-wrap replaces the float
mechanism entirely -- flex items ignore any float set on them, so
nav_panel.css's own float:left doesn't need to be touched -- and
justify-content:center centers EVERY row the buttons wrap into,
not just the first one. flex-shrink:0 on the buttons themselves
keeps each one at its original fixed width instead of letting flex
squeeze them to fit -- wrapping to a new row is the intended
behavior here, shrinking the buttons themselves was never wanted. */
div.UniBtns.NavPanel
{
display: flex;
flex-wrap: wrap;
justify-content: center;
}
.NavPanel div
{
flex-shrink: 0;
}
/* ============================================================
Mobile nav toggle — a hidden checkbox + label, pure CSS, no
JavaScript. The checkbox/label markup is inserted as the
first children of div.LeftColumn on each page, immediately
before the #include that pulls in the shared nav panel
(includes/panel_common.shtm) — so the panel's own output
(three .CommonPanelContainer blocks) are true CSS siblings of
the checkbox, which is what the :checked ~ selector below
depends on.
============================================================ */
.NavToggleCheckbox
{
display: none;
}
/* position:absolute, not fixed — anchored to div.WebPgeContainer (made
a positioning context below, mobile-only) instead of the raw
viewport. This is the real fix for both the earlier positioning
guesswork AND the scroll behavior: fixed anchors to the viewport, so
the button stays glued to the same spot on screen forever, floating
over whatever content scrolls underneath it. Absolute anchors to the
header's own box instead, so the button is genuinely PART of the
header (like the logo or banner) and scrolls away together with it,
the way a normal, non-sticky hamburger icon actually behaves. Since
WebPgeContainer's own margin sits OUTSIDE its box (children position
relative to its inner edge, unaffected by its own external margin),
this also removes the need to separately guess-compensate for that
margin — top:0.6em now means exactly what it says, measured from
where the header itself actually starts.
Background changed from the site's primary blue (#21488C) to white
with blue bars (inverted) — the original fill was too close to the
dark banner's own dominant color to read as a distinct button.
top/right are cqw, not em — the same "graphics scale, offset
doesn't" mismatch as Freedom Clock and the header title: the banner
around the button scales directly with the header's actual WIDTH (a
wide range), while an em-based offset only scales with body's
font-size (deliberately capped to a much narrower range) — so the
two drift apart as the window resizes, which is what "moves down as
the browser shrinks" actually was. cqw ties the offset to
WebPgeContainer's own current width directly, the same thing the
banner is already scaling from, so they move together.
width/height are ALSO cqw now, not em — the offset alone wasn't
enough: with the icon's own size still tied to the font-size clock
while the header keeps shrinking on the width clock, the icon stays
roughly the same physical size as the header shrinks around it,
which means it effectively grows relative to the header and pushes
further down into it, even though its top edge was correctly
scaling. The whole icon needs to shrink together with the header,
not just its position.
These cqw values are calibrated against ~660px — WebPgeContainer's
own actual width right at the 42em/672px breakpoint, where the icon
first appears and its original em-based size (2.6em/2.2em, already
confirmed correct) was tuned. My first attempt used 375px as the
reference instead — a guess, not tied to anything real — which made
every value come out at roughly double its correct size, since 375
is roughly half of 660. That's what "bigger than ever" was. */
.NavToggleLabel
{
display: none; /* shown only inside the mobile breakpoint below */
position: absolute;
top: 0.91cqw;
right: 0.91cqw;
width: 3.9cqw;
height: 3.3cqw;
z-index: 1000;
cursor: pointer;
background-color: #ffffff;
border: 0.1em solid #21488C;
border-radius: 0.45cqw;
box-shadow: 0 0.1em 0.3em rgba(0, 0, 0, 0.4);
}
/* The three bars used to be built from three separate CSS box elements
(a span plus its own ::before/::after pseudo-elements), each sized
independently as a percentage. Thin lines like that get rounded to
whole device pixels by the browser at render time, and since each of
the three was rounded SEPARATELY, they could drift out of sync with
each other at certain sizes — occasionally 1px, occasionally 2px,
independently per bar — which is what "the bars change height" as
you resized actually was. A single inline SVG (in the HTML markup,
replacing the old empty ) draws all three bars as one
cohesive vector graphic instead — the browser's SVG renderer scales
the whole viewBox as one unit, so the three bars stay in the same
fixed proportion to each other at every size, with no per-element
rounding to drift apart. The icon's own overall size (this rule) is
still cqw, same as before — only the INTERNAL construction of the
three bars changed. */
.NavToggleIcon
{
display: block;
width: 100%;
height: 100%;
fill: #21488C;
}
/* ============================================================
Mobile breakpoint — below this, stack the two columns and
switch the left nav to the hamburger toggle. 42em (~420px) is
a starting point, not a fixed law — adjust this one number if
it doesn't feel right once you're actually looking at it on a
real phone or a narrow window.
============================================================ */
@media (max-width: 42em)
{
div.LeftColumn,
div.RightColumn,
div.BookContainer
{
float: none;
width: 100%;
border-left: none;
}
/* The containing block for the button and panel below — see the
long comment on .NavToggleLabel for why this needs to be
position:relative rather than left at its default static.
div.LeftColumn ALSO has position:relative, in the original,
unmodified desktop CSS — since the checkbox/label/panel are
DOM descendants of LeftColumn, that intercepts the containing-
block search before it ever reaches WebPgeContainer, which is
why the button vanished on the first attempt at this — it was
actually positioning relative to LeftColumn (wherever that
currently sits in the stacked mobile layout, nowhere near the
header) instead. Overriding it to static here, mobile-only,
removes it from being a candidate at all, letting the button
and panel correctly resolve to WebPgeContainer. LeftColumn's
own position:relative was never doing anything visible on its
own (it had no top/left offsets) — this only changes which
ancestor ITS descendants anchor to, nothing about how
LeftColumn itself looks. */
div.WebPgeContainer
{
position: relative;
container-type: inline-size;
}
div.LeftColumn
{
position: static;
}
.NavToggleLabel
{
display: block;
}
/* A real dropdown menu, not the desktop nav content just
revealed inline (which pushed the whole page down and looked
like a plain gap rather than a menu). div.NavMenuPanel wraps
all three CommonPanelContainer blocks (added once in the
shared includes/panel_common.shtm, so it applies to every
page automatically). Hidden by default; when shown, it's
position:absolute — anchored to the header (WebPgeContainer),
same reasoning as the button itself: it scrolls away together
with the header instead of floating fixed over the page. */
div.NavMenuPanel
{
display: none;
}
.NavToggleCheckbox:checked ~ .NavMenuPanel
{
display: block;
position: absolute;
top: 4.4cqw;
right: 0.91cqw;
width: fit-content;
z-index: 999;
max-height: calc(100vh - 4.4cqw);
overflow-y: auto;
box-sizing: border-box;
background-color: #EDF1FC;
border: 0.15em solid #C1D4E9;
border-radius: 0.3em;
box-shadow: 0 0.3em 0.6em rgba(0, 0, 0, 0.25);
padding: 0.5em 1em;
}
/* Each of the three sections gets its own light card inside the
panel, so "Content"/"Who is ST?"/"Contact" read as distinct
groups rather than one undifferentiated list — the original
graphic sprite buttons stay exactly as they are, at their
normal fixed size, just stacked one under another instead of
floating side by side and wrapping unpredictably. width:
fit-content on both the panel and each card, instead of 100%,
is what lets the whole menu size itself to the actual button
width rather than stretching edge to edge. */
.NavToggleCheckbox:checked ~ .NavMenuPanel .CommonPanelContainer
{
width: fit-content;
box-sizing: border-box;
background-color: #ffffff;
border: 0.1em solid #C1D4E9;
border-radius: 0.3em;
margin: 0 auto 0.5em auto;
padding: 0.5em 0.8em;
}
.NavToggleCheckbox:checked ~ .NavMenuPanel .CommonPanelContainer:last-child
{
margin-bottom: 0;
}
div.NavMenuPanel .CommonPanel div
{
float: none;
margin: 0 auto 0.3em auto;
}
div.NavMenuPanel .CommonPanel div:last-child
{
margin-bottom: 0;
}
/* The big blank gap before "Content"/"Contact": these captions
had a huge top margin (4.5em/5em) in the original design,
tuned to visually align the left column against the tall
banner/Freedom Clock area it used to sit BESIDE on desktop.
Once the column stacks above the page content instead of
beside it, that offset has nothing left to align against —
it's just dead space. */
p.ContentPanelCaption,
p.ContactPanelCaption
{
margin-top: 0.3em;
}
}