/* ============================================================================
   Starter-authored chrome — cookie banner + 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.

   The 404 page is NOT here — once a client provides their own bespoke 404
   design (as this one did), it moves into site.css like any other real page,
   reusing the site's actual design tokens (--teal-dark, --blush, etc.) instead
   of the generic hardcoded dark theme this file ships as a fallback.
   ============================================================================ */

.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;
  }
}

/* ---------- 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) {
  .umb-block-grid__layout-item {
    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>; */
}