/* ============================================================================
   Starter-authored chrome — cookie banner + 404 page + generic Content Page +
   Block Grid mechanics
   ============================================================================
   Deliberately kept OUT of site.css. site.css gets replaced wholesale with the
   incoming static design's own stylesheet on every clone (copy the client's
   main.css in verbatim) — static designs never include their own cookie-banner
   styling (it's a legal add-on, not part of the original mockup) or Umbraco's
   own Block Grid wrapper classes (those don't exist in a static mockup at all),
   so any CSS for either living in site.css would be silently destroyed the
   moment that copy step happens. Everything below uses hardcoded values only —
   no reference to this starter's own --colour-*, --space-*, --z-* custom
   properties, since those get replaced along with everything else in site.css
   too. This file survives the clone process untouched; restyle the chrome
   parts by hand per-client if you want them to match that client's palette,
   but it works out of the box either way.

   ⚠ Do NOT let any comment in this file contain the literal two-character
   sequence "*/" as part of its prose (e.g. writing "--colour-*/--space-*"
   with a slash instead of a comma, as this file's own header comment used
   to). It closes the comment block right there — everything after it, up to
   the next real "*/", gets parsed as invalid CSS and silently swallows
   whatever rule follows as an unparseable selector. Confirmed: this exact
   mistake in this exact comment dropped the .cookie-banner rule entirely on
   a live client build (Guiding Light Hypnotherapy) — position:fixed simply
   never applied, with zero console error, because the rule never made it
   into the parsed stylesheet at all. See Gotchas doc §19.
   ============================================================================ */

.cookie-banner {
  position: fixed;
  left: 0;
  right: 0;
  bottom: 0;
  z-index: 999;
  background: #111318;
  color: #f4f4f5;
  padding: 20px 24px;
  box-shadow: 0 -4px 16px rgba(0, 0, 0, 0.25);
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif;
}

.cookie-banner-content {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: 24px;
  max-width: 1200px;
  margin-inline: auto;
  flex-wrap: wrap;
}

.cookie-banner-content p {
  flex: 1;
  min-width: 240px;
  margin: 0;
  font-size: 14px;
  line-height: 1.5;
  color: #d4d4d8;
}

.cookie-banner-actions {
  display: flex;
  align-items: center;
  gap: 12px;
  flex-wrap: wrap;
}

.cookie-banner-btn {
  font: inherit;
  font-weight: 600;
  font-size: 13.5px;
  padding: 9px 18px;
  border-radius: 999px;
  border: 1px solid transparent;
  cursor: pointer;
  transition: opacity 0.15s ease;
}

.cookie-banner-btn:hover {
  opacity: 0.85;
}

.cookie-banner-btn--accept {
  background: #f4f4f5;
  color: #111318;
}

.cookie-banner-btn--reject {
  background: transparent;
  color: #f4f4f5;
  border-color: rgba(244, 244, 245, 0.35);
}

.cookie-banner-link {
  color: #f4f4f5;
  font-size: 14px;
  text-decoration: underline;
  text-underline-offset: 3px;
}

.cookie-banner-link:hover {
  opacity: 0.85;
}

@media (max-width: 640px) {
  .cookie-banner-content {
    flex-direction: column;
    align-items: flex-start;
  }
}

/* ---------- 404 page (Views/Error404.cshtml — standalone, not wrapped in _Layout) ---------- */

body.error-404 {
  min-height: 100svh;
  display: flex;
  flex-direction: column;
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif;
  background: #111318;
  color: #f4f4f4;
}

.error-404__header {
  padding: 24px 28px;
}

.error-404__header a {
  display: inline-flex;
  align-items: center;
  color: inherit;
  text-decoration: none;
  font-weight: 700;
}

.error-404__header img {
  height: 32px;
  width: auto;
  display: block;
}

.error-404__main {
  flex: 1;
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  text-align: center;
  padding: 24px;
}

.error-404__code {
  font-size: clamp(64px, 18vw, 140px);
  font-weight: 800;
  line-height: 1;
  margin: 0 0 8px;
  color: rgba(244, 244, 244, 0.25);
}

.error-404__main h1 {
  font-size: clamp(22px, 4vw, 32px);
  margin: 0 0 12px;
}

.error-404__main p {
  color: #a3a0a0;
  max-width: 44ch;
  margin: 0 0 24px;
}

.error-404__main a:not(.error-404__header a) {
  color: #f4f4f4;
  font-weight: 600;
  text-decoration: underline;
  text-underline-offset: 3px;
}

/* ---------- Generic Content Page (Views/ContentPage.cshtml — Privacy Policy, Terms, etc.) ----------
   Baseline only. No static design has ever included an equivalent page to derive real styling
   from, so this exists purely so a fresh clone isn't broken (unstyled, overlapping the nav) the
   first time someone actually uses this Doc Type. Restyle with the client's real typography/colour
   once a real one exists — same as the cookie banner and 404 page.
   Assumes .nav-primary's default `position: sticky` (reserves its own space in flow, no clearance
   needed). If a client's nav uses `position: fixed` instead, add enough top padding here to clear
   it explicitly — confirmed necessary on the Guiding Light Hypnotherapy build, which used a fixed
   nav and needed ~160px top padding instead of this. */

.content-page {
  max-width: 800px;
  margin-inline: auto;
  padding: 64px 24px 96px;
}

.content-page__title {
  font-size: clamp(28px, 4vw, 40px);
  font-weight: 700;
  margin-bottom: 24px;
  color: #1a1a1a;
}

.content-page__body {
  font-size: 16px;
  line-height: 1.7;
  color: #333333;
}

.content-page__body h2 {
  font-size: 22px;
  font-weight: 600;
  margin: 32px 0 12px;
  color: #1a1a1a;
}

.content-page__body h2:first-child {
  margin-top: 0;
}

.content-page__body p {
  margin-bottom: 16px;
}

.content-page__body a {
  color: #1a56db;
  text-decoration: underline;
  text-underline-offset: 2px;
}

.content-page__body a:hover {
  text-decoration-color: currentColor;
}

/* ---------- Block Grid mechanics ----------
   The static source's own section containers (.tiers/.chat-grid/whatever the client's design calls
   them) don't exist in Umbraco's Block Grid output — it wraps every item in its own
   .umb-block-grid__layout-item, one level per nesting depth. This reproduces a consistent 12-column
   grid rhythm across those wrapper levels using CSS Grid subgrid, and documents two gotchas that
   are easy to lose an afternoon to if you don't know they're coming:

   1. Every block gets its OWN wrapper div, so :first-child/:last-child on a repeated element inside
      a block (e.g. a numbered step's connecting line) matches EVERY item, not just the true first/
      last in the visual list — each one is trivially both first and last child of its own unique
      wrapper. Target the wrapper's :first-child/:last-child instead of the inner element's, scoped
      to the specific area (see the [data-area-alias="..."] pattern below — swap "steps" for whatever
      area alias the actual client build uses).

   2. A hand-authored static section normally gets its own top/bottom padding for free. A Block Grid
      item doesn't — there's no equivalent "section" wrapper per block. The rules below add that
      padding back only at the very first/last item of the OUTERMOST grid (never inside a nested
      Area, or a group block's own children misalign against their row siblings). */

.umb-block-grid {
  display: grid;
  grid-template-columns: repeat(var(--umb-block-grid--grid-columns, 12), 1fr);
  column-gap: 20px;
  row-gap: 0;
}

.umb-block-grid__layout-container {
  display: grid;
  grid-column: 1 / -1;
  /* Not using grid-template-columns:subgrid here — with items placed only via
     grid-column:span N (no explicit grid-row) and column-span values coming
     from a CSS custom property, subgrid + auto-placement failed to pack two
     span-6 siblings into the same row in Chrome, Firefox, and Edge alike
     (each fell back to one item per row, full-width, instead of side-by-side)
     on the BSS-BaySmartSolutions site. Plain repeat() auto-placement doesn't
     have this problem. */
  grid-template-columns: repeat(var(--umb-block-grid--grid-columns, 12), 1fr);
  column-gap: 20px;
  row-gap: 0;
}

.umb-block-grid__layout-item {
  /* Not using grid-column:span var(--umb-block-grid--item-column-span,...) here —
     on the BSS-BaySmartSolutions site it reliably resolved to the fallback (12)
     on first paint in Chrome, Firefox, and Edge alike, even though the custom
     property was verifiably present and correctly valued in the server-rendered
     HTML. It only ever "fixed itself" if the exact value was retyped live in
     DevTools. Root cause unresolved; sidestepping it entirely by matching
     Umbraco's own data-col-span attribute instead, which never goes through
     custom-property substitution. */
  min-width: 0;
}
.umb-block-grid__layout-item[data-col-span="1"] { grid-column: span 1; }
.umb-block-grid__layout-item[data-col-span="2"] { grid-column: span 2; }
.umb-block-grid__layout-item[data-col-span="3"] { grid-column: span 3; }
.umb-block-grid__layout-item[data-col-span="4"] { grid-column: span 4; }
.umb-block-grid__layout-item[data-col-span="5"] { grid-column: span 5; }
.umb-block-grid__layout-item[data-col-span="6"] { grid-column: span 6; }
.umb-block-grid__layout-item[data-col-span="7"] { grid-column: span 7; }
.umb-block-grid__layout-item[data-col-span="8"] { grid-column: span 8; }
.umb-block-grid__layout-item[data-col-span="9"] { grid-column: span 9; }
.umb-block-grid__layout-item[data-col-span="10"] { grid-column: span 10; }
.umb-block-grid__layout-item[data-col-span="11"] { grid-column: span 11; }
.umb-block-grid__layout-item[data-col-span="12"] { grid-column: span 12; }

.umb-block-grid__area {
  display: grid;
  grid-template-columns: repeat(var(--umb-block-grid--grid-columns, 12), 1fr);
  gap: 20px;
}

@media (max-width: 900px) {
  /* [data-col-span] (attribute-presence, matches any value) rather than the bare
     class — needs equal-or-higher specificity than the .umb-block-grid__layout-item
     [data-col-span="N"] rules above (0,2,0) to actually win the override; the bare
     class alone (0,1,0) silently lost to them, leaving desktop's column span
     applied on mobile too. Confirmed on BSS-BaySmartSolutions. */
  .umb-block-grid__layout-item[data-col-span] {
    grid-column: 1 / -1;
  }
}

/* Example only — delete or adapt once the actual client build's section-padding values are known.
   If the first block already provides its own visual separator (a divider component, say), scope
   the :not(:has(...)) escape hatch to that divider's real class name so this doesn't double up. */
.umb-block-grid > .umb-block-grid__layout-container > .umb-block-grid__layout-item:first-child {
  /* padding-top: <same value the static design's own first section used>; */
}
.umb-block-grid {
  /* padding-bottom: <same value the static design's own last section used>; */
}