/* ==========================================================================
   judybees — page layout
   --------------------------------------------------------------------------
   Site-wide gutters. Horizon ships 16px on phones rising to 40px on desktop;
   the judybees framework uses `.padding-global` at 64px with a 20px gutter on
   phones. Set once here so every section inherits it.

   IMPORTANT — why these selectors and not `:root`:
   Horizon declares `--page-margin` on `.page-width-wide / -normal / -narrow /
   -content`, and those classes sit on <body>. A `:root` declaration is only
   INHERITED down to <body>, and any direct declaration on an element beats a
   value it would otherwise inherit — regardless of specificity. So `:root`
   silently loses. The override has to land on the same elements.

   `--page-content-width` is deliberately untouched: that one is driven by the
   Page width setting in the theme editor and should stay Nikol's to change.
   ========================================================================== */

.page-width-wide,
.page-width-normal,
.page-width-narrow,
.page-width-content {
  --page-margin: 20px; /* framework mobile gutter */
}

@media screen and (min-width: 750px) {
  .page-width-wide,
  .page-width-normal,
  .page-width-narrow,
  .page-width-content {
    --page-margin: 40px;
  }
}

/* Desktop gutter: 64px is the floor, but it grows with the viewport so a wide
   screen keeps roughly the 87%-content proportion Nikol' specified rather than
   pinning to a fixed 64px and looking mean at 1920px. 6.5vw either side leaves
   87% for content; `max()` guarantees it never drops below the 64px floor. */
@media screen and (min-width: 990px) {
  .page-width-wide,
  .page-width-normal,
  .page-width-narrow,
  .page-width-content {
    --page-margin: max(64px, 6.5vw);
  }
}


/* ==========================================================================
   Main content — always at least a screenful
   --------------------------------------------------------------------------
   Without this, a short page (the Updates archive with one entry, a thin
   policy page, an empty search result) leaves the footer riding up the middle
   of the viewport, which reads as a broken page rather than a short one.

   Subtracting the header rather than using a bare `100dvh`: the header sits
   above `#MainContent`, so a flat viewport height would guarantee a scrollbar
   on every page even when the content fits. `--header-group-height` is
   Horizon's own, written onto `document.body` by `header.js` and recalculated
   on resize, so this tracks the real header — announcement bar, nav row and
   category row included — rather than a number that goes stale the moment a
   row is added. The 0px fallback covers first paint, before the script runs.

   `dvh` rather than `vh` so mobile browsers measure the *visible* viewport and
   the footer is not pushed under the address bar.
   ========================================================================== */
#MainContent {
  min-height: calc(100dvh - var(--header-group-height, 0px));
}


/* ==========================================================================
   Text selection
   --------------------------------------------------------------------------
   Amber on black — the brand's own inversion, and the one pairing that stays
   legible whichever scheme the text under the cursor happens to be using.

   The two rules CANNOT be merged into one selector list. `::-moz-selection` is
   Firefox's older prefixed form and every other engine treats it as invalid —
   and an invalid selector anywhere in a list invalidates the ENTIRE rule, so a
   combined `::selection, ::-moz-selection { }` would style nothing at all in
   Chrome or Safari. They stay separate on purpose.
   ========================================================================== */
::selection {
  background: #0a0807;
  color: var(--jb-amber, #fcb217);
}

::-moz-selection {
  background: #0a0807;
  color: var(--jb-amber, #fcb217);
}


/* ==========================================================================
   Scrollbar
   --------------------------------------------------------------------------
   Two implementations, deliberately NOT declared together.

   Since Chromium 121 the standard `scrollbar-color` property takes precedence
   over `::-webkit-scrollbar` and switches the scrollbar to the standard
   rendering path entirely. Declaring both on the same element therefore throws
   away the custom width silently — and width is the one thing the standard
   properties cannot express, since `scrollbar-width` accepts only
   `auto | thin | none` and no length.

   So Blink and WebKit get the pseudo-elements and a real pixel width; Firefox
   gets the standard properties, behind a `@supports` that only matches engines
   which do NOT understand the pseudo-element.

   THE RESET BELOW IS LOAD-BEARING — without it none of this renders. Horizon's
   `base.css` already declares both properties on `html`, commented "Firefox"
   because that was the only engine that honoured them when it was written.
   Chromium honours them now, so that rule was quietly holding the whole browser
   on the standard path: measured before the reset, the gutter was 10px with a
   grey thumb and every `::-webkit-scrollbar` rule below was being ignored.
   Returning both to `auto` hands Blink back to the pseudo-elements. Both are
   needed — either one left specified is enough to keep the standard path.

   This wins on source order, not specificity: `html` against `html` is a tie,
   and `judybees-layout.css` loads at theme.liquid:56 while `base.css` goes in
   through `render 'stylesheets'` at line 29. Moving either would break it.
   ========================================================================== */
html {
  scrollbar-width: auto;
  scrollbar-color: auto;

  /* Reserves the scrollbar's column whether or not a scrollbar is currently
     drawn, so that hiding it never changes the width of the page.

     Without this the whole layout jumps sideways every time something locks
     scrolling — the search panel, the cart drawer, any dialog — because
     `html[scroll-lock] { overflow: hidden }` removes the scrollbar and hands
     its width back to the content. Measured at 1676: client width goes 1662 →
     1676 the instant the lock lands, so every element shifts 14px right.

     Pre-existing rather than new, but the wider bar above made it obvious:
     the jump has always been exactly the scrollbar's width, so it was 10px
     when Horizon's thin bar was in force.

     `stable` and not `stable both-edges` — the gutter belongs on the scrollbar
     side only; mirroring it would indent the left edge of every page to match. */
  scrollbar-gutter: stable;
}

::-webkit-scrollbar {
  width: 14px;
  height: 14px;
}

::-webkit-scrollbar-track {
  background: #0a0807;
}

/* The transparent border with `background-clip: content-box` is what insets
   the thumb — it leaves a 10px pill inside a 14px gutter instead of a bar that
   touches both edges. Padding does nothing on a scrollbar thumb, so this is
   the only way to buy that breathing room. */
::-webkit-scrollbar-thumb {
  background-color: var(--jb-amber, #fcb217);
  background-clip: content-box;
  border: 2px solid transparent;
  border-radius: 9999px;
}

/* Lifted toward white rather than darkened. On a black track a darker amber
   reads as the thumb receding on hover, which is backwards — the affordance
   should come forward. */
::-webkit-scrollbar-thumb:hover {
  background-color: color-mix(in srgb, var(--jb-amber, #fcb217) 80%, #fff);
}

/* Where a vertical and a horizontal bar meet. Left unpainted, Chromium fills
   it with the default grey, which is the one square that would give the old
   scrollbar away. */
::-webkit-scrollbar-corner {
  background: transparent;
}

@supports not selector(::-webkit-scrollbar) {
  html {
    /* `auto` rather than `thin` — Firefox has no length here, and `thin` would
       land noticeably narrower than the 14px above. */
    scrollbar-width: auto;
    scrollbar-color: var(--jb-amber, #fcb217) #0a0807;
  }
}


/* ==========================================================================
   hCaptcha badge
   --------------------------------------------------------------------------
   NOTHING IN THIS THEME ADDED IT. `#shop-hcaptcha-badge-container` is injected
   by Shopify's own `storefront-forms-hcaptcha` bundle, which loads on any page
   carrying a form Shopify protects — contact and comment forms, and the login,
   create-account and password-recovery pages. It is activated by DEFAULT on
   every Shopify store.

   It appeared on the homepage on 24 Aug 2026 because that is the day the
   homepage got its first protected form: the CTA split's `{% form 'customer' %}`
   newsletter card. Nothing was installed and no setting changed.

   Shopify only paints it once the visitor INTERACTS with the form, which is why
   it shows up mid-session rather than on load, and why it is easy to read as
   something an app injected.

   THE BADGE IS HIDDEN, THE PROTECTION IS NOT. This rule hides 214x55 pixels of
   floating furniture; the hCaptcha challenge still runs on every submission,
   which is what stops the newsletter card collecting bot signups. Junk
   subscribers are not merely untidy — they damage sender reputation, so
   turning the protection itself off would cost more than it saved.

   If the PROTECTION is ever what needs to go, it is a Shopify setting rather
   than a theme change: Online Store -> Preferences -> Spam protection. There is
   no Shopify setting for the badge alone, which is why this is CSS.

   `!important` because the container is written with an inline `style`
   attribute by that bundle, and an inline style outranks any selector. */
#shop-hcaptcha-badge-container {
  display: none !important;
}