/**
 * ux-overrides.css
 *
 * Additive layer on top of Sitely's own site.*.css. Never edit
 * site.faa4f4.css / site.92723c.css directly -- Sitely regenerates those
 * on every republish and any hand edit there gets silently reverted (see
 * README notes on the postal-to-email revert incident). This file is NOT
 * Sitely-owned, so it survives republishing untouched.
 *
 * Load this AFTER site.*.css on every page.
 */

/* ── Mobile scaling stopgap ──────────────────────────────────────────────
 * Sitely's canvas is a fixed 1200px absolute-positioned layout
 * (body{min-width:1200px} in site.*.css, cumulative negative-margin
 * positioning throughout). There is no way to make that reflow into a
 * true mobile layout without rebuilding the Sitely canvas itself -- that
 * is a design-tool job, not a CSS-override job, and is out of scope here.
 *
 * What this DOES do: shrink the whole 1200px canvas down to fit the
 * viewport using `zoom`, so phones get a legible, non-scrolling,
 * non-pinch-required view instead of a horizontally-scrolling 1200px
 * page. Text gets proportionally smaller rather than reflowing -- this
 * is a stopgap that kills the "unusable on mobile" problem, not a
 * mobile-optimised redesign.
 *
 * `zoom` (not `transform:scale`) is used deliberately: this codebase's
 * own smooth-scroll script already reads
 * getComputedStyle(document.body).getPropertyValue('zoom') for its
 * scroll-position math (see popup.*.js / inline anchor-scroll handlers).
 * `transform:scale` would NOT be picked up by that math and would throw
 * off anchor-jump scrolling on mobile. `zoom` is.
 *
 * Fixed tiers rather than a fluid calc() -- deliberately simple and
 * predictable rather than a pixel-perfect fit. Revisit if/when the
 * canvas itself gets a real responsive rebuild.
 *
 * Browsers without `zoom` support (very old Firefox) simply fall back to
 * the current (pre-existing) behaviour -- no worse than baseline today.
 */
@media (max-width: 480px) {
  body { zoom: 0.34; }
}
@media (min-width: 481px) and (max-width: 768px) {
  body { zoom: 0.55; }
}
@media (min-width: 769px) and (max-width: 1024px) {
  body { zoom: 0.78; }
}
@media (min-width: 1025px) and (max-width: 1200px) {
  body { zoom: 0.92; }
}

/* ── Heading-tag safety net ──────────────────────────────────────────────
 * A handful of Sitely-exported <p class="..."> elements are being
 * promoted to real <h1>/<h2> for screen-reader / SEO structure (see
 * index.php, verification.php). Their Sitely classes (.p1/.f8 etc.)
 * already fully specify font-family/size/weight/line-height/color, so
 * the only visual risk is the browser's default h1-h6 margin -- zero it
 * out here so a tag-name swap is a pure no-visual-diff semantic change.
 */
h1, h2, h3, h4, h5, h6 {
  margin: 0;
  padding: 0;
  font: inherit;
}