/* ==========================================================================
   babaLucas Creative — GeneratePress host-neutralization fixes.

   NOT page content or design-system rules — those now live entirely in
   babalucas-tokens.css (v1.1, chrome + shared components) and page-home.css
   (page-specific rules), both shipped by design-handoff. This file exists
   solely to make GeneratePress itself stop fighting that design system.
   See references/generatepress-host-audit.md in the wp-pixel-perfect skill
   for the full diagnosis behind each rule below.
   ========================================================================== */

/* --------------------------------------------------------------------------
   GENERATEPRESS INTEGRATION
   CORRECTION 2026-08-30: the CSS :root remap that used to live here (--base/
   --contrast/etc pointed at our design tokens) is gone — replaced with real
   values written directly into generate_settings['global_colors'] via
   WP-CLI (see the generatepress-settings skill). GP now emits
   ":root{--contrast:#FFF9F6;--base:#221410;--accent:#F26722;...}" natively
   (#DEC9C5 until tokens.css v1.7, 2026-10-07),
   Customizer-visible, no CSS override needed. Verified via
   `wp eval 'echo generate_base_css();'`: GP's own block now prints our
   brand hex directly, so every GP-themed surface (nav, footer, forms,
   links, buttons) picks up the babaLucas palette from the settings layer,
   not a parallel stylesheet.
   Only the body background survives as hand-written CSS below — GP's own
   color-output code only ever assigns solid `background-color` to body,
   never the `background` shorthand, so the two-stop espresso gradient is
   structurally impossible to express through generate_settings. `color`
   is gone from this rule too: GP's own body{color:var(--contrast)} is now
   already correct, since --contrast holds our real text color natively.
   -------------------------------------------------------------------------- */
body{background:linear-gradient(180deg, var(--bg) 0%, var(--bg-deep) 100%)}

/* --------------------------------------------------------------------------
   GRAVITY FORMS INTEGRATION — same pattern as GP's own --base/--contrast
   system above, different plugin. Both forms switched off legacy markup
   2026-08-31 (markupVersion 2), which moves them onto GF's "Orbital" theme
   framework — its own CSS custom-property color system, scoped per form
   instance via .gform-theme, assuming a light form on a light page. Values
   below read directly off the injected #gform_wrapper_N <style> block
   (GF version active 2026-08-31); re-diff against that source if a future
   GF update ships new default tokens rather than assuming these still match.
   Confirmed the real driver (not a guess): --gf-color-secondary-contrast
   computed to #112337 on a live label, matching Orbital's own dark-navy
   default exactly — remapping once here fixes every current and future
   Orbital-themed form sitewide, not just this page's.
   Not remapped: --gf-icon-ctrl-number/-select/-search are embedded SVG
   data-URIs with the fill color baked into the image itself, not a plain
   CSS color — a variable remap can't reach them. Only matters for
   number/select/search field types, none of which are in use yet; revisit
   if one gets added and its icon reads too dark against the card background.
   -------------------------------------------------------------------------- */
.gform-theme{
  /* !important on every custom property: GF injects its own values inline, scoped to
     "#gform_wrapper_N[data-form-index].gform-theme" — an ID selector, which beats a plain
     class regardless of print order. Custom properties follow ordinary cascade/specificity
     rules like any other property, so matching that ID per-form isn't durable (breaks on
     the next form's wrapper id) — !important is the correct tool for overriding a plugin's
     own ID-scoped styles, same justification as .wrap.wrap in editor-canvas.css. */
  --gf-color-primary: var(--orange) !important;
  --gf-color-primary-contrast: #fff !important;
  --gf-color-primary-darker: var(--orange-dark) !important;
  --gf-color-primary-lighter: var(--orange-mid) !important;
  --gf-color-secondary: var(--card) !important;
  --gf-color-secondary-contrast: var(--text-strong) !important;
  --gf-color-secondary-darker: var(--bg) !important;
  --gf-color-secondary-lighter: var(--card) !important;
  --gf-color-out-ctrl-dark: var(--muted) !important;
  --gf-color-out-ctrl-dark-darker: var(--text-strong) !important;
  --gf-color-out-ctrl-dark-lighter: var(--muted) !important;
  --gf-color-in-ctrl: var(--bg) !important;
  --gf-color-in-ctrl-contrast: var(--text) !important;
  --gf-color-in-ctrl-darker: var(--bg-deep) !important;
  --gf-color-in-ctrl-lighter: var(--card) !important;
  --gf-color-in-ctrl-primary: var(--orange) !important;
  --gf-color-in-ctrl-primary-contrast: #fff !important;
  --gf-ctrl-border-color: var(--line) !important;
  --gf-ctrl-label-color-primary: var(--text-strong) !important;
  --gf-ctrl-label-color-secondary: var(--text-strong) !important;
  --gf-ctrl-btn-border-color-secondary: var(--line) !important;
}

/* GP's actual rule is ".separate-containers .inside-article{background-
   color:var(--base-3)}" (specificity 0,2,0 — two classes), which beats a
   plain ".inside-article" override regardless of load order. GP applies
   this "raised card" box treatment to post/page content depending on the
   active Customizer container style (Separate Containers / One Container),
   so !important guarantees full-bleed sections stay full-bleed no matter
   which container style is selected later. */
.inside-article,
.separate-containers .inside-article,
.one-container .container{background:transparent!important}

/* CORRECTION 2026-08-23: the former sitewide zero-reset that lived here
   (p,ul,ol,dl,h1-h6{margin:0;padding:0}) has moved to page-home.css,
   scoped to the front page only. It's now doing double duty as both a
   GP-fighting rule AND the homepage's own component-spacing baseline
   (service cards etc. rely on zero heading margin, letting their parent's
   flex/grid `gap` own the spacing) — those two jobs need different
   scopes. Sitewide, it was silently killing GeneratePress's own Dynamic
   Typography settings (Customize > Typography), configured 2026-08-23
   with real margin/font-size values for h1/h2/h3/p — see
   inc/class-typography.php: GP's dynamic CSS and this reset are the same
   specificity (0,0,1, both bare-tag), so whichever printed later won,
   and page-specific.css always printed after GP's inline styles. Every
   plain content page (Terms, Privacy, future blog/SEO pages) now gets
   real vertical rhythm from GP's own settings, adjustable via Customizer,
   zero code required — verified on the Terms & Conditions page: h2
   margin-bottom went from a computed 0px to the configured 20px. */

/* --------------------------------------------------------------------------
   SITE IDENTITY — deliberate deviation from tokens.css v1.1's header
   treatment, per Rob's explicit sign-off (2026-08-20) to move away from
   the original icon-mark + text lockup in favor of a single wordmark logo
   at roughly double the old icon's height. Lives here rather than in
   tokens.css itself so it stays a visible, isolated override the design
   side can see and reconcile later, not a silent edit to their file.
   -------------------------------------------------------------------------- */
.nav .brandmark img{height:80px;border-radius:0}

/* Page title -> content gap. GP core's own rule (main.css:905-909) is
   ".entry-content:not(:first-child){margin-top:2em}" — a structural rule keyed off DOM
   position, not part of the Dynamic Typography settings schema, so generate_settings can't
   express this one; it's a genuine CSS-only case. 2em -> 3em: same unit GP already uses
   (stays responsive, no arbitrary px value grafted onto an em-based system), a clean 1.5x,
   and lands at 50.4px — within a hair of 48px/56px, the two gap sizes already used
   elsewhere on the site (see page-home.css/babalucas-tokens.css), so it reads as
   consistent with the site's existing spacing rather than a one-off number. Mirrors GP's
   own ":not(:first-child)" selector, which makes this self-scoping: it only applies where
   .entry-header actually precedes .entry-content (Terms, Privacy, Accessibility Statement,
   future content/blog pages) — Home and Contact suppress entry-header entirely via the
   disable-headline meta, so entry-content is first-child there and this rule never matches. */
.entry-content:not(:first-child){margin-top:3em}
/* CORRECTION 2026-08-30: was "footer.site ul{...}", written 2026-08-20 when the footer's
   nav markup was still wrapped in a <ul>. The 2026-08-22 migration to real WP menus (see
   functions.php) changed the footer template's output to bare <li class="menu-item"> with
   no <ul> wrapper at all — the old selector silently stopped matching anything, and browsers
   still apply default list-item bullet markers to an orphaned <li> regardless of its parent.
   Target the actual element now. */
footer.site li{list-style:none;margin:0;padding:0}

/* --------------------------------------------------------------------------
   HEADER NAV — bridges GP core's native generate_navigation_position()
   output (called from the "Site Header" gp_elements hook element, added
   2026-08-22 replacing hand-rolled markup) to the brand look. GP's own
   responsive show/hide (menu-toggle, 768px breakpoint, .toggled state) is
   untouched — verified working via generate-style-inline-css — this only
   restyles colors/layout, not visibility logic.

   .main-navigation gets --base-3 (var(--card)) as a background box via GP's
   own color-system remap above; correct for blog/card contexts, wrong here
   since .site-head already supplies the header's own translucent backdrop.
   -------------------------------------------------------------------------- */
.site-head .nav{flex-wrap:wrap;container-type:inline-size}
.site-head .main-navigation{background:none;margin:0}
.site-head .main-navigation.mobile-menu-control-wrapper{display:none} /* duplicate toggle from GP's flexbox-header mode; the real one lives inside #site-navigation */
.site-head .inside-navigation.grid-container{padding:0}
.site-head .nav .main-navigation.toggled{flex:1 0 100%} /* GP's own .toggled .main-nav{flex-basis:100%} only sizes the ul WITHIN this <nav>'s own inner flex context (.inside-navigation.grid-container) -- it says nothing about how this <nav> itself, one of two flex items in our custom .site-head .nav wrapper (the other being .brandmark), should size once it wraps onto its own row. Without this, the wrapped nav just shrinks to fit its content (flex-basis:auto default) instead of spanning the row it's now alone on. */
@media (min-width:769px){
  .site-head .nav{flex-wrap:nowrap} /* BUG FIXED 2026-08-31: unguarded (and previously default-value) nowrap kept the logo and the mobile .toggled menu on the same row below 769px, squeezing the menu into whatever room was left beside the logo (~139-177px) instead of letting it wrap onto its own full-width line, where GP core's own `.toggled .main-nav{flex-basis:100%}` expects to take over. Mobile now gets flex-wrap:wrap from the unconditional .site-head .nav rule above; this override restores nowrap on desktop only. */
}

/* Desktop-only from here down, guarded to GP core's own 769px breakpoint
   (confirmed against generatepress/assets/css/main.min.css: mobile toggle
   kicks in at max-width:768px). BUG FIXED 2026-08-31: #primary-menu{display:
   flex} was previously unguarded -- an ID selector, so it out-specifies GP's
   own class-based .toggled mobile rules and forced the mobile dropdown into
   a cramped 177px-wide horizontal flex row instead of GP's normal full-width
   stacked column, wrapping "how we do it" onto its own line and overlapping
   the logo. Wrapping the whole desktop block here lets GP's native mobile
   CSS govern layout (not just visibility) below 769px, untouched. */
@media (min-width:769px){
  .site-head #primary-menu{display:flex;gap:28px;align-items:center;list-style:none;margin:0}
  .site-head #primary-menu li{list-style:none}
  .site-head #primary-menu li>a{line-height:normal;padding-left:0;padding-right:0} /* GP core's main.min.css sets line-height:60px + 20px/side padding on .main-navigation .main-nav ul li a for tall-header centering/spacing — wrong here since spacing is already handled by #primary-menu's own gap, and doubling up (40px padding + 28px gap per item) was consuming ~240px of width with zero slack at the header's own 1120px max-width, forcing the CTA button to wrap on any narrower viewport. li.btn>a below re-applies its own padding, since a button needs it. */
  .site-head #primary-menu li.link>a{color:var(--text-strong);text-decoration:none;font-family:var(--head);font-weight:600;font-size:.92rem}
  .site-head #primary-menu li.link>a:hover,
  .site-head #primary-menu li.link>a:focus{color:var(--orange-darkest)}
  .site-head #primary-menu li.btn{background:var(--orange-dark);border-radius:8px;transition:background .2s, transform .2s}
  .site-head #primary-menu li.btn:hover{background:var(--orange-darkest);transform:translateY(-1px)}
  .site-head #primary-menu li.btn>a{color:#fff;text-decoration:none;font-weight:700;font-size:.92rem;padding:10px 20px;display:inline-block}
}

/* Container query (not @media) deliberately: the failure mode is .nav's own
   rendered width running out of room — capped at 1120px by .wrap, not by
   the viewport directly — so this must respond to .nav's actual box, which
   a viewport media query can't see correctly (.nav can be short on room
   while the viewport itself is still wide). Placed after the base rules
   above: identical specificity, so cascade order is what makes these win
   when the condition matches — putting them earlier in the file is a
   silent no-op regardless of whether the @container condition is true.
   Also guarded to desktop: container-type:inline-size is set on .site-head
   .nav unconditionally above, so without this guard these would still fire
   inside the mobile toggled menu's own (now full-width, but still narrower
   than 1024px) box. */
@media (min-width:769px){
  @container (max-width: 1024px){
    .site-head #primary-menu{gap:16px}
    .site-head .nav .brandmark img{height:64px}
    .site-head #primary-menu li.link>a{font-size:.86rem}
  }
  @container (max-width: 860px){
    .site-head #primary-menu{gap:10px}
    .site-head .nav .brandmark img{height:52px}
    .site-head #primary-menu li.link>a{font-size:.78rem}
    .site-head #primary-menu li.btn>a{padding:8px 14px;font-size:.82rem}
  }
  @container (max-width: 830px){
    .site-head #primary-menu{gap:6px}
    .site-head .nav .brandmark img{height:44px}
    .site-head #primary-menu li.link>a{font-size:.7rem}
    .site-head #primary-menu li.btn>a{padding:7px 12px;font-size:.74rem}
  }
}
.site-head .menu-toggle{color:var(--text-strong)}