/*
 * RahkarTheme — classic-base override layer.
 *
 * PrestaShop core ALWAYS auto-loads the forked classic `assets/css/theme.css`
 * (200 KB of Bootstrap + Bootstrap-TouchSpin + classic theme rules). We can't
 * drop it — 41 templates use the Bootstrap grid (col-xs-*) and core JS widgets
 * (quantity spinner, modals, form validation) depend on its styles.
 *
 * theme.css loads AFTER our global chrome CSS (tokens/global/header/…) but with
 * the same specificity it wins, so its legacy globals (#wrapper bg, .h6 size,
 * .data-sheet cells, heading sizes, …) keep bleeding into the rahkar design.
 *
 * THIS sheet is registered with a very high priority (loads dead LAST, after
 * theme.css AND the per-page CSS), so a plain selector here beats theme.css with
 * no specificity gymnastics. Put global classic-base neutralizers here — keep it
 * SMALL and only for rules that genuinely fight the design (not a place for new
 * component styles; those belong in their own component sheet).
 *
 * Same job for THIRD-PARTY MODULE globals: modules we may not edit (§1 of
 * RAHKAR-THEME-GUIDE.md) sometimes ship unscoped element selectors that leak
 * across the whole shop. Neutralising them from the theme side is the sanctioned
 * remedy (guide §1, option 2) — see the SVG icon guard below.
 */

/* ── Let the page grow past the viewport so bottom padding can be reserved ────
 * theme.css ships an unscoped `body,html{height:100%}`. On `body` that is not a
 * minimum — it PINS the content box to exactly one viewport, and anything
 * taller simply overflows it. Padding then sits at the end of that pinned box
 * (viewport + padding), not at the end of the real content, so on any page
 * longer than one screen the reserve is silently thrown away.
 *
 * That is what hid the footer's copyright and developer credit on mobile:
 * bottom-nav.css correctly reserves `64px + safe-area` on `body` for the fixed
 * dock (~62px tall), but the reserve never landed after the last element, so
 * the dock painted straight over it.
 *
 * `height:auto` restores normal flow; `min-height:100%` keeps what the classic
 * rule was actually reaching for — a body that still fills a short page — and
 * resolves against `html`, whose own `height:100%` is deliberately left alone.
 * Fixes every page at once, which is why it belongs here rather than in
 * bottom-nav.css. */
body {
  height: auto;
  min-height: 100%;
}

/* ── Defend the icon contract against unscoped module `svg {}` rules ──────────
 * Every icon in this theme is `<svg fill="none" stroke="currentColor">` — 143 of
 * the 148 inline SVGs in templates/ — i.e. the outline look comes from the
 * `fill="none"` PRESENTATION ATTRIBUTE.
 *
 * `modules/ets_affiliatemarketing/views/css/front.css` opens with a bare
 *     svg { fill: currentColor; vertical-align: -2px }
 * and a CSS declaration ALWAYS beats a presentation attribute (attributes sit at
 * the very bottom of the cascade, below even the UA sheet). One unscoped rule in
 * a loyalty module therefore filled in every icon on the site — header, footer,
 * cards, buybox — solid black.
 *
 * The guard re-asserts exactly what the markup already declares, nothing more:
 * matching on the attribute makes it (0,1,1) vs the module's (0,0,1), so it wins
 * on SPECIFICITY and does not depend on load order — it stays correct even if
 * that module (or any future one) is registered later than this sheet. Icons
 * that are genuinely filled — `fill="currentColor"`, brand logos, inner shapes
 * carrying their own fill — never match, so they are untouched.
 *
 * `fill` is an inherited SVG property, so children without their own fill
 * inherit `none` from the root exactly as they did from the attribute.
 *
 * vertical-align goes back to the initial `baseline`: the module's -2px nudge
 * only shows on inline-level icons (flex/grid items ignore it), but where it
 * did apply it knocked our icons off the text baseline. Scoped to the theme's
 * own icon signature so the module's own widgets keep whatever it intended. */
svg[fill="none"] {
  fill: none;
}
svg[fill="none"],
svg[stroke="currentColor"] {
  vertical-align: baseline;
}

/* The classic base paints the whole page shell grey (#f6f6f6). The rahkar
   design is white surfaces on a white page — let the (white) body show through. */
#wrapper {
  padding-top: 0;
  background: #FFF;
}
.container{
  padding-left: 0 !important;
  padding-right: 0 !important;
}
.done {
  margin-right: 0;
}
#header {
  background: transparent !important;
  box-shadow: none;
}
.product-prices div {
  margin-bottom: 0;
}

/* ── Custom checkbox / radio — global, theme-wide restyle ─────────────────────
   The classic base (theme.css) renders every .custom-checkbox / .custom-radio
   (checkout terms & gift, carrier & payment pickers, address selector, account
   consent, faceted filters) as a grey #979797 box/circle with a #24b9d7 dot —
   off-brand and dated. We restyle the VISUALS only — border, radius, fill, tick,
   dot — with design tokens, and leave the classic POSITIONING/layout untouched so
   no form shifts (checkout radios float, the account box is absolutely placed).
   The native <input> stays hidden by the classic base (opacity:0 overlay) and
   keeps firing its events; we only repaint the fake span.

   This sheet loads dead-last (priority 200), so these plain selectors beat
   theme.css by source order. The faceted-filter column keeps its own richer skin
   (scoped under `#search_filters .rpa-facet__label`, higher specificity), so it
   overrides these rules and is unaffected. */

/* Checkbox box — square, rounded, primary fill on check (skip colour swatches). */
.custom-checkbox input[type="checkbox"] + span:not(.color) {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  border: 1.5px solid var(--wp--preset--color--border, #d3d7de);
  border-radius: 5px;
  background: var(--wp--preset--color--base, #fff);
  transition: background-color 0.15s ease, border-color 0.15s ease;
}
.custom-checkbox input[type="checkbox"]:checked + span:not(.color) {
  background: var(--wp--preset--color--primary, #0a66c2);
  border-color: var(--wp--preset--color--primary, #0a66c2);
}
.custom-checkbox input[type="checkbox"] + span .checkbox-checked {
  margin: 0;
  font-size: 1rem;
  line-height: 1;
}
.custom-checkbox input[type="checkbox"]:checked + span .checkbox-checked {
  color: #fff;
}

/* Radio circle — token border; centred primary dot on check. */
.custom-radio {
  border-color: var(--wp--preset--color--border, #d3d7de);
  background: var(--wp--preset--color--base, #fff);
  transition: border-color 0.15s ease;
}
.custom-radio:has(input[type="radio"]:checked) {
  border-color: var(--wp--preset--color--primary, #0a66c2);
}
.custom-radio input[type="radio"]:checked + span {
  top: 50%;
  left: 50%;
  width: 10px;
  height: 10px;
  background-color: var(--wp--preset--color--primary, #0a66c2);
  transform: translate(-50%, -50%);
}

/* «سایر مشخصات» (product-details.tpl's data-sheet) — classic ships an
 * unconditional flex-wrap layout with a permanent grey background + its own
 * padding/font-weight on every name/value cell, PLUS a second rule just for
 * the grey (`.product-features>dl.data-sheet dd.value:nth-of-type(even),
 * …dt.name:nth-of-type(even) { background:#f6f6f6 }`) whose 4-class
 * specificity beats product-details-band.css's own
 * `.rh-pdetails__body--specs .data-sheet > dt/dd` rule outright — load order
 * never even comes into it. The result was every spec row wrapped in a
 * swollen grey box instead of our plain bordered list. This mirrors classic's
 * own selector structure (so the specificity is at least as high) under our
 * scope, so ours is the one that actually renders; `!important` on the
 * background is the one property that still needs it since the nth-of-type
 * variant is genuinely a wash on specificity and this is more legible than
 * chasing one more selector segment. */
.rh-pdetails__body--specs .data-sheet dd.value,
.rh-pdetails__body--specs .product-features > dl.data-sheet dt.name {
  min-height: 0;
  margin: 0;
  padding: 10px 0;
  text-transform: none;
}
.rh-pdetails__body--specs .product-features > dl.data-sheet dt.name,
.rh-pdetails__body--specs .product-features > dl.data-sheet dd.value {
  background: transparent !important;
}
.rh-pdetails__body--specs .product-features > dl.data-sheet dt.name {
  padding-inline-end: 20px;
  font-weight: var(--rh-fw-strong);
  color: var(--wp--preset--color--foreground, #1a1d23);
}
.rh-pdetails__body--specs .data-sheet dd.value {
  font-weight: var(--rh-fw-base, 400);
}

/* Header nav-link hover turning cyan (#24b9d7) — classic ships a bare
 * `#header a:hover { color:#24b9d7 }`. The ID selector outranks every
 * rahkar hover rule that says "just inherit the current colour" (
 * `.rahkar-site-header a`, `.rh-toplinks__link:hover`, …), regardless of
 * load order — an ID always beats any number of plain classes. Matching the
 * same ID selector here is the only way to out-rank it; loading last then
 * settles it in our favour. */
#header a:hover {
  color: inherit;
  text-decoration: none;
}