@import url('https://fonts.googleapis.com/css2?family=Varela+Round&display=swap');
/* verified: original html{font-family:'Varela Round';font-weight:400} applies
   to BOTH body copy and headings — there is no separate heading typeface,
   and headings are regular weight (400), not bold. Google only ships this
   font at weight 400; the browser will synthetically embolden <strong>/<b>,
   same as it would on the original site. */

html { scroll-behavior: smooth; } /* verified: original CTA links use uk-scroll (smooth in-page scroll) to #chiro/#physical/#neuro */

:root {
    --primary:   #4A91FD; /* brand blue — verified against original compiled CSS: --bs-primary / .uk-section-primary bg */
    --accent:    #1ED482; /* --bs-green / --bs-success — NOT used as a visible accent anywhere on the real homepage, kept for other pages */
    --dark:      #363636; /* verified: original h1-h6{color:#363636} */
    --body-text: #666666; /* verified: original html{color:#666} / body copy color, distinct from heading color */
    --light-text: rgba(255,255,255,.8); /* verified: original .uk-light body text color (dark/hero sections) */
    --bg-alt:    #F8F8F8;
    --fog:       #E5E5E5;
}

body, .et_pb_text_inner p {
    font-family: 'Varela Round', sans-serif;
    color: var(--body-text);
}

/* verified: global theme rule `em{color:#4dc36b}` — every <em> tag on the
   real site renders in this green, not inherited body/paragraph gray. Easy
   to miss because it's a bare-tag rule with no distinguishing class name;
   caught only by grepping literally for `em{color` rather than for
   specific green hex values already suspected. Site-wide, not page-specific
   (affects the About page's testimonial quotes and insurance-credential
   line, and any future page with italicized emphasis text). */
em { color: #4dc36b; }
/* verified real base rule: blockquote{margin:0 0 20px 0;font-size:20px;
   line-height:1.7;font-style:italic;color:#363636;font-weight:400}. Note:
   nested <em> tags inside a blockquote still render via the global em rule
   above (a direct rule always wins over an inherited value), so quoted
   video transcripts etc. render in the green em color, not blockquote's
   own dark color — verified this is really how the source behaves too,
   not a bug to special-case around. */
blockquote { margin: 0 0 20px; font-size: 20px; line-height: 1.7; font-style: italic; color: var(--dark); font-weight: 400; }

h1, h2, h3, h4, h5, h6,
.et_pb_module h1, .et_pb_module h2, .et_pb_module h3 {
    font-family: 'Varela Round', sans-serif;
    font-weight: 400; /* verified: original h1-h6{font-weight:400} — not bold */
    color: var(--dark); /* verified: original h1-h6{color:#363636}, distinct from #666 body copy */
}
/* verified real sizes for BARE (unclassed) h1-h6 tags — needed for article
   body content (about/services/issues pages etc.) which uses plain
   semantic headings, not the opt-in .site-h1-size/.site-h2-size classes
   built for Home's styled section headers. Without this, bare headings
   fall back to the browser's generic UA-stylesheet sizes instead of the
   real theme values. h1/h2 grow at the 960px breakpoint like elsewhere on
   this theme; h3-h6 are flat (no responsive scale-up in the source CSS). */
h1 { font-size: 35.7px; line-height: 1.2; }
h2 { font-size: 30.6px; line-height: 1.3; }
h3 { font-size: 24px; line-height: 1.4; }
h4 { font-size: 20px; line-height: 1.4; }
h5 { font-size: 16px; line-height: 1.4; }
h6 { font-size: 14px; line-height: 1.4; }
@media (min-width: 960px) {
    h1 { font-size: 42px; }
    h2 { font-size: 36px; }
}

.site-eyebrow {
    color: var(--primary);
    text-transform: uppercase;
    letter-spacing: 0.12em;
    font-weight: 700;
    font-size: 0.85rem;
}

.site-accent { color: var(--accent); }

.site-text-bold { font-weight: 700; } /* verified: .uk-text-bold{font-weight:700} — used on Rehabilitation's "Video Playlist:" h2 */

/* font sizes below are exact values pulled from the original compiled
   templates/yootheme/css/theme.1030c9.css — these grow at UIkit's `m`
   (960px) and `l`/`xl` (1200px) breakpoints, they do NOT start large and
   shrink on mobile. Base value = smallest (mobile) size. */
.site-hero-h1 { font-size: 42px; line-height: 1.1; font-weight: 400; color: #fff; } /* .uk-heading-medium */
@media (min-width: 960px)  { .site-hero-h1 { font-size: 3.5rem; } }
@media (min-width: 1200px) { .site-hero-h1 { font-size: 4rem; } }

/* Home hero background (home-hero-bg-blue.svg, 1920x1145) is sparse
   decorative artwork on a transparent/white canvas, not a full color fill —
   confirmed identical on the real live source site, which relies on the
   same background-size:cover crop with no phone-breakpoint handling either.
   On desktop's short/wide crop the visible sliver lands on the artwork's
   filled top ~73%, so white text (h1/bio/quote/h2 all color:#fff or
   var(--light-text)) reads fine against it. On mobile the same content
   stacks into a much taller column, cover crops down to a narrow vertical
   sliver of the SAME 1920-wide image, and part of that sliver can land on
   the transparent bottom ~27% — revealing the section's own white
   background-color underneath the white text (reported: unreadable on
   phone, fine on desktop). Fixing by giving the section a solid mobile-only
   fallback instead of touching the desktop-verified white background-color
   or the image itself. Color used is #37465c — not invented, it's the
   SVG's own dark-navy fill (see build_home.py HERO_BG_FALLBACK comment) —
   so it blends with whatever part of the artwork is still visible rather
   than introducing an unrelated color. !important needed: Divi renders
   background_color as a scoped inline <style> rule for the section's
   module ID, which normally beats an external stylesheet class alone. */
@media (max-width: 767px) {
    .site-home-hero.et_pb_section { background-color: #37465c !important; }
}

/* Divi's global preset rule `.mobile_menu_bar:before{color:#4A91FD}` (in the
   et-critical-inline-css block, unscoped by menu instance) colors every
   hamburger icon on the site, including the Home page's own transparent
   overlay nav (et_pb_menu_0, distinct from the sitewide et_pb_menu_0_
   tb_header used on other pages) sitting on the hero image. Scoped to just
   .site-home-hero so the sitewide header's hamburger (other pages) is
   untouched. */
.site-home-hero .mobile_menu_bar:before { color: #fff !important; }

/* Home's hero menu (et_pb_menu_0) sets background_color="rgba(255,255,255,0)"
   in the shortcode for the transparent desktop overlay bar. Divi reuses that
   same transparent value for BOTH dropdown types (deferred CSS):
   `.et_pb_menu_0.et_pb_menu .nav li ul,.et_pb_menu_0.et_pb_menu .et_mobile_
   menu,.et_pb_menu_0.et_pb_menu .et_mobile_menu ul{background-color:rgba(
   255,255,255,0)!important}` — `.nav li ul` is the DESKTOP hover-dropdown
   submenu (this menu has real parent/child items, e.g. Issues/Solutions),
   `.et_mobile_menu`(+ its own nested ul) is the mobile hamburger panel.
   First pass only covered the mobile selectors and missed `.nav li ul`,
   so desktop submenu flyouts were still showing transparent. Needs an
   extra ancestor class to out-specificity that rule; scoped to
   .site-home-hero so only Home's dropdowns change, not the sitewide
   tb_header menu on other pages. */
.site-home-hero .et_pb_menu_0.et_pb_menu .nav li ul,
.site-home-hero .et_pb_menu_0.et_pb_menu .et_mobile_menu,
.site-home-hero .et_pb_menu_0.et_pb_menu .et_mobile_menu ul { background-color: #fff !important; }

/* Dropdown backgrounds above are now solid white — the menu's top-level
   nav text stays white (readable against the transparent overlay bar), but
   that same white was inherited into the dropdown submenu/mobile-panel
   links too (background_layout="dark" light-text styling wasn't scoped to
   just the top level), which is unreadable against the new white panels.
   Matches the sitewide #mobile_menu1 li a{color:#777} convention already
   used elsewhere on the site. */
.site-home-hero .et_pb_menu_0.et_pb_menu .nav li ul a,
.site-home-hero .et_pb_menu_0.et_pb_menu .et_mobile_menu a { color: #777 !important; }

.site-h1-size { font-size: 35.7px; line-height: 1.2; font-weight: 400; } /* .uk-h1 / plain h1 */
@media (min-width: 960px) { .site-h1-size { font-size: 42px; } }

.site-h2-size { font-size: 30.6px; line-height: 1.3; font-weight: 400; margin: 40px 0; } /* .uk-h2 + uk-margin-medium (40px, verified flat/non-responsive) */
@media (min-width: 960px) { .site-h2-size { font-size: 36px; } }

/* .site-section-h2 kept as an alias of the uk-h1 size — every homepage
   heading except "Explore Your Pain Relief..." (uk-h2) uses this size. */
.site-section-h2 { font-size: 35.7px; line-height: 1.2; font-weight: 400; }
@media (min-width: 960px) { .site-section-h2 { font-size: 42px; } }

/* verified: original .uk-button — pill shaped, NOT bold, NOT a small chip.
   padding 0 38px / line-height 46px / font-size 14px / letter-spacing .5px /
   border-radius 500px (full pill). .uk-button-large bumps padding/line-height
   only (chiro/physical/braincore anchor buttons under the hero).
   Blog/legal audit pass (2026-08-19): body content ported verbatim from
   blog post HTML (hub excerpts AND individual WP posts, via build_blog_
   hub_pages.py / build_blog_posts.py) keeps the ORIGINAL literal
   `class="uk-button uk-button-large"` etc. from the source markup — it is
   never rewritten to `.site-btn`. Without a rule for the literal `.uk-
   button*` classes those inline CTAs (e.g. "Read More.." / "Click here to
   watch..." links inside several teaching/main posts) rendered as bare
   unstyled links instead of pill buttons. Fixed by aliasing the literal
   classes onto the same verified ruleset rather than duplicating it. */
.site-btn, .uk-button {
    display: inline-block;
    padding: 0 38px;
    line-height: 46px;
    border-radius: 500px;
    font-size: 14px;
    font-weight: 400;
    letter-spacing: 0.5px;
    text-transform: none;
    text-decoration: none;
    border: 2px solid transparent;
    box-sizing: border-box;
    background:#e9e9ed;
    color: #4a91fd; /* verified: real .uk-button{color:inherit} sits AFTER the
        page's generic a{color:#4a91fd} in the cascade, so a bare uk-button
        link (no -primary/-default modifier) deliberately overrides back to
        its surrounding text color (#666 body gray) instead of link-blue.
        Without this, Divi's own global a{color:#4A91FD} — which loads after
        this stylesheet — was winning instead, showing these as blue links. */
    transition: .2s ease-in-out;
    transition-property: color, background-color, background-position, background-size, border-color, box-shadow;
}
.site-btn-large, .uk-button-large { padding: 0 54px; line-height: 54px; }
.site-btn-primary, .uk-button-primary {
    background-color: var(--primary); color: #fff;
    background-image: linear-gradient(45deg, var(--primary) 40%, #7cb0fe); /* verified: original .uk-button-primary gradient */
}
.site-btn-primary:hover, .uk-button-primary:hover { box-shadow: 0 8px 20px rgba(74,145,253,.35); }
/* .uk-button-default — outline button used for the single "click here to
   contact us" CTA; verified light variant (on white) vs the .uk-light
   override (on the blue "Are You Ready" section) are different color sets. */
.site-btn-default, .uk-button-default { background-color: transparent; color: var(--dark); border-color: #edecec; }
.site-btn-default:hover, .uk-button-default:hover { border-color: var(--primary); color: var(--primary); }
.site-btn-default.site-btn-on-dark { color: #fff; border-color: #fff; }
.site-btn-default.site-btn-on-dark:hover { color: #fff; border-color: #fff; opacity: .85; }
/* .uk-button-secondary (real source: green gradient) — not observed in the
   3-4 spot-checked posts during the blog audit, but real CSS exists for it
   (verified via theme.*.css) and ported content may contain it elsewhere
   across the ~56 posts; added defensively rather than waiting to find one. */
.uk-button-secondary {
    background-color: #4dc36b; color: #fff;
    background-image: linear-gradient(45deg, #4dc36b 40%, #74da7d);
}
.uk-button-secondary:hover { background-color: #3eb85d; background-image: linear-gradient(45deg, #43cd4f 40%, #94e29b); box-shadow: 0 0 30px 0 rgba(17,255,78,.5); } /* verified exact hover values via brace-depth parse */

.site-hero-btns { display: flex; gap: 16px; justify-content: center; flex-wrap: wrap; margin-top: 24px; }

/* ── Mobile sticky CTA bar ─────────────────────────────────────────── */
.pprc-mobile-cta {
    display: none;
    position: fixed;
    bottom: 0; left: 0; right: 0;
    z-index: 9999;
    background: var(--dark);
    padding: 10px 14px;
    justify-content: space-between;
    align-items: center;
    box-shadow: 0 -4px 16px rgba(0,0,0,.2);
}
.pprc-mobile-cta a {
    color: #fff;
    font-weight: 700;
    text-decoration: none;
    font-size: 0.95rem;
}
.pprc-mcta-btn {
    background: var(--primary);
    padding: 10px 20px;
    border-radius: 4px;
}
@media (max-width: 767px) {
    .pprc-mobile-cta { display: flex; }
    body { padding-bottom: 64px; }

    .site-btn {
      padding: 10px 38px;
      line-height: 20px !important;
    }
}

/* ── Scroll reveal ─────────────────────────────────────────────────── */
.site-reveal            { opacity:0; transform:translateY(28px);
                          transition: opacity .65s cubic-bezier(.16,1,.3,1), transform .65s cubic-bezier(.16,1,.3,1); }
.site-reveal.is-visible { opacity:1; transform:translateY(0); }

@media (prefers-reduced-motion: reduce) {
    *, *::before, *::after { animation-duration:.01ms !important; transition-duration:.01ms !important; }
}

/* ── Stat counters (for "25+ years" style, not natively supported by Divi counter) ── */
.site-stat { text-align: center; padding: 20px; }
.site-stat-num { display: block; font-family: 'Varela Round', sans-serif; font-size: 3rem; font-weight: 400; color: var(--primary); }
.site-stat-label { display: block; font-size: 0.9rem; color: var(--dark); text-transform: uppercase; letter-spacing: 0.06em; margin-top: 4px; }

/* verified real px values for YOOtheme's width utilities, used repeatedly
   across the homepage to cap/center text blocks — a previous build left
   most of these unconstrained, so on wide viewports text stretched full
   column/container width instead of the original's narrower centered
   columns. */
.site-width-2xl { max-width: 750px; margin-left: auto; margin-right: auto; } /* .uk-width-2xlarge */
.site-width-xl  { max-width: 600px; margin-left: auto; margin-right: auto; text-align: center; } /* .uk-width-xlarge, mobile-first center */
@media (min-width: 960px) { .site-width-xl { text-align: left; } } /* uk-text-left@m */

/* verified: original `.uk-margin-xlarge{margin-bottom:70px}` at mobile base,
   overridden to 140px only at the (min-width:1200px) breakpoint — NOT 960px
   like the section-large padding nearby (checklist item 10: never assume a
   breakpoint from a neighboring rule). Used 3x on Home for the gap before
   each of the 2nd/3rd feature rows and before the final "Are You Ready" CTA
   block. Divi renders custom_padding as an inline style, so this needs
   !important to win over it. */
.site-gap-xlarge { padding-top: 70px !important; }
@media (min-width: 1200px) { .site-gap-xlarge { padding-top: 140px !important; } }

/* verified via brace-depth parse of theme.*.css: article-style pages
   (Symptoms, Services hub — same pattern as About) wrap their content in
   `<main class="tm-main uk-section uk-section-default uk-padding-remove-top">`.
   `.uk-section` (plain, not -large) is padding-top:40px/padding-bottom:40px
   base, 70px/70px @960px (NOT @1200 — different breakpoint family from the
   uk-margin-* utilities above, checklist item 11) — but
   `.uk-padding-remove-top{padding-top:0!important}` zeroes the TOP side on
   every one of these pages. Real visual top gap above the H1 comes entirely
   from .site-article-title's own margin-top (40px/70px@1200), not from any
   section padding. A previous pass shipped a flat 70px|70px Divi
   custom_padding on these sections, which double-counted the top gap
   (70px section pt + 40-70px h1 margin-top stacked = up to 140px where
   real is 40-70px) and used the wrong flat 70px for the bottom instead of
   the real 40/70@960 pair. Apply this class (via `module_class` on the
   et_pb_section, with NO pt/pb passed to section() so no inline
   custom_padding competes) instead of hardcoding pt="70px" pb="70px". */
.site-gap-section { padding-top: 0 !important; padding-bottom: 40px !important; }
@media (min-width: 960px) { .site-gap-section { padding-bottom: 70px !important; } }

/* verified via brace-depth parse: hub/category-listing pages (Issues hub,
   Testimonies hub, testimony category hubs like /testimonies/chiropractic/)
   wrap their content in `<main class="tm-main uk-section uk-section-default">`
   — NOT uk-padding-remove-top (confirmed: that class is present on individual
   article/issue/testimony pages but genuinely absent on the hub-listing
   pages' <main> tag). So unlike .site-gap-section above, hubs get the full,
   symmetric plain .uk-section padding on both sides: 40px base -> 70px@960.
   A previous pass reused the same flat pt=70px|pb=70px on hub sections too
   (technically correct at desktop >=960 by coincidence, since uk-section's
   960px value is also 70, but 30px too much on each side below 960px). */
.site-gap-section-hub { padding-top: 40px !important; padding-bottom: 40px !important; }
@media (min-width: 960px) { .site-gap-section-hub { padding-top: 70px !important; padding-bottom: 70px !important; } }

/* ── Homepage: hero bio + floated portrait ───────────────────────────── */
/* verified against original compiled CSS: .uk-light context => body text
   rgba(255,255,255,.8), headings/blockquote #fff, links #fff (not primary blue) */
/* verified: original bio wrapper carries `uk-margin-medium` (40px, flat/
   non-responsive) — the previous `margin:0 auto` dropped this vertical gap
   entirely, leaving the hero heading and bio copy jammed together. Only
   margin-top is set (bottom:0) — see the "top-margin-only" note on
   .site-quote-center below for why cross-module Divi gaps are each set in
   exactly one place instead of relying on margin-collapse across separate
   et_pb_code/et_pb_text module wrappers. */
.site-hero-bio { max-width: 750px; margin: 40px auto 0; text-align: left; color: var(--light-text); }
.site-hero-bio::after { content: ""; display: table; clear: both; }
.site-hero-portrait { float: right; margin: 0 0 20px 24px; text-align: right; max-width: 263px; }
.site-hero-portrait img { width: 100%; height: auto; border-radius: 8px; }
.site-hero-portrait figcaption { font-size: 0.82rem; color: var(--light-text); margin-top: 8px; line-height: 1.4; }
.site-hero-portrait figcaption a { color: #fff; text-decoration: underline; font-weight: 600; }
.site-hero-bio p { margin: 0 0 1em; line-height: 1.7; }
.site-hero-bio a { color: #fff; font-weight: 600; text-decoration: underline; }
@media (max-width: 600px) {
    .site-hero-portrait { float: none; margin: 0 auto 20px; text-align: center; }
}

/* ── Homepage: pull-quote ────────────────────────────────────────────── */
/* verified: original `blockquote{font-size:20px;line-height:1.7;font-style:
   italic;color:#363636}` — plain, no box/border. Default alignment is LEFT
   (the 3 feature-section quotes have no centering wrapper at all); only the
   hero quote and the "Are You Ready" quote sit inside an explicit
   uk-text-center container, hence .site-quote-center below. */
.site-quote { max-width: 750px; margin: 20px 0; padding: 0; border: none;
    background: none; font-style: italic; color: var(--dark); line-height: 1.7; font-size: 20px; text-align: left; }
.site-quote.site-quote-dark { color: #fff; }
/* verified: the hero + "Are You Ready" CTA quotes only (site-quote-center is
   never used on the 3 plain feature quotes) sit in their own real
   `uk-panel uk-margin uk-width-2xlarge` wrapper on the source — a 40px
   top gap distinct from the base .site-quote's 20px. Top-margin-only,
   same reasoning as .site-hero-bio above. */
.site-quote.site-quote-center { text-align: center; margin-left: auto; margin-right: auto; margin-top: 40px; margin-bottom: 0; }

/* ── Homepage: feature link buttons under hero ───────────────────────── */
/* verified: original wraps this button row in `uk-margin-xlarge` (70px
   base, 140px at real min-width:1200px breakpoint — same value/breakpoint
   as .site-gap-xlarge). Previous 8px margin-top dropped this almost
   entirely. */
.site-link-btns { display: flex; gap: 16px; justify-content: center; flex-wrap: wrap; margin: 70px 0; }
@media (min-width: 1200px) { .site-link-btns { margin: 140px 0; } }
@media (min-width: 960px) { .site-link-btns { justify-content: space-evenly; } }

/* verified: original "Learn More" (feature sections) and "Click here to
   contact us" (CTA) button wrappers both carry `uk-margin-large` (40px
   base, 70px at min-width:1200px) — was a flat 12-20px inline style. */
.site-gap-large { margin-top: 40px; }
@media (min-width: 1200px) { .site-gap-large { margin-top: 70px; } }

.site-hero-photo { margin-top: 70px; text-align: center; }
@media (min-width: 1200px) { .site-hero-photo { margin-top: 140px; } }

/* ── Homepage: alternating feature section ───────────────────────────── */
.site-feature-img img { width: 100%; height: auto; border-radius: 10px; display: block; }
/* verified: heading + copy + "Learn More" button are each individually
   capped at uk-width-xlarge (600px) and centered within their column — the
   blockquote between them is NOT (bare <blockquote>, no width class), so it
   runs the full column width while the text around it stays narrower. */
.site-feature-copy { max-width: 600px; margin: 0 auto; text-align: center; }
@media (min-width: 960px) { .site-feature-copy { text-align: left; } }
.site-feature-copy p { line-height: 1.7; margin: 0 0 1em; }

/* ── Homepage: 3-step process cards ──────────────────────────────────── */
/* verified against the real classes on these cards: `uk-card uk-card-default
   uk-card-large uk-card-body uk-width-large uk-margin-auto uk-text-left@m
   uk-text-center`. That's a 450px-wide (uk-width-large) box CENTERED inside
   its 1/3 column (not stretched full-width like the previous build had it),
   padding 40px 40px base -> 70px 70px at >=1200px (uk-card-large.uk-card-body),
   text centered on mobile / left-aligned from 960px up, and card text color
   is #666 (.uk-card-default{color:#666}), not a custom dark tone. */
/* CORRECTION: uk-width-large (450px) is a FIXED UIkit utility width, same
   tier as uk-width-xlarge(600)/2xlarge(750) used correctly unscaled
   elsewhere on this page — it does NOT scale proportionally with the
   container, so the previous 1080/1300 scale-down to 375px was the wrong
   category of fix (that ratio only applies to values computed AS a
   fraction of the container, like the decorative SVG background sizes
   below). Restored to the real 450px. In practice this cap rarely binds
   anyway — `width:100%` means the card fills its ~320-360px flex column
   on Divi's narrower 1080px container regardless of the max-width value;
   450px only matters on very wide viewports. Padding (28px mobile/40px
   desktop) genuinely IS container-independent (checklist item 3), left
   as-is. */
.site-step-card {
    background: #fff; border-radius: 10px; height: 100%;
    box-shadow: 0 10px 30px 0 rgba(0,0,0,.08);
    width: 100%; max-width: 450px; min-width: 0; margin: 0 auto;
    padding: 28px 26px; color: var(--body-text); text-align: center;
    box-sizing: border-box;
    /* the card is itself a flex item of .et_pb_code_inner (column-direction)
       — every OTHER link in this chain is explicitly `flex:1 1 auto`, but
       this one was left to the default `flex:0 1 auto` (no grow) and
       relied on `height:100%` alone to resolve as its flex-basis. Made it
       explicit instead of implicit — this is what was actually letting
       the 3 step cards render at their own natural (unequal) content
       height instead of stretching to match their row's tallest card. */
    flex: 1 1 auto;
}
@media (min-width: 1200px) { .site-step-card { padding: 40px 40px; } }
@media (min-width: 960px)  { .site-step-card { text-align: left; } }
/* verified: the "Step One" label (.el-meta) has NO dedicated style rule in
   the theme at all — it's plain inherited card text (#666, normal weight).
   A previous build invented a bold/uppercase/letter-spaced blue badge here;
   that treatment doesn't exist on the real site. */
.site-step-badge { color: var(--body-text); font-weight: 400; }
.site-step-card h3 { margin: 20px 0 0; font-size: 30.6px; line-height: 1.3; font-weight: 400; }
@media (min-width: 960px) { .site-step-card h3 { font-size: 36px; } } /* .uk-h2 */
/* verified: original title text sits in a <span class="uk-text-background">
   with a gradient background-clip:text fill — not plain dark text */
.site-step-card h3 .site-grad-text {
    -webkit-background-clip: text; background-clip: text; color: transparent; display: inline-block;
    background-image: linear-gradient(90deg, #4a91fd 0%, #7a4afd 100%);
}
.site-step-card p { margin: 20px 0 0; line-height: 1.6; font-size: 1rem; color: var(--body-text); }

/* ── Homepage: feature-photo decorative backgrounds ──────────────────── */
/* verified: these are the ACTUAL theme SVGs (home-features-bg-01/02.svg),
   used as background-image behind the chiro/braincore photos only (the
   spinal-decompression photo in between has no decorative background in
   the original). Copied verbatim into the child theme's images/ folder
   alongside home-hero-bg-blue.svg. Original inline sizes were 330x330 /
   410x410, computed against the original's 1300px container — same
   container-ratio mistake as the step cards. Divi's real .et_pb_column_1_2
   is 47.25% of its own 1080px container (~510px) vs. the original's wider
   ~600px+ half-column, so those raw sizes were scaled down by the same
   1080/1300 ≈ .83 ratio (330→274, 410→341) to keep the same proportion of
   column covered instead of reading oversized on the narrower column. */
/* no padding/centering here — original wraps the photo at full column
   width with no inset box; an earlier build invented a 30px pad to make
   room for a fake circle graphic, which just shrank/shifted the photo away
   from where the original actually places it. */
.site-feature-img { position: relative; }
.site-feature-img.site-blob-1 {
    background-image: url('https://precision.computingartisan.com/wp-content/themes/divi-child-precision/images/home-features-bg-01.svg');
    background-repeat: no-repeat; background-position: center left; background-size: 274px 274px;
}
.site-feature-img.site-blob-2 {
    background-image: url('https://precision.computingartisan.com/wp-content/themes/divi-child-precision/images/home-features-bg-02.svg');
    background-repeat: no-repeat; background-position: top left; background-size: 341px 341px;
}
.site-feature-img img { position: relative; z-index: 1; }

/* verified: original home-pricing-bg.svg sits behind the "Discovery Process"
   section as a real CSS background layer (uk-background-top-right, inline
   size 570x525) — layered as a background so it naturally sits behind the
   text/cards with no z-index gymnastics, same as the hero section's
   background_image. Divi's own background_size attribute only accepts
   cover/contain/initial, so this exact pixel size is applied via a plain
   CSS rule on the section's module_class instead. Original 570x525 was
   computed against the original's 1300px section width; Divi's equivalent
   full section here is 1080px (verified: .container{max-width:1080px}), so
   scaled down by the same 1080/1300 ≈ .83 ratio (570→473, 525→436) to
   cover the same proportion of the section instead of reading oversized. */
.site-process-section {
    background-image: url('https://precision.computingartisan.com/wp-content/themes/divi-child-precision/images/home-pricing-bg.svg');
    background-repeat: no-repeat; background-position: top right; background-size: 473px 436px;
}
@media (max-width: 960px) { .site-process-section { background-image: none; } }

/* ── Equal-height card rows (discovery-process cards + blog grid) ────── */
/* verified: original uses `uk-grid-match` (blog) / a `uk-flex uk-flex-column`
   + `uk-flex-1` column pairing (process cards) so every card in a row
   stretches to match its tallest sibling. `height:100%` on the card alone
   does nothing unless every ancestor down to it is also a stretching flex
   box — Divi's row/column/module wrappers are NOT that by default, so
   short-content cards were sizing to their own content instead of matching
   their row. This chain forces stretch all the way down. */
.site-equal-row.et_pb_row { display: flex; flex-wrap: wrap; }
/* min-width:0 on every link in this flex chain defeats flexbox's default
   min-width:auto, which otherwise refuses to shrink a flex item below its
   content's intrinsic width — with a 450px-wide card inside, that bug was
   forcing the whole column (and the row's 3-up layout) to overflow instead
   of shrinking the card down to fit its 1/3 track. */
.site-equal-row > .et_pb_column { display: flex; flex-direction: column; min-width: 0; }
.site-equal-row .et_pb_module.et_pb_code { display: flex; flex-direction: column; flex: 1 1 auto; min-width: 0; }
.site-equal-row .et_pb_code_inner { display: flex; flex-direction: column; flex: 1 1 auto; width: 100%; min-width: 0; }

/* ── Homepage: blog grid ─────────────────────────────────────────────── */
/* verified: cards use plain `uk-card uk-card-default` (no -small/-large
   modifier), so the real box-shadow is .uk-card-default's own
   `0 10px 30px 0 rgba(0,0,0,.08)` (same shadow value as .site-step-card,
   not an invented lighter one) and the real body padding is the
   UNMODIFIED `.uk-card-body{padding:40px 40px}`, which itself is
   overridden at the real min-width:1200px breakpoint to `60px 50px` —
   both were guessed too small (24px flat) in the previous build. */
.site-blog-card { background: #fff; border-radius: 10px; overflow: hidden; box-sizing: border-box;
    box-shadow: 0 10px 30px 0 rgba(0,0,0,.08); height: 100%; width: 100%; min-width: 0;
    display: flex; flex-direction: column; flex: 1 1 auto; }
.site-blog-card img { width: 100%; aspect-ratio: 900 / 400; object-fit: cover; display: block; }
.site-blog-card-body { padding: 40px 40px; display: flex; flex-direction: column; flex: 1; }
@media (min-width: 1200px) { .site-blog-card-body { padding: 60px 50px; } }
.site-blog-card h3 { font-size: 1.05rem; margin: 0 0 8px; line-height: 1.35; }
.site-blog-card .site-blog-date { font-size: 0.78rem; color: #888; text-transform: uppercase; letter-spacing: 0.05em; margin-bottom: 10px; }
.site-blog-card .site-blog-excerpt { font-size: 0.88rem; line-height: 1.6; color: var(--body-text); flex: 1; margin-bottom: 16px; }

/* verified: the real gap between the two wrapped blog-card rows comes from
   UIkit's `uk-grid` JS component adding `uk-grid-margin` to the first item
   of each new row — its base rule is `*+.uk-grid-margin{margin-top:30px}`,
   overridden to 40px only at real min-width:1200px (this specific grid has
   no `-large` modifier, so it's the plain 30/40 value, not the 40/70 used
   for the xlarge/large gaps elsewhere on this page). */
.site-gap-grid { padding-top: 30px !important; }
@media (min-width: 1200px) { .site-gap-grid { padding-top: 40px !important; } }

/* ── Article body content (about, services, issues, blog posts, etc.) ── */
/* verified: original wraps the article+sidebar in `uk-container-small`
   (max-width:900px) — its OWN standalone container preset, not a
   proportional value derived from the general 1300px container, so it's
   ported as an absolute px cap rather than the 1080/1300 ratio used
   elsewhere. Divi's own container already caps at 1080px; this narrows it
   further to match the source layout exactly. */
/* verified with a proper brace-depth CSS parse (not just "nearest preceding
   @media" text search, which had already caused one wrong-breakpoint bug
   this session): .uk-container-small is NOT a flat 900px cap. It's fluid —
   900px is only the base/mobile value; from 640px it becomes
   calc(50% + 420px), and from 960px calc(50% + 410px), growing roughly
   with the viewport instead of staying pinned at 900. Divi's own container
   (1080px) still naturally bounds this on top, since a child can't exceed
   its parent's box regardless of its own max-width. */
.site-container-small { max-width: 900px; margin-left: auto; margin-right: auto; }
@media (min-width: 640px) { .site-container-small { max-width: calc(50% + 420px); } }
/* capped with min() so the column stops growing past ~1100px on wide
   screens instead of continuing to expand with the viewport indefinitely —
   keeps generous, consistent side whitespace on wide monitors */
@media (min-width: 960px) { .site-container-small { max-width: min(calc(50% + 410px), 1100px); } }
/* .uk-article-title: real classes are `uk-margin-large-top
   uk-margin-remove-bottom uk-article-title` — margin-top 40px->70px@1200,
   margin-bottom 0 (NOT the 20px-bottom/0-top I had backwards before). The
   body wrapper below carries its own margin-top (uk-margin-medium-top,
   40px) to create the actual title-to-body gap. */
.site-article-title { font-size: 36px; line-height: 1.5; font-weight: 400; color: var(--dark); margin: 40px 0 0; }
@media (min-width: 960px) { .site-article-title { font-size: 42px; } }
@media (min-width: 1200px) { .site-article-title { margin-top: 70px; } }
/* Individual blog posts are native WP posts (single-post template), not a
   Divi-built page — build_blog_posts.py deliberately doesn't inject a
   second .site-article-title h1 into the body content (would double the
   real post_title). WordPress renders the real title via its own
   h1.entry-title instead, which Divi's core theme sizes generically
   (~26-30px, no site branding) rather than to this site's real article-
   title convention. Verified against a real source post
   (blog/teaching/74-is-texting-hurting-your-neck.html): the ORIGINAL site's
   post title carries the identical `uk-margin-large-top uk-margin-remove-
   bottom uk-article-title` classes as every other article page (legal/
   about/issues) — same size everywhere, not a smaller post-specific
   convention. This was a real sitewide deviation across all ~56 individual
   posts, found during the Blog/Legal/Sitemap audit pass (2026-08-19).
   Mirrors .site-article-title's exact values; body content's own
   .site-article{margin-top:40px} still supplies the title-to-body gap. */
.single-post .entry-title { font-size: 36px; line-height: 1.5; font-weight: 400; color: var(--dark); margin: 40px 0 0; }
@media (min-width: 960px) { .single-post .entry-title { font-size: 42px; } }
@media (min-width: 1200px) { .single-post .entry-title { margin-top: 70px; } }
/* individual testimonial pages: source genuinely has a duplicate category-name
   heading above the article's own H1 (verified on the live original site, not
   a mirror artifact) — rendered as a muted eyebrow label instead of a second
   literal <h1>, same position/text, no semantic-heading collision. */
.site-testimony-category { max-width: 720px; margin: 40px auto 0; font-size: 14px; text-transform: uppercase; letter-spacing: .05em; color: #999; }
@media (min-width: 1200px) { .site-testimony-category { margin-top: 70px; } }
.site-testimony-category + .site-article-title { margin-top: 8px; }
@media (min-width: 1200px) { .site-testimony-category + .site-article-title { margin-top: 8px; } }
.site-article { margin-top: 40px; } /* .uk-margin-medium-top, on the real body-text wrapper div */
/* reading-width cap: on two-column pages (About/Pain-Relief-Process/Donald)
   the sidebar naturally keeps the article text to roughly this width; on
   single-column full-width pages (issue sub-pages) there's no sidebar to
   do that, so the text was spanning the full ~1100px row — much wider
   than a comfortable reading line-length, and the likely cause of both
   the "width" and "spacing feels off" complaints (wide lines make normal
   paragraph gaps read as visually inconsistent). Applied to both the
   title and body so they stay aligned with each other; no-op on the
   two-column pages since their 2_3 column is already narrower than this. */
.site-article-title, .site-article { max-width: 720px; margin-left: auto; margin-right: auto; }
/* CORRECTION (Issues audit pass): the earlier "no bare p margin rule
   exists" claim was wrong — it came from a naive text grep for `p{margin`
   that missed a compound comma-selector. A proper brace-depth parse of
   theme.*.css finds the real UIkit base reset:
   `address,dl,fieldset,figure,ol,p,pre,ul{margin:0 0 20px 0}` plus
   `*+address,*+dl,*+fieldset,*+figure,*+ol,*+p,*+pre,*+ul{margin-top:20px}`
   — i.e. p (and ol/ul, see below) DO get a real 20px margin on the
   original site; it's not browser-default spacing. Restored here. Sibling
   <p> tags collapse normally to a single 20px gap (same-code()-module
   plain HTML flow, see skill's margin-collapsing note), so this does NOT
   double up against .site-issue-cta's margin-top below — collapsing takes
   the max of the two, still 40px there. */
.site-article p { line-height: 1.6; margin: 0 0 20px; }
/* same base reset applies to ol/ul: margin 0 0 20px 0 + padding-left:50px
   (verified `ol,ul{padding-left:50px}` — separate rule, same source).
   Needed by several issue pages whose extracted body content includes
   real <ul>/<ol> lists (arthritis, back-pain, headaches, neck-pain,
   osteoarthritis, sciatic-pain, tmd). No li-specific rule exists in the
   source — bullets/numbers render at browser defaults inside that
   padding-left. */
.site-article ul, .site-article ol { margin: 0 0 20px; padding-left: 50px; }
/* no border-radius here — grepped theme.*.css for any img rounding rule on
   article/panel images and found none; that was an earlier invented
   aesthetic touch, not something the source actually does. */
.site-article img { max-width: 100%; height: auto; display: block; }
.site-article iframe { max-width: 100%; } /* no .video-container rule exists in the theme — bare wrapper, safety cap only */
.site-article table { max-width: 100%; overflow-x: auto; } /* verified no bare table{} rule exists either (that "match" was actually .uk-table td{} and .calendar-container table{}) — this table relies on its own inline width/border attrs; cap+scroll is just overflow safety on narrow viewports, not invented styling */
@media (max-width: 767px) {
  /* Legacy pasted-content tables (Arthritis, High Blood Pressure) carry fixed
     inline px widths on the table and header <td>s from the original source.
     display:block previously left table-cell children generating their own
     anonymous table box at their unconstrained natural width, so the fixed
     px widths still won and the table overflowed the viewport. table-layout:
     fixed instead scales the original column-width ratios (from the first
     row's cells) down to fit width:100%, and the !important beats the
     inline width/style attrs pasted into the content. */
  .site-article table { width: 100% !important; table-layout: fixed; }
  .site-article table td, .site-article table th { width: auto !important; word-break: break-word; }
}
.site-article hr { border: 0; border-top: 2px solid #f4f4f4; margin: 0 0 20px; } /* verified real: hr{margin:0 0 20px 0} (top:0, not 20px — no visible change since it collapses with the preceding p's own 20px bottom margin either way, but matching the literal source value) */
.site-article h2:not(:first-child), .site-article h3:not(:first-child) { margin-top: 40px; } /* verified: *+h1..h6{margin-top:40px} */
/* found during Pain-Relief-Process/Contact audit: bare (unclassed) h1-h6
   also carry a real base margin-bottom in the source —
   `h1,h2,h3,h4,h5,h6,.uk-h1...uk-h6{margin:0 0 20px 0}` (same UIkit
   heading-reset rule family documented above for margin-top, just the
   other side, and previously missed). Divi's own core CSS resets all
   headings to margin:0, so without this a heading in a code() module sits
   flush against the very next paragraph — visible on Contact's bare <h1>/
   <h2> (no .site-article-title class to carry its own margin) and on
   Pain-Relief-Process's four numbered <h2> steps, whose paragraph
   immediately below had zero gap. margin-top is unaffected (h1 is always
   .site-article's first child so 0 is correct there; h2/h3 top already
   handled by the rule above) — collapses normally with the following
   <p>'s own margin (.site-article p, 0 0 20px) same as the source's own
   collapsing behavior, verified not to double the gap. */
.site-article h1, .site-article h2, .site-article h3, .site-article h4, .site-article h5, .site-article h6 { margin-bottom: 20px; }

/* ── Article sidebar (tm-sidebar) ───────────────────────────────────── */
/* verified: .uk-grid-divider draws a vertical rule between the main
   article column and the sidebar (border-left:2px solid #f4f4f4) —
   missing from an earlier pass of this build. Applied to the 1_3 column
   inside .site-container-small specifically, since that's the only row
   this divider belongs to. */
.site-container-small.et_pb_row > .et_pb_column_1_3 { border-left: 2px solid #f4f4f4; padding-left: 30px; }
@media (min-width: 1200px) { .site-container-small.et_pb_row > .et_pb_column_1_3 { padding-left: 40px; } } /* verified 1200px via brace-depth parse, not 960px */
/* CORRECTION: was a flat 40px. Real value comes from the sidebar's own
   `<div class="uk-grid uk-child-width-1-1" uk-grid>` wrapper (verified in
   both about.html and donald-a-capoferri-dc-bcn.html) — a PLAIN uk-grid
   with no -large/-medium modifier, so UIkit JS marks each item after the
   first with `uk-grid-margin`, whose base rule is
   `*+.uk-grid-margin{margin-top:30px}`, overridden to 40px only at real
   min-width:1200px (same 30/40 pair as .site-gap-grid on Home's blog grid
   — a different value/breakpoint pair than the 40/70 uk-margin-large gaps
   used elsewhere on this page, per the "never inherit a breakpoint from a
   nearby rule" rule). */
.site-sidebar-block { margin-bottom: 30px; }
@media (min-width: 1200px) { .site-sidebar-block { margin-bottom: 40px; } }
/* no border-radius / list-style override — grepped theme.*.css for
   `.latestnews` (the real class on the blog-links <ul>) and found NO rule
   at all; it's a plain default bulleted list, not the "no bullets +
   divider rows" treatment an earlier pass invented here. Links keep the
   page's normal accent-blue color (no override) since the source doesn't
   special-case them either. */
.site-sidebar-block img { max-width: 100%; height: auto; display: block; margin-bottom: 12px; }
/* verified: the insurance-logo block is the one sidebar list that's
   genuinely different — 4 logos stacked with real <br> tags, centered via
   the parent's text-align, at their own individual widths (Cigna is
   narrower than the other 3). Needs its images to stay inline (not the
   block-stacking behavior above) so the parent's text-align:center works. */
.site-sidebar-insurance img { display: inline; max-width: 100%; height: auto; margin-bottom: 0; }

/* ── Issues hub (single-column stacked list, no sidebar) ─────────────── */
/* verified: original H1 is bare (no .uk-article-title class), just the
   plain global h1 rule; .uk-margin-medium-bottom = 40px gap before the list */
.site-issues-h1 { margin: 0 0 40px; }
/* .uk-grid-row-large: 40px base -> 70px, but verified the breakpoint is
   1200px, NOT 960px (checked both this rule and .uk-margin-large-top
   directly in the source — both live inside the same @media(min-width:
   1200px) block, not the 960px one used elsewhere on this theme; don't
   assume breakpoints carry over between different utility classes).
   Applied as the single gap BETWEEN issue blocks — the source ALSO puts
   uk-margin-large-top on each block's own H2, but that sits on the first
   child of a plain block-flow wrapper, so it CSS-collapses with the
   wrapper's own grid-margin into one gap, not two. Divi's module wrappers
   don't reliably collapse margins the same way, so replicating both
   separately double-counted the gap. Fixed by applying it ONLY here. */
.site-issue + .site-issue { margin-top: 40px; }
@media (min-width: 1200px) { .site-issue + .site-issue { margin-top: 70px; } }
.site-issue h2 { margin: 0; }
/* .uk-link-reset: color:inherit + no underline — title link reads as plain
   dark heading text, not a blue link */
.site-issue-title-link { color: inherit; text-decoration: none; }
.site-issue-title-link:hover { color: var(--primary); }
.site-issue-body { margin-top: 20px; } /* .uk-margin-top */
/* CORRECTION (Issues audit pass): see .site-article p above — the earlier
   "no bare p margin rule" finding was a false negative from naive grep.
   Real value is 20px (UIkit base reset), restored here. Verified this does
   NOT create a double gap before the "Read more" CTA: .site-issue-body's
   last <p> and the sibling .site-issue-cta are both plain HTML siblings
   inside the SAME code() module blob, so their margins collapse to
   max(20, 40) = 40px, matching .site-issue-cta's own margin-top exactly —
   no visible change to that particular gap, only to multi-paragraph issue
   bodies (e.g. joint-pain, osteoarthritis, car-accident's iframe+citation)
   which previously had zero gap between consecutive <p> tags. */
.site-issue-body p { line-height: 1.6; margin: 0 0 20px; }
.site-issue-body img { max-width: 900px; max-height: 900px; }
/* real <ul>/<ol> don't appear in the hub's own excerpt copy today, but
   covering it here too for consistency/future-proofing — same source rule
   as .site-article ul/ol above. */
.site-issue-body ul, .site-issue-body ol { margin: 0 0 20px; padding-left: 50px; }
/* CORRECTION (Issues audit pass): margin-top:40 is right — the source `<p
   class="uk-margin-medium">` gets it via `*+.uk-margin-medium{margin-top:
   40px!important}` (it's preceded by the body-text sibling div). But the
   padding-top:18px/padding-bottom:36px this rule also carried had no
   source backing at all — `.uk-margin-medium{margin-bottom:40px}` is the
   ENTIRE real rule, no padding property exists on it anywhere in
   theme.*.css. That was ~54px of invented extra vertical space around the
   button on every issue block on the hub, same "eyeballed, not ported"
   category of mistake as the invented card shadow/padding already caught
   on the Home page. Removed — margin-bottom intentionally stays unset:
   verified `.uk-grid>*>:last-child{margin-bottom:0}` zeroes it in the
   source too, since this CTA <p> is the last child of its grid item. */
.site-issue-cta { margin-top: 40px; }

/* ── Dr. Donald Capoferri page ────────────────────────────────────────── */
/* verified: original inline style on the portrait img, moved to a class
   during extraction for cleanliness — same exact values, not invented. */
.site-donald-portrait { margin: 0 0 6px 6px; border: 4px solid #000; float: right; max-width: 100%; height: auto; }
/* verified: original inline style on the CE-section heading image (the
   font-size/line-height in the source are no-ops on an <img>, dropped;
   only the real margins are replicated) */
.site-donald-cesection-img { margin: 6px 0; max-width: 100%; height: auto; display: block; }
/* CORRECTION: two errors found on audit. (1) real `.uk-list-striped>*`
   padding is `10px 10px` (uniform all sides), not "0 top/bottom" as
   previously claimed here — verified via brace-depth parse of
   theme.1030c9.css: `.uk-list-striped>*{padding:10px 10px}` is the
   unmodified rule (no -large/-collapse variant used on this page).
   (2) this <ul> is also a plain child of `.site-article` (Donald's article
   body), so it ALSO matches `.site-article ul{margin:0 0 20px;
   padding-left:50px}` above — and that selector has higher specificity
   (0,1,1 vs 0,1,0), so it was silently WINNING over this class's own
   `padding:0`/`margin:0`, indenting the whole CV list an extra 50px that
   doesn't exist on the real site (real `.uk-list{padding:0}`). Requalified
   under `.site-article` to raise specificity above it. */
.site-article .site-striped-list { list-style: none; margin: 0 0 20px; padding: 0; }
.site-striped-list > li { padding: 10px; }
.site-striped-list > li:nth-of-type(odd) { background: #f8f8f8; }

/* ── Contact page: SMS-consent checkbox label ─────────────────────────── */
/* verified: source wraps this disclaimer in <em>, which combined with the
   real global em{color:#4dc36b} rule means it renders green on the source
   site. Ninja Forms' `label` setting is plain text (no HTML), so that
   formatting was silently dropped when the field got rebuilt — set
   element_class:"site-sms-consent" on the field (build_contact_form.php)
   as a CSS hook to reapply the real color. NF3 renders this field
   client-side via JS (no static HTML to inspect ahead of time, confirmed
   in SESSION_NOTES), so the exact element the class lands on can't be
   verified without a browser — covering every plausible NF3 DOM shape
   here rather than guessing a single selector. */
#nf-form-3-cont .site-sms-consent,
#nf-form-3-cont .site-sms-consent ~ label,
#nf-form-3-cont label:has(.site-sms-consent),
#nf-form-3-cont .nf-field-container:has(.site-sms-consent) label,
#nf-form-3-cont .nf-field-container:has(.site-sms-consent) .nf-field-label {
    color: #4dc36b !important;
}

/* ── Global Footer (Divi Theme Builder) ──────────────────────────────────
   Real source: 4-col link grid (Solutions/Company/Contact & Terms/
   Insurance) + "Areas We Serve" block, both white bg, then a separate
   primary-blue bottom bar (logo/address+copyright/social links). Source
   used UIkit's uk-icon attribute-based icon font for link bullets and
   social icons — that depends on UIkit's JS (not loaded on this WP
   install, same situation as every other UIkit-JS-dependent widget
   already encountered on this project) — so those render as plain text
   links instead of icon+text, matching the established fallback pattern. */
.site-footer-col h4 { font-size: 16px; font-weight: 600; color: var(--dark); margin: 0 0 16px; text-transform: uppercase; letter-spacing: .03em; }
.site-footer-col ul { list-style: none; margin: 0; padding: 0; }
.site-footer-col li { margin-bottom: 10px; }
.site-footer-col a { color: #666; text-decoration: none; }
.site-footer-col a:hover { color: var(--primary); }
.site-footer-insurance-card { display: block; text-align: center; padding: 20px; border-radius: 10px; color: #fff; background-color: var(--primary); background-image: linear-gradient(45deg, #4a91fd, #6da6fd); box-shadow: 0 10px 30px 0 rgba(0,0,0,.08); margin-bottom: 16px; }
.site-footer-insurance-card img { max-width: 100%; height: auto; margin: 0 auto; }
.site-footer-areas-served { border-top: 1px solid #e2e2e2; padding-top: 30px; margin-top: 10px; }
.site-footer-areas-served h2 { font-size: 24px; margin: 0 0 10px; }
.site-footer-areas-served a { color: var(--primary); text-decoration: none; }
.site-footer-areas-served a:hover { text-decoration: underline; }
.site-footer-bottom { color: #fff; }
.site-footer-bottom a { color: #fff; }
.site-footer-bottom .site-footer-address { text-align: center; margin: 0 0 10px; }
.site-footer-bottom .site-footer-copyright { text-align: center; font-size: 13px; opacity: .85; margin: 0; }
.site-footer-social { display: flex; gap: 16px; justify-content: center; list-style: none; margin: 0; padding: 0; }
@media (min-width: 981px) { .site-footer-social { justify-content: flex-end; } }
.site-footer-social a { color: #fff; text-decoration: none; font-size: 14px; }
.site-footer-social a:hover { text-decoration: underline; }

/* ── Image Review service page ────────────────────────────────────────── */
/* verified via brace-depth parse: `.uk-padding{padding:30px}` overridden to
   `padding:40px` at real min-width:1200px (`.uk-card-primary` itself only
   sets bg/color/shadow, `.uk-card` only sets border-radius/position — the
   padding value comes from the separate `.uk-padding` utility class also
   present on this element). Previous build had this as a plain inline
   style (flat 30px, no @1200 bump) — inline styles can't carry media
   queries, so moved to a class. */
.site-card-primary-frame { display: block; margin: 0 auto; max-width: 100%; height: auto;
    padding: 30px; border-radius: 10px; color: #fff; box-sizing: border-box;
    background-color: #4a91fd; background-image: linear-gradient(45deg,#4a91fd,#6da6fd);
    box-shadow: 0 20px 40px 0 rgba(0,0,0,.1); }
@media (min-width: 1200px) { .site-card-primary-frame { padding: 40px; } }

/* verified: `.uk-card-default` (bg #fff, color #666, shadow
   0 10px 30px 0 rgba(0,0,0,.08)) + UNMODIFIED `.uk-card-body` (padding
   40px 40px base -> 60px 50px @1200px — same override already documented
   for .site-blog-card-body above, this page just hadn't been ported to a
   class yet). Previous build had a flat 40px inline style with no @1200
   bump. */
.site-mri-card { background-color: #fff; color: #666; border-radius: 10px; padding: 40px;
    box-shadow: 0 10px 30px 0 rgba(0,0,0,.08); text-align: center; box-sizing: border-box; }
@media (min-width: 1200px) { .site-mri-card { padding: 60px 50px; } }

#mobile_menu1 {
   background-color: #fff !important;
   color: #777 !important;
   overflow-y: scroll !important;
   max-height: 80vh;
}

#mobile_menu1 li a {
   color: #777 !important;
}

.video-container {
   max-height:550px;
}

/* Gentle Computer-Aided Chiropractic Care (post 70): two article images use
   float:right so body copy wraps beside them. On mobile that "left column"
   of wrapped text becomes a narrow, awkward strip. Two different fixes per
   the plain-vs-strong distinction in the wrapping text:
   1. .site-mobile-unfloat (proadjuster-banner-1.jpg) — the wrapping text is
      a plain paragraph that already comes AFTER the image in source order,
      so simply dropping the float stacks it below the image as-is, no
      reordering needed.
   2. .site-mobile-img-text-swap (spinal-adjuster-1.jpg) — the wrapping text
      is the bold "How can anything so gentle..." sub-heading; per request,
      strong/bold wrapping text should render ABOVE the image on mobile
      instead of below, which needs actual reordering, not just an unfloat.
      Desktop is untouched either way — both selectors only activate inside
      the media query; outside it the image/strong stay in normal block/
      inline flow exactly as before (float wraps text identically to the
      original single <p><strong><img>...</strong></p> markup). */
.site-mobile-img-text-swap { margin: 0 0 20px; }
@media (max-width: 767px) {
    .site-mobile-unfloat { float: none !important; width: 100% !important; margin: 0 0 15px !important; }
    .site-mobile-img-text-swap { display: flex; flex-direction: column; }
    .site-mobile-img-text-swap img { order: 2; float: none !important; width: 100% !important; margin: 0 0 15px !important; }
    .site-mobile-img-text-swap strong,
    .site-mobile-img-text-swap h2,
    .site-mobile-img-text-swap h3 { order: 1; }
}

/* Site-wide rollout of the above pattern (Issues hub + issue detail pages:
   back pain, joint pain, sciatic pain, knee pain). These float small topic
   icons (80-188px), not full-content photos — per explicit decision,
   unfloating them should keep their original small size, centered, rather
   than stretching to width:100% like a real content photo. -small variants
   of both classes do the same float-removal / strong-text-reorder logic as
   above but center at natural width instead of forcing 100%. h2/h3 added
   to the swap variant's heading selector because the sciatic pain content
   wraps its heading in <h2> (detail page) / <h3> (Issues hub excerpt)
   instead of <strong>. */
.site-mobile-img-text-swap-small { margin: 0 0 20px; }
@media (max-width: 767px) {
    .site-mobile-unfloat-small { float: none !important; display: block !important; margin: 0 auto 15px !important; }
    .site-mobile-img-text-swap-small { display: flex; flex-direction: column; }
    .site-mobile-img-text-swap-small img { order: 2; float: none !important; display: block !important; margin: 0 auto 15px !important; }
    .site-mobile-img-text-swap-small strong,
    .site-mobile-img-text-swap-small h2,
    .site-mobile-img-text-swap-small h3 { order: 1; }
}

#nf-field-20 {
   font-size: 16px;
   color: #fff;
   background: #4585f4;
   border-color: #4585f4;;
   padding:  13px 20px;
   border-radius: 3px;
}