/* ==========================================================================
   THE CHA — platform adapter
   Shopline injects DOM around every section and block that the ported
   stylesheet knows nothing about. These rules re-establish the origin's
   cascade. Playbook §11. Loaded AFTER global.css, on every template.
   ========================================================================== */

/* ---- §11.1 The section wrapper ----------------------------------------- *
 * Every section is wrapped in <div id="shopline-section-…" class="section">.
 * The wrapper's class is literally `section`, and global.css:59 styles
 * `.section { padding-block: var(--section-y) }` — so without this every
 * platform wrapper takes a section's padding and the whole page insets.
 * Authored .section elements INSIDE content keep their padding.            */
[id^="shopline-section-"].section,
[id^="shopline-section-"].section--tight {
  padding: 0;
  margin: 0;
}

/* The wrapper also caps position: sticky — a sticky header inside it only
   sticks within the wrapper's own height. Dissolve the box entirely.       */
[id^="shopline-section-"]:has(> .site-top),
[id^="shopline-section-"]:has(> header.site-header) {
  display: contents;
}

/* ---- §11.2 Block wrappers ---------------------------------------------- *
 * Every block renders inside <div id="shopline-block-…">, which becomes the
 * flex/grid item and breaks :nth-child, :last-child and sibling selectors.
 * `display: contents` restores the origin's parenting for paint; the unwrap
 * script removes them outright on the storefront.
 *
 * App blocks are the exception — app extensions scope their own CSS to
 * #shopline-block-<id> and go unstyled without the wrapper (§18.7). The
 * playbook identifies them by "___" in the id, but on this platform ___ is the
 * ordinary section/block separator and EVERY block id contains it, so that
 * guard would disable the rule entirely. Exclude the apps section instead.  */
[id^="shopline-block-"] {
  display: contents;
}
[id^="shopline-section-"][id*="apps"] [id^="shopline-block-"] {
  display: block;
}

/* ---- §11.3 Base theme cascade ------------------------------------------ *
 * base/index.css is gated off custom templates in layout/theme.html, but it
 * still loads on commerce templates. Two of its rules out-specify ported CSS:
 *   a:not(.button) at (0,1,1) beats every single-class link rule
 *   --sort-title-font / --sort-body-font default to a serif
 * Bump the brand faces at :root so native components inherit them.         */
:root {
  --sort-title-font: var(--font-sans);
  --sort-body-font: var(--font-sans);
}

/* Anchor rules re-stated at (0,1,1) so they win where base CSS loads. */
a.btn, a.btn:hover { color: var(--text-inverse); }
a.btn--soft, a.btn--soft:hover, a.btn--light, a.btn--light:hover { color: var(--text); }
a.btn--media, a.btn--media:hover { color: var(--cha-white); }
a.pill { color: var(--text-secondary); }
a.pill[aria-current="page"], a.pill[aria-checked="true"] { color: var(--text-inverse); }
.on-media a.pill { color: rgba(253, 252, 248, .84); }
.on-media a.pill[aria-current="page"] { color: var(--cha-white); }
.site-footer a, .site-footer a:hover { color: inherit; }
.site-footer a:hover { color: var(--cha-terra); }
.site-footer__credit a { color: var(--text-secondary); }

/* ---- §11.6 The overscroll flash ---------------------------------------- *
 * The platform ships its own skip link in layout/theme.html, parked off-screen
 * and still painted — mobile overscroll drags it into view as a stray pill.
 * Ours is already clipped in global.css; neutralise the platform's too.    */
.skip-to-content-link {
  position: absolute !important;
  width: 1px !important; height: 1px !important;
  margin: -1px !important; padding: 0 !important;
  overflow: hidden !important;
  clip-path: inset(50%) !important;
  white-space: nowrap !important;
}
.skip-to-content-link:focus {
  position: fixed !important; top: 1rem !important; left: 1rem !important;
  width: auto !important; height: auto !important; margin: 0 !important;
  padding: var(--s-3) var(--s-5) !important;
  overflow: visible !important; clip-path: none !important;
  z-index: 200;
}

/* ---- §11.7 all: revert also reverts the focus ring --------------------- *
 * Safety net for platform form controls the ported sheet does not style, so
 * a brand-coloured site never hands back Chrome's blue ring. Scoped to our
 * own sections; native commerce templates keep base styling deliberately.  */
[data-section-key] :is(input, select, textarea):focus-visible {
  outline: 2px solid var(--cha-ink);
  outline-offset: 3px;
}

/* The layout's own main wrapper must not add a box around ported pages. */
main#main:focus { outline: none; }

/* ---- Newsletter, where base CSS loads --------------------------------- *
 * The newsletter is a footer-group section, so it renders on EVERY template —
 * including the ones that keep base/index.css for their native components. Two
 * base rules reshape it there, and the band came out 11px short on the product
 * template while matching exactly on home:
 *   · the status paragraph is hidden (display:none), losing its 16px live-region
 *     line plus the 16px margin above it,
 *   · the submit button grows from 52px to 72px.
 * Restated here because platform-fixes.css loads after base/index.css in the
 * layout and therefore wins at equal specificity. Anything a group section
 * renders must be styled by CSS that loads everywhere (§12.6).           */
.newsletter .form-msg { display: block; }

/* The real cause of the 20px: the platform's form helper emits hidden inputs
 * (returnTo, form_type) and base CSS gives them a box. In a flex form whose
 * items already fill the row exactly, that extra item wraps onto a second line
 * and the whole form grows — the submit button then stretches to match, which
 * is what made it look like a button bug. A hidden input must never be a flex
 * item. */
input[type="hidden"] { display: none !important; }

/* "Subscribe" sits within about a pixel of the button's content width, so on
 * templates where base CSS loads it wraps to a second line and the button grows
 * from 52px to 72px — which reads as a broken button and moved the whole band.
 * The origin never wraps it. */
/* CLASS COLLISION, same family as .section (§11.1): the base theme also owns a
 * `.field` class, and its `.field::after` is a 50px block pseudo-element. Inside
 * the newsletter's flex form that inflated the flex line to 72px, which stretched
 * the submit button from 52px to 72px and moved the whole band — a "button bug"
 * whose cause was neither the button nor a text wrap.
 * Found by diffing the ported band against base-CSS and non-base-CSS templates. */
.newsletter .field::before,
.newsletter .field::after { content: none !important; }

/* …and the same collision carries a margin: base's `.field` has
 * margin-bottom: 20px. Margins sit OUTSIDE the rect, so the field still
 * measured 52px while its outer size was 72px — that set the flex line, the
 * submit button stretched to match, and the whole band moved 20px. Every
 * earlier suspect (hidden inputs, a text wrap, the form's own box) measured
 * identical on both templates, because none of them was the cause.
 * Zeroing it is safe: base's own fields on native templates are untouched. */
.newsletter .field { margin: 0; }

.newsletter form .btn { white-space: nowrap; }

/* ---- Cart bubble host ---------------------------------------------------- *
 * The platform's cart bubble is mounted in the header for its behaviour only —
 * our own pill is the visible control. Clipped rather than offset off-screen,
 * so it is never dragged into view by overscroll (§11.6). */
.cart-bubble-host {
  position: absolute;
  width: 1px; height: 1px;
  margin: -1px; padding: 0;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
  pointer-events: none;
}

/* ---- Cart drawer stacking ------------------------------------------------ *
 * <theme-cart-drawer> sits at the end of <body> as an inline element with no
 * z-index, and its panel is position:fixed with z-index:auto. Against the
 * ported design that loses: .bleed__scrim carries --z-overlay (2), so the hero's
 * scrim paints over an open drawer and it looks like the drawer never opened.
 * The panel was measurably in the right place (top 0, left 1000, 440x900,
 * opacity 1) the whole time — elementFromPoint at its centre returned the
 * scrim, which is what named the bug.
 *
 * Making the host a positioned block with the drawer z-index lifts the whole
 * subtree into its own stacking context. line-height:0 also removes the stray
 * 24px line box it contributed at the end of the document — every page was
 * 24px taller than the origin because of it.                                */
theme-cart-drawer {
  /* absolute, not relative: it still creates the stacking context that lifts the
     fixed panel above .bleed__scrim, but contributes nothing to document flow.
     In flow it added a line box (its empty <summary>) and every page measured
     taller than the origin — 24px before line-height:0, 10px after. */
  display: block;
  position: absolute;
  z-index: var(--z-modal);
  line-height: 0;
}

/* ==========================================================================
   Native cart drawer — dependency shim
   The drawer is rendered by layout/theme.html on EVERY template, so by §12.6
   everything it needs must be styled by CSS that loads on every template. Its
   own cart-drawer.css is self-contained for layout, but it reads the colour
   scheme variables, the z-index scale, the focus ring and a few typography
   classes — all of which are defined in base/index.css, which is deliberately
   gated off the custom-markup templates (§11.3).
   Without this the drawer opened on the home page with no colours, no padding
   and overlapping text.
   Values mirror theme.config.json's schemes, so the drawer looks the same
   whether or not base CSS happens to be loaded on a given template.
   ========================================================================== */
:root {
  --color-scheme-white: 253, 252, 248;
  --color-scheme-ink: 56, 56, 56;

  --z-index-fixed: 50;
  --z-index-popover: 100;

  --focus-ring-color: 56, 56, 56;
  --focus-ring-width: 2px;
  --focus-ring-offset: 3px;
}

.color-scheme-1 {
  --color-background: 253, 252, 248;      /* --cha-white  */
  --color-text: 56, 56, 56;               /* --cha-ink    */
  --color-light-text: 106, 101, 96;       /* --cha-mid    */
  --color-entry-line: 228, 226, 220;
  --color-image-background: 237, 233, 207;/* --cha-off    */
  --color-card-background: 253, 252, 248;
  --color-button-background: 56, 56, 56;
  --color-button-text: 253, 252, 248;
  --color-button-text-link: 56, 56, 56;
}
.color-scheme-2 {
  --color-background: 56, 56, 56;
  --color-text: 253, 252, 248;
  --color-light-text: 201, 199, 194;
  --color-entry-line: 90, 90, 90;
  --color-image-background: 74, 74, 74;
  --color-card-background: 56, 56, 56;
  --color-button-background: 253, 252, 248;
  --color-button-text: 56, 56, 56;
  --color-button-text-link: 253, 252, 248;
}

/* Typography classes the drawer markup borrows from the base theme. Our own
   sections never use these names, so defining them globally is safe. */
.title4 {
  font-family: var(--font-sans);
  font-size: var(--t-h4);
  font-weight: var(--weight-regular);
  line-height: var(--lh-snug);
  letter-spacing: var(--track-tight);
}
.body2 { font-family: var(--font-sans); font-size: .95rem; line-height: var(--lh-normal); }
.body3 { font-family: var(--font-sans); font-size: .9rem;  line-height: var(--lh-normal); }
.body6 { font-family: var(--font-sans); font-size: var(--t-micro); line-height: var(--lh-normal); }

/* The drawer's own panel: give it the brand ground and the pill button shape,
   so it reads as ours rather than as the base theme's. */
.cart-drawer__body { background: var(--surface); color: var(--text); }
.cart-drawer__body .button { border-radius: var(--r-pill); }

/* The native `.button` rule lives in base/index.css, so on the custom-markup
   templates the drawer's Checkout rendered as bare text. Re-state it as the
   brand's pill, scoped to the cart surfaces so it cannot leak into our own
   sections (which use .btn). */
.cart-drawer__body .button,
.cart-fixed-checkout .button,
.cart-drawer__body .shopline-element-buy-now {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  gap: var(--s-2);
  width: 100%;
  min-height: 48px;
  padding: .85rem 1.8rem;
  border: 0;
  border-radius: var(--r-pill);
  background: var(--cha-ink);
  color: var(--text-inverse);
  font-family: var(--font-sans);
  font-size: var(--t-small);
  font-weight: var(--weight-medium);
  letter-spacing: var(--track-wide);
  text-align: center;
  text-decoration: none;
  cursor: pointer;
  transition: background var(--d-fast) var(--ease);
}
.cart-drawer__body .button:hover,
.cart-fixed-checkout .button:hover { background: #262626; color: var(--text-inverse); }

.cart-drawer__body .button--secondary,
.cart-fixed-checkout .button--secondary {
  background: transparent;
  border: 1px solid var(--border-strong);
  color: var(--text);
}

/* The drawer's quantity stepper and its inputs also lean on base form styling. */
.cart-drawer__body input[type="number"],
.cart-drawer__body input[type="text"] {
  border: 1px solid var(--border-strong);
  border-radius: var(--r-md);
  background: transparent;
  color: var(--text);
  font-family: var(--font-sans);
  font-size: .9rem;
  text-align: center;
}

/* ---- The drawer's disclosure triangle ------------------------------------ *
 * <details class="cart-drawer"> carries an empty <summary>, which renders as
 * display:list-item with list-style-type:disclosure-closed — a ▶ marker. It sits
 * at the very end of the document (left 0, 17px wide) and, because the host
 * carries --z-modal, paints above everything: a stray arrow in the bottom-left
 * corner of every page. theme-modal drives the details' open state directly, so
 * the summary needs no marker and no box. display:block is what drops the
 * marker — a marker only exists on list-item.                              */
theme-cart-drawer summary {
  display: block;
  width: 0;
  height: 0;
  overflow: hidden;
  list-style: none;
}
theme-cart-drawer summary::-webkit-details-marker,
theme-cart-drawer summary::marker { display: none; content: ""; }

/* ---- Overscroll ground (§11.6, refined) ---------------------------------- *
 * §11.6 says to paint html with the design's ground, because body's background
 * never reaches the rubber-band area. True — but the region people actually
 * overscroll into is BELOW the footer, and the footer is the sunken tint, not
 * the page white. Painting html white left a pale band under the footer on every
 * page. The footer ends every template, so its ground is the right canvas
 * colour; body keeps the page ground for the document itself.              */
html { background: var(--surface-sunken); }
body { background: var(--surface); }