/*!
Theme Name:   Fanbotica HUD
Theme URI:    https://fanbotica.com
Description:  Child theme of Storefront — dark HUD design system shared with the
              HaptiStick minisite (fanbotica_redesign_2026/01_MINISITO_JOYFFB).
              Built as a clean Gutenberg/WooCommerce-block theme, deliberately
              free of the Divi Builder page-authoring layer.
Author:       Fanbotica
Template:     storefront
Version:      0.1.0
Text Domain:  fanbotica-hud
*/

/* ==========================================================================
   Design tokens — mirrored 1:1 from the minisite's globals.css. Keep these
   two files in sync by hand; there is no shared build step between the
   Next.js site and this WordPress theme.
   ========================================================================== */
:root {
  /* Anthracite ladder, not near-black — was #0a0b0d/#121419/#171a20 (pure
     black-adjacent, "troppo scuro... sfondo nero pece" per direct
     feedback). Each step is a genuinely distinguishable lighter grey, not
     a few points of luminance apart, so panels read as physically raised
     surfaces catching light rather than flat colour blocks on black. */
  --background: #1b1e24;
  --surface: #23272f;
  --surface-raised: #2c313a;
  --foreground: #e7e9ec;
  --muted: #979da8;
  --border: #3a4049;

  /* HUD semantic palette v2 — cyan is banned project-wide. amber = primary/
     interactive, red = critical alert, green = live/nominal status, ice =
     desaturated instrument data line. Each role has exactly one meaning. */
  --accent: #ffb32c;
  --accent-foreground: #2a1c04;
  --critical: #ff6b52;
  --critical-foreground: #2a0d07;
  --live: #4ade80;
  --data: #93a8b3;

  /* A separate, lighter still "reading panel" tone for long-form article
     body copy, one more step up the same ladder — running text still
     wants the softest contrast of anything on the page even after the
     base palette lightened. */
  --content-surface: #31363f;
  --content-foreground: #dde0e5;

  /* Panel depth — a thin light catch on the top edge + a soft cast shadow
     underneath, the actual mechanism a "cockpit with lights and shadows"
     needs: flat same-tone panels can't read as dashboard instruments no
     matter how the hue is tuned, only real light/shadow modelling can.
     Applied to the header, nav, footer, and every card surface below. */
  --panel-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.06), 0 2px 10px rgba(0, 0, 0, 0.4);

  --font-sans: "IBM Plex Sans", -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
  --font-mono: "JetBrains Mono", ui-monospace, "SFMono-Regular", Menlo, monospace;
  /* Nameplate face — tall/narrow all-caps, for project/product titles
     styled like a vehicle badge (real site reference: "caratteri stretti
     e alti"). Fallback condenses a system sans via font-stretch so the
     look survives even before/without the webfont loading. */
  --font-display: "Bebas Neue", "Arial Narrow", -apple-system, sans-serif;

  /* Spacing scale — used for section rhythm everywhere below instead of ad-hoc
     rem values, so vertical spacing reads as a system rather than guesswork. */
  --space-1: 0.5rem;
  --space-2: 0.75rem;
  --space-3: 1rem;
  --space-4: 1.5rem;
  --space-5: 2rem;
  --space-6: 3rem;
  --space-7: 4rem;

  --radius: 10px;
  --transition: 160ms ease;
}

/* ==========================================================================
   Base — dark theme lock, same as the minisite (no light/dark toggle).
   ========================================================================== */
html {
  background: var(--background);
}

/* IMPORTANT re: !important below — Storefront's Customizer options generate
   an inline <style id="storefront-style-inline-css"> block targeting these
   exact same bare selectors (body, a, h1..h6, .site-header, .site-footer...).
   The theory was "our stylesheet enqueues after theirs, so we win ties on
   load order alone" — proven wrong three separate times in this project on
   tied-specificity selectors (submenu background, footer text/background,
   and here): Storefront wins anyway for reasons not fully root-caused, so
   rather than keep chasing cascade order, every bare selector Storefront's
   inline CSS also targets gets `!important` here as a standing policy, not
   just reactively per bug report. */
body {
  background-color: var(--background) !important;
  /* Same ambient top-right light source as the minisite's own Hero
     (Hero.tsx: a 640px radial-gradient at `color-mix(foreground 8%,
     transparent)`, faint on purpose — "a light in the room", not a glow
     tied to one component). Ported to `body` with `background-attachment:
     fixed` so it reads as one light source for the whole site as you
     scroll, not a decoration repeated per-section — the multi-page
     equivalent of the minisite's single full-height Hero. This alone does
     a lot of the "meno cupo" work: it's the same dark palette, just no
     longer flat matte-black. */
  background-image: radial-gradient(
    circle at top right,
    color-mix(in srgb, var(--foreground) 8%, transparent) 0%,
    transparent 45%
  );
  background-attachment: fixed;
  background-repeat: no-repeat;
  color: var(--foreground) !important;
  font-family: var(--font-sans);
  font-size: 16px;
  line-height: 1.65;
}

/* No underlines anywhere, sitewide, per explicit direction — links are
   already differentiated by colour (amber, shifting to coral on
   hover/focus) everywhere on the site, so colour alone carries the "this
   is a link" signal instead of doubling up with an underline too. Applies
   to every state (rest/hover/focus/visited) — a partial removal (e.g.
   keeping it on hover only) wasn't what was asked. */
a {
  color: var(--accent) !important;
  text-decoration: none !important;
  transition: color var(--transition), transform var(--transition);
}
a:hover,
a:focus {
  color: var(--critical) !important;
  text-decoration: none !important;
}
/* Pressed/active feedback — same `active:scale-[0.98]` press-down the
   minisite uses on its own buttons/links (Hero.tsx), not previously
   present here at all, per the "no hover/pressed effect" report. */
a:active {
  transform: scale(0.98);
}

/* Real bug, reported with a screenshot: clicking a nav link (or any button)
   left a bright violet ring around it — that's the browser/OS's own
   default focus outline, in its own default colour, never overridden here.
   `a:focus` above only ever changed the TEXT colour, the outline itself
   was untouched this whole project. Not simply deleted (`outline: none`
   with nothing in its place is a real accessibility regression for anyone
   navigating by keyboard) — replaced with our own amber ring instead, so
   it still reads as "focused" but in the site's own palette. `:focus-
   visible` (not bare `:focus`) so it still only shows for keyboard/
   switch-control navigation, matching modern browsers' own intent, not
   the "as soon as you click a plain mouse click" behaviour the screenshot
   showed. Form inputs already have their own dedicated amber-border focus
   treatment above (`input:focus` etc.) — intentionally not touched here.

   UPDATE: first pass used `:focus-visible` on the theory that a plain
   mouse click "shouldn't" trigger it per the modern browser convention —
   but the ring was still reported present after a real click on a real
   browser, and this project's own test tooling can't reliably reproduce
   real click-vs-keyboard focus-visible heuristics to root-cause exactly
   why (script-dispatched clicks/`.focus()` don't behave like a real user
   click for this purpose). Switched to plain `:focus`, which always
   matches regardless of input modality or any given browser's heuristic —
   guarantees our own colour wins every time instead of depending on a
   heuristic this project has no reliable way to test. */
a:focus {
  outline: 2px solid var(--accent) !important;
  outline-offset: 2px;
}

/* Real bug #2, also reported with a screenshot: on a real BUTTON (nearly
   all of them sitewide are solid amber-filled, per the blanket `button`
   rule above), the amber focus ring above just drew a second, slightly
   larger amber shape around an already-amber shape — same colour on both,
   so it read as one thickened/doubled border rather than a distinct
   "you're focused here" indicator. A plain link doesn't have this problem
   (no fill behind it), which is why `a:focus` above keeps the accent
   ring — buttons get their own version instead, in `--foreground`
   (light neutral) so it's visibly a SEPARATE ring from the button's own
   fill, not a second outline in the exact same hue. Selector list is the
   same set of "gets amber-filled by the blanket rule" elements as that
   rule further down uses — several of these (.wp-block-button__link,
   .wp-element-button, .woocommerce a.button) are real `<a>` tags styled
   to look like buttons, e.g. the homepage's "Tutorial Step by Step" CTA,
   so `a:focus` above would otherwise still win there without this list
   covering them explicitly. */
button:focus,
.button:focus,
.menu-toggle:focus,
.wp-block-button__link:focus,
.wp-element-button:focus,
.woocommerce a.button:focus,
.woocommerce button.button:focus,
.woocommerce #respond input#submit:focus,
.woocommerce input.button:focus,
.woocommerce-page a.button:focus {
  outline: 2px solid var(--foreground) !important;
  outline-offset: 2px;
}

/* Real aesthetic regression from the rule above, caught with a screenshot:
   Portfolio/product cards (`.fanbotica-archive-card`, WooCommerce's own
   `li.product`) already have their OWN focus/hover language — a dashed
   border that turns solid amber (`:hover` a few sections down in each
   case) — the card itself is a plain <article>/<li>, but it contains real
   <a> links (image, title, "Continua a leggere"), so the generic outline
   above landed on those and stacked a second amber rectangle just outside
   the card's own border. Single indicator reads better than two — the
   card border already does this job clearly on its own, so the extra
   outline is just suppressed here rather than fought with a second colour.

   UPDATE: this was reported as still happening after the fix above — it
   was, but on a THIRD and FOURTH card system this rule never covered:
   `.fanbotica-projects-grid` (the small Pedro/LRC/Rocker Tubie grid on
   the homepage) and `.fanbotica-hero-project` (the big PEDRO hero above
   it) are both hand-built Gutenberg blocks, structurally unrelated to
   `.fanbotica-archive-card` despite looking similar, so neither was ever
   in scope of the original fix. Added below now that both are on a
   dashed border of their own too. */
.fanbotica-archive-card a:focus,
.woocommerce ul.products li.product a:focus,
.fanbotica-projects-grid a:focus,
.fanbotica-hero-project a:focus {
  outline: none !important;
}

::selection {
  background: var(--accent);
  color: var(--accent-foreground);
}

/* Typography scale — sized/tracked to read as a deliberate hierarchy rather
   than the browser defaults Storefront otherwise falls back to. Tight
   negative letter-spacing on the two largest sizes only (instrument-panel
   numerals read tighter at scale), body copy stays at normal tracking. */
h1, h2, h3, h4, h5, h6 {
  color: var(--foreground) !important;
  font-family: var(--font-sans);
  font-weight: 600;
  line-height: 1.2;
  margin-bottom: var(--space-3);
}

h1 { font-size: 2.75rem; letter-spacing: -0.02em; }
h2 { font-size: 2rem; letter-spacing: -0.01em; }
h3 { font-size: 1.375rem; }
h4 { font-size: 1.125rem; }

p { color: var(--foreground); }

code, kbd, pre, .price, .sku, .amount {
  font-family: var(--font-mono);
}

hr {
  border-color: var(--border);
}

/* Eyebrow tag — small uppercase label used above a hero/section heading,
   the same "instrument placard" motif as the minisite's Hero eyebrow tags.
   Angular chamfer + monospace + wide tracking instead of a rounded pill. */
.fanbotica-eyebrow {
  display: inline-block;
  font-family: var(--font-mono);
  font-size: 0.75rem;
  font-weight: 500;
  letter-spacing: 0.12em;
  text-transform: uppercase;
  color: var(--accent);
  background: color-mix(in srgb, var(--accent) 12%, transparent);
  border: 1px solid color-mix(in srgb, var(--accent) 35%, transparent);
  padding: 0.3rem 0.75rem;
  margin-bottom: var(--space-3);
}

/* ==========================================================================
   Layout — matched 1:1 to the minisite's own container system
   (`mx-auto max-w-7xl px-6`, used identically in Hero/Footer/every section
   there): 1280px max width, centered, a fixed 24px side gutter at every
   breakpoint (the minisite doesn't scale the gutter per-breakpoint either).
   Storefront's own `.col-full` is narrower (~1064px, fluid-percentage
   based) and reserves side space for a sidebar column — overridden here
   rather than left as a second, different width system running alongside
   the minisite's. No sidebar exists any more (see functions.php), so
   `.content-area` goes to the full container width instead of floating
   at Storefront's ~786px content + sidebar split.
   ========================================================================== */
.col-full {
  max-width: 1280px !important;
  padding-left: 1.5rem !important;
  padding-right: 1.5rem !important;
}

.content-area {
  width: 100% !important;
  float: none !important;
}

.storefront-sidebar,
.widget-area {
  display: none !important;
}

/* ==========================================================================
   Site header / branding
   ========================================================================== */
.site-header {
  background-color: var(--surface);
  border-bottom: 1px solid var(--border);
  padding-top: var(--space-3);
  padding-bottom: var(--space-3);
  box-shadow: var(--panel-shadow);
  position: relative;
  z-index: 2;
}

.site-header {
  background-color: var(--surface) !important;
}

.site-header .site-branding {
  padding: var(--space-2) 0;
}

.site-header .site-branding .site-title,
.site-header .site-branding .site-title a {
  color: var(--foreground) !important;
  font-weight: 600;
}

.site-header .site-description {
  color: var(--muted) !important;
  font-size: 0.875rem;
}

.site-header-cart .cart-contents,
.site-header a {
  color: var(--foreground) !important;
}

.site-header-cart .cart-contents {
  font-family: var(--font-mono);
  gap: 0.5rem;
}

.site-header-cart .cart-contents:hover,
.site-header a:hover {
  color: var(--accent) !important;
}

/* Mini-cart dropdown (opens on clicking the header cart icon) — same
   `#f0f0f0` light-grey pattern as everywhere else Storefront draws a
   floating panel; never checked until now because it only appears on
   click, not on a plain page load. */
.site-header-cart .widget_shopping_cart {
  background-color: var(--surface-raised) !important;
  border: 1px solid var(--border);
  border-radius: var(--radius);
  box-shadow: var(--panel-shadow), 0 12px 24px rgba(0, 0, 0, 0.4);
}

.site-header-cart .woocommerce-mini-cart-item,
.site-header-cart .mini_cart_item {
  border-bottom-color: var(--border) !important;
  color: var(--foreground);
}

/* Mini-cart item thumbnails are the same white-studio-backdrop product
   photography as the shop grid — softened with the same "photo-on-glass"
   treatment below instead of sitting as a bare white square in the
   dropdown. */
.site-header-cart .woocommerce-mini-cart-item img,
.site-header-cart .mini_cart_item img {
  border-radius: 6px;
  background-color: var(--background);
  filter: brightness(0.9) contrast(0.96);
  box-shadow: inset 0 0 10px 2px rgba(0, 0, 0, 0.35);
}

.site-header-cart .woocommerce-mini-cart-item a:not(.button),
.site-header-cart .mini_cart_item a:not(.button) {
  color: var(--foreground) !important;
}
.site-header-cart .woocommerce-mini-cart-item a:not(.button):hover {
  color: var(--accent) !important;
}

.site-header-cart .woocommerce-Price-amount,
.site-header-cart .quantity {
  color: var(--muted) !important;
}

.site-header-cart .total .woocommerce-Price-amount {
  color: var(--accent) !important;
  font-weight: 600;
}

/* Real remaining white: the `<p>` wrappers Storefront puts around the
   subtotal row and the button row (`.woocommerce-mini-cart__total`,
   `.woocommerce-mini-cart__buttons`) carry their own `#f5f5f5` background,
   separate from the item rows already covered above — found via a live
   scan of every computed background-color inside the dropdown, not by
   guessing (the earlier pass only touched the text/button colors inside
   these wrappers, never the wrapper's own background). */
.site-header-cart .woocommerce-mini-cart__total,
.site-header-cart .woocommerce-mini-cart__buttons {
  background-color: transparent !important;
}

.site-header-cart .remove_from_cart_button {
  color: var(--critical) !important;
}

.site-header-cart .woocommerce-mini-cart__buttons .button {
  background-color: var(--accent) !important;
  color: var(--accent-foreground) !important;
}
.site-header-cart .woocommerce-mini-cart__buttons .button.checkout {
  background-color: var(--surface) !important;
  color: var(--foreground) !important;
  border: 1px solid var(--border);
}

/* ==========================================================================
   Primary navigation — simplified per explicit feedback: the amber
   background-tint box on hover was unwanted ("elimina l'effetto over di
   colore ambra trasparente"); text-color-only feedback on hover/active,
   matching the minisite's own nav links (Hero.tsx: `transition-colors
   hover:text-foreground`, plain color swap, no background). Kept the
   `scale(0.97)` press feedback on `:active` — that's a shape/motion cue,
   not a color box, and wasn't part of what was flagged.
   ========================================================================== */
.main-navigation {
  background-color: var(--surface) !important;
}

.main-navigation ul li a {
  color: var(--foreground) !important;
  font-size: 0.9375rem;
  font-weight: 500;
  transition: color var(--transition), transform var(--transition);
  display: block;
}

.main-navigation ul li a:hover,
.main-navigation ul li.current-menu-item > a {
  color: var(--accent) !important;
}

.main-navigation ul li a:active {
  transform: scale(0.97);
  color: var(--critical) !important;
}

.main-navigation ul ul,
.main-navigation ul.menu ul.sub-menu,
.main-navigation ul.nav-menu ul.children {
  background-color: var(--surface-raised) !important;
  border: 1px solid var(--border);
  box-shadow: 0 12px 24px rgba(0, 0, 0, 0.4);
}

.main-navigation ul ul li a,
.main-navigation ul.menu ul.sub-menu li a {
  color: var(--foreground) !important;
  font-weight: 400;
}

/* Real bug, reported with a screenshot: mobile menu text sat flush against
   the screen edge, at EVERY nesting level (top level, "Robot in Kit",
   "Artropodi"...). Root cause is Storefront's own default for the
   handheld/mobile nav specifically: top-level items get `padding: .875em
   0` (zero horizontal, confirmed in storefront/style.css) — the desktop
   dropdown version of this same menu does get horizontal padding on its
   own submenus, but the separate handheld nav markup this theme actually
   uses on phones doesn't inherit that. Applied one consistent horizontal
   margin at every depth instead of chasing each level's own default. */
.handheld-navigation ul.menu li a,
.handheld-navigation ul.menu ul li a,
.main-navigation ul li a {
  padding-left: var(--space-3) !important;
  padding-right: var(--space-3) !important;
}

/* The expand/collapse arrow button is a plain <button>, so it also picked
   up the sitewide blanket `button{...}` fill/padding treatment (same bug
   shape as the hamburger toggle and the cookie-modal close button earlier
   this session) — Storefront's own version is meant to be fully
   transparent and flush inside its row, not a filled pill. Reset it back,
   then pulled its right edge in from the literal screen edge (`right: 0`
   in Storefront's own rule) by one spacing unit so it doesn't touch the
   border either. Only the button's own box is touched here — whatever
   draws the visible arrow itself (a pseudo-element inside/around it) isn't
   targeted, so the arrow itself is untouched, just better positioned. */
.handheld-navigation .dropdown-toggle {
  background-color: transparent !important;
  padding: 0 !important;
  border-radius: 0 !important;
  right: var(--space-3) !important;
  color: var(--foreground) !important;
}

/* REAL follow-up bug, reported with a screenshot: the arrow went nearly
   invisible once the orange fill above was removed — it was only ever
   legible against that fill, never against this dark page background on
   its own. Confirmed by direct experiment that `.dropdown-toggle::after`
   is genuinely the element drawing it (display:none on it removes the
   visible mark; display:none on ::before alone does not) — but NOT what
   colours it: `color` and `border-color` both changed on the pseudo-
   element with no visible effect, and `background-color` did draw
   something, but a plain rectangle, not the arrow shape — the wrong fix,
   would have looked worse than the problem. Left un-set rather than
   guessed at further: this project has a known, separate limitation in
   this exact area (pseudo-element/hover state doesn't read back reliably
   in the preview tooling used to verify this file), and forcing a
   property that isn't actually the right one risks another visible
   regression like the rectangle above. Needs a look on a real device/
   real DevTools to find the actual property before touching this again —
   flagged here rather than left undocumented. */

/* REAL bug, confirmed via a genuine mouse-hover test (not a screenshot
   limitation): `.main-navigation ul.menu ul.sub-menu li a` two rules above
   is a 3-class selector (0,3,4 specificity) matching Storefront's own
   selector shape — MORE specific than a 1-class `:hover` selector here
   (0,2,4), so it kept winning over the hover colour even with `!important`
   on both sides (specificity, not source order, decides ties between two
   `!important` declarations). The submenu never actually lit up on hover
   despite the rule existing, because that rule was never specific enough
   to beat its own resting-state sibling. Matched the same 3-class shape
   for :hover/:active too. */
.main-navigation ul ul li a:hover,
.main-navigation ul.menu ul.sub-menu li a:hover {
  color: var(--accent) !important;
}

.main-navigation ul ul li a:active,
.main-navigation ul.menu ul.sub-menu li a:active {
  color: var(--critical) !important;
}

/* ==========================================================================
   Content surfaces
   ========================================================================== */
/* This opaque background-color was the actual reason the top-right ambient
   glow (on `body`) never reached past a thin strip near the very top of
   the page: `.content-area`/`#content` is what actually sits under almost
   the entire page below the header, painted the SAME flat colour directly
   over body's gradient, blocking it completely. Transparent here lets the
   glow wash across the real page body — instrument panels (cards, header,
   footer) still sit on top of it with their own opaque surfaces + the
   panel-shadow depth below, so the ambient light reads as coming from
   behind/above the panels rather than being erased by them. */
.content-area,
#content,
.site-content {
  background-color: transparent;
  color: var(--foreground);
}

.storefront-sidebar,
.widget-area {
  background-color: var(--surface);
  color: var(--foreground);
}

.widget-area .widget-title,
.widget-title {
  color: var(--foreground);
  border-bottom: 1px solid var(--border);
}

/* ==========================================================================
   Buttons — sitewide amber primary action, same tone as the minisite CTAs.
   `.wp-block-button__link` AND `.wp-element-button` (the "Tutorial Step by
   Step" anchor carries BOTH classes) are two separate core-WordPress button
   classes, neither originally covered here. `.wp-element-button` in
   particular has a REAL (not `:where()`-zero-specificity) rule in
   `global-styles-inline-css` — `border-radius:9999px` among other things —
   tied specificity with our own single-class selector, and it was winning
   the border-radius specifically (background/color were already `!important`
   from the first pass and displayed correctly; the pill-shaped corners were
   the one property that slipped through unprotected). `!important` on
   every property in this block now, not just background/color — the
   established pattern all session: don't trust tied-specificity + load
   order on this site, force it.
   ========================================================================== */
.button,
button,
input[type="submit"],
input[type="button"],
.wp-block-button__link,
.wp-element-button,
.woocommerce a.button,
.woocommerce button.button,
.woocommerce #respond input#submit,
.woocommerce input.button,
.woocommerce-page a.button {
  background-color: var(--accent) !important;
  color: var(--accent-foreground) !important;
  border: none !important;
  border-radius: 6px !important;
  font-weight: 600 !important;
  padding: 0.7em 1.4em !important;
  transition: background-color var(--transition), transform var(--transition);
}

.button:hover,
button:hover,
input[type="submit"]:hover,
.wp-block-button__link:hover,
.wp-element-button:hover,
.woocommerce a.button:hover,
.woocommerce button.button:hover,
.woocommerce input.button:hover {
  background-color: #ffc250 !important;
  color: var(--accent-foreground) !important;
  transform: translateY(-1px);
}

.wp-block-button__link:active,
.wp-element-button:active {
  transform: scale(0.97);
}

/* NOT a "danger/secondary" flag — WooCommerce itself puts `.alt` on its
   own PRIMARY actions (`single_add_to_cart_button button alt`, checkout,
   place order). Assumed the opposite (Divi's convention, where .alt reads
   as secondary/red) and it made "Aggiungi al carrello" render coral
   instead of amber — a real bug, found on a real product page. `.button`
   alone already carries the amber treatment above; nothing extra needed
   here, so this block is just documentation of why it's gone.               */

/* REAL bug, mobile only, never caught until tested on a real phone: the
   blanket `button { padding: 0.7em 1.4em !important }` above also (of
   course — it's a bare `button` selector) hit Storefront's own mobile nav
   toggle, `button.menu-toggle`. Storefront reserves an ASYMMETRIC left
   padding (2.617924em) there on purpose — its hamburger/✕ icon is three
   CSS-drawn bars (`::before`/`span::before`/`::after`), absolutely
   positioned at `left: 1em` inside the button — and our symmetric override
   collapsed that reserved space, so the icon rendered directly on top of
   the "M" of "Menu" instead of beside it (open state: the ✕ over the "M"
   the same way). Also bumped size/padding overall — genuinely too small a
   tap target/type size on an actual phone, not just the overlap bug. */
button.menu-toggle {
  font-size: 1rem !important;
  padding: 0.75em 1.25em 0.75em 2.75em !important;
  max-width: none !important;
}

/* ==========================================================================
   WooCommerce product cards / shop archive
   ========================================================================== */
.woocommerce ul.products li.product,
.woocommerce-page ul.products li.product {
  background-color: var(--surface);
  /* Dashed, same signature card treatment as the Portfolio archive and the
     two homepage project grids — product cards were the one card system
     left on a plain solid border. */
  border: 1px dashed color-mix(in srgb, var(--accent) 55%, transparent);
  border-radius: var(--radius);
  padding: var(--space-3);
  box-shadow: var(--panel-shadow);
  transition: border-color var(--transition), transform var(--transition), box-shadow var(--transition);
}

.woocommerce ul.products li.product:hover {
  border-color: var(--accent);
  transform: translateY(-3px);
}

/* "Il bianco è troppo forte" — this is real studio photography on plain
   white backdrops (not the CAD renders flood_fill_bg.py targets), so a
   per-pixel background removal isn't the right tool here. A mild filter +
   an inset vignette instead: dims/softens the backdrop everywhere without
   touching the subject enough to risk "irriconoscibile" the way a harder
   crush did earlier in this project — the white recedes toward the panel
   tone at the edges (glass/vignette read) rather than sitting as a raw
   white rectangle punched into the dark UI. */
.woocommerce ul.products li.product img {
  border-radius: calc(var(--radius) - 4px);
  background-color: var(--background);
  filter: brightness(0.9) contrast(0.96);
  box-shadow: inset 0 0 18px 4px rgba(0, 0, 0, 0.35);
}

/* Product name as an instrument data-plate: a small glowing "pilot light"
   dot + boxed plaque, same motif as the minisite's status indicators —
   colour is real data (WooCommerce's own instock/outofstock/onbackorder
   classes on li.product), not decoration: green = available, amber = on
   backorder, coral = out of stock. */
.woocommerce ul.products li.product {
  --stock-color: var(--live);
}
.woocommerce ul.products li.product.outofstock {
  --stock-color: var(--critical);
}
.woocommerce ul.products li.product.onbackorder {
  --stock-color: var(--accent);
}

.woocommerce ul.products li.product .woocommerce-loop-product__title,
.woocommerce ul.products li.product h2,
.woocommerce ul.products li.product h3 {
  display: flex;
  flex-direction: column;
  align-items: flex-start;
  gap: 0.4rem;
  color: var(--foreground);
  font-size: 0.9375rem;
  margin: var(--space-2) 0 var(--space-1);
}

/* Stock status as a "spia di avviso": colored text inside a rounded-border
   chip — the HaptiStick app's own warning/status tag shape — not a round
   micro-LED dot (explicit feedback: replace the dot style everywhere it
   was used). The label text itself is the real WooCommerce stock state,
   still genuine data, not decoration. */
.woocommerce ul.products li.product .woocommerce-loop-product__title::before,
.woocommerce ul.products li.product h2::before,
.woocommerce ul.products li.product h3::before {
  content: "Disponibile";
  display: inline-block;
  font-family: var(--font-mono);
  font-size: 0.625rem;
  font-weight: 500;
  letter-spacing: 0.07em;
  text-transform: uppercase;
  padding: 0.2rem 0.55rem;
  border-radius: 999px;
  color: var(--stock-color);
  background: color-mix(in srgb, var(--stock-color) 14%, transparent);
  border: 1px solid color-mix(in srgb, var(--stock-color) 40%, transparent);
}
.woocommerce ul.products li.product.outofstock .woocommerce-loop-product__title::before,
.woocommerce ul.products li.product.outofstock h2::before,
.woocommerce ul.products li.product.outofstock h3::before {
  content: "Esaurito";
}
.woocommerce ul.products li.product.onbackorder .woocommerce-loop-product__title::before,
.woocommerce ul.products li.product.onbackorder h2::before,
.woocommerce ul.products li.product.onbackorder h3::before {
  content: "In arrivo";
}

.woocommerce ul.products li.product .price {
  color: var(--accent);
  font-weight: 600;
}

.woocommerce ul.products li.product .price del {
  color: var(--muted);
}

.woocommerce span.onsale {
  background-color: var(--critical);
  color: var(--critical-foreground);
}

.woocommerce nav.woocommerce-pagination ul {
  border-color: var(--border);
}
.woocommerce nav.woocommerce-pagination ul li {
  border-color: var(--border);
  background: var(--surface);
}
.woocommerce nav.woocommerce-pagination ul li a,
.woocommerce nav.woocommerce-pagination ul li span {
  color: var(--foreground);
}
.woocommerce nav.woocommerce-pagination ul li a:hover,
.woocommerce nav.woocommerce-pagination ul li span.current {
  background: var(--accent);
  color: var(--accent-foreground);
}
/* REAL bug: the active-page number still showed Storefront's own light
   grey (`rgb(230,230,230)`) — the rule above never actually beat it.
   Storefront's OWN compiled+inline CSS both target
   `.woocommerce-pagination .page-numbers li .page-numbers.current`, a
   4-class selector (woocommerce-pagination, page-numbers[ul],
   page-numbers, current) — MORE specific than ours above (3 classes +
   4 elements loses on the class tier regardless of element count).
   Matched Storefront's exact shape + `!important`. */
.woocommerce-pagination .page-numbers li .page-numbers.current {
  background: var(--accent) !important;
  color: var(--accent-foreground) !important;
  border-radius: 4px;
}

/* Same bug, same fix, on the BLOG/category pagination — a different
   wrapper class (`.pagination`, from `the_posts_pagination()`) from the
   WooCommerce one above (`.woocommerce-pagination`), so the earlier rule
   never matched it. Storefront's compiled+inline CSS mirror the same
   4-class shape here too: `.pagination .page-numbers li .page-numbers.current`. */
.pagination .page-numbers li .page-numbers.current {
  background: var(--accent) !important;
  color: var(--accent-foreground) !important;
  border-radius: 4px;
}

/* ==========================================================================
   Single product
   ========================================================================== */
/* Same data-plate treatment as the shop-loop title (see there for why the
   colour is real stock-status data, not decoration) — scaled up for a
   heading rather than a card label. */
.woocommerce div.product.outofstock {
  --stock-color: var(--critical);
}
.woocommerce div.product.onbackorder {
  --stock-color: var(--accent);
}
.woocommerce div.product:not(.outofstock):not(.onbackorder) {
  --stock-color: var(--live);
}

.woocommerce div.product .product_title {
  display: flex;
  flex-direction: column;
  align-items: flex-start;
  gap: 0.55rem;
  color: var(--foreground);
}

/* Same rounded-rect status chip as the shop-loop title, scaled up. */
.woocommerce div.product .product_title::before {
  content: "Disponibile";
  display: inline-block;
  font-family: var(--font-mono);
  font-size: 0.6875rem;
  font-weight: 500;
  letter-spacing: 0.08em;
  text-transform: uppercase;
  padding: 0.25rem 0.65rem;
  border-radius: 999px;
  color: var(--stock-color);
  background: color-mix(in srgb, var(--stock-color) 14%, transparent);
  border: 1px solid color-mix(in srgb, var(--stock-color) 40%, transparent);
}
.woocommerce div.product.outofstock .product_title::before {
  content: "Esaurito";
}
.woocommerce div.product.onbackorder .product_title::before {
  content: "In arrivo";
}

/* Product photos are real photography on plain white studio backdrops
   (not the CAD renders the flood-fill script targets) — framed in the
   same dark inset-plate treatment as everywhere else on the site instead
   of a flat white rectangle sitting directly on the dark page, plus the
   same softening filter as the shop grid so the white itself reads calmer
   against the panel.
   REAL bug fixed here: this border+padding used to sit directly on
   `.woocommerce-product-gallery__image` — the exact <div> FlexSlider
   treats as one "slide" and measures for its own width math. FlexSlider
   2 (2012-era) computes each slide's width as `viewportWidth -
   boxPadding` (border+padding, read via jQuery) — correct ONLY under the
   old content-box model it was written for, where padding/border ADD on
   top of `width`. This site is border-box everywhere (a standard modern
   reset), where `width` already INCLUDES padding/border — so FlexSlider's
   subtraction doubly-shrank every slide by our 34px frame, an error that
   compounded with each slide index in its translateX() math: by the 5th
   thumbnail the viewport was showing a ~137px sliver of TWO different
   photos at once ("come se il nastro scorresse in modo non sincronizzato").
   Confirmed live via FlexSlider's own internal state
   (`$('.woocommerce-product-gallery').data('flexslider')`) and by forcing
   `box-sizing:content-box` on the slide as a first attempt — that fixed
   each slide's own rendered SIZE (content 408px + 34px frame = 442px,
   matching the viewport again) but NOT the translateX() step distance,
   which FlexSlider still drives off its inner `computedW` (408px, content
   only) rather than the true outer per-slide spacing (442px) — so the
   misalignment on navigation persisted regardless. The real fix is to
   give FlexSlider a slide `<div>` with NO padding/border of its own at
   all (so `boxPadding` measures 0 and every internal calculation — width
   AND step distance — uses the same correct number), and move the framed-
   card look one level down onto the `<a>` inside it instead, which
   FlexSlider never measures or resizes. */
.woocommerce div.product div.images {
  background-color: var(--surface);
  border: 1px solid var(--border);
  border-radius: var(--radius);
  padding: var(--space-3);
}
.woocommerce div.product .woocommerce-product-gallery__image a {
  display: block;
  background-color: var(--surface);
  border: 1px solid var(--border);
  border-radius: var(--radius);
  padding: var(--space-3);
}
.woocommerce div.product .woocommerce-product-gallery__image img {
  filter: brightness(0.9) contrast(0.96);
  box-shadow: inset 0 0 28px 6px rgba(0, 0, 0, 0.3);
  border-radius: calc(var(--radius) - 4px);
}

/* YITH Wishlist's own frontend stylesheet already exposes exactly this as
   a CSS custom-property hook (`color: var(--add-to-wishlist-icon-color,
   #000)` on the heart SVG) — no specificity fight needed, just set the
   variable to the theme's own red token instead of the plugin's black
   default. The icon markup itself ships as an OUTLINE-only heart
   (`fill="none"` inline attribute, `stroke="currentColor"`) — "falla
   completamente rossa anche dentro" means it should read as a solid heart,
   not just a red outline, so `fill` is set to the same token too. A CSS
   `fill` declaration always beats a presentation attribute like this
   inline `fill="none"`, regardless of specificity, so no !important
   needed here either. */
.woocommerce div.product {
  --add-to-wishlist-icon-color: var(--critical);
}
.woocommerce div.product .yith-wcwl-icon-svg {
  fill: var(--critical);
}

/* Storefront's own sticky "add to cart" bar (appears once you scroll past
   the main product image) ships plain white with grey text — completely
   unstyled by our theme so far ("la barra bianca in alto... deve essere
   dei colori del sito"). */
.storefront-sticky-add-to-cart {
  background-color: var(--surface-raised) !important;
  border-bottom: 1px solid var(--border);
  box-shadow: var(--panel-shadow);
}
.storefront-sticky-add-to-cart__content-title {
  color: var(--foreground) !important;
}
.storefront-sticky-add-to-cart__content-price {
  color: var(--muted) !important;
}
.storefront-sticky-add-to-cart__content-price .amount {
  color: var(--accent) !important;
}

/* Google/Apple Pay express-checkout button: the button graphic itself
   renders INSIDE a cross-origin Stripe.js iframe, which we have no CSS
   access to — and Google/Apple's own brand guidelines only allow their
   button to render in a small set of fixed presets (black "dark", or
   white/outlined "light"/"light-outline", switched via
   `payment_request_button_theme` in the payment gateway's own settings,
   already set to light-outline). There's no supported way to recolour the
   button itself to the site's amber. A themed card/panel around it was
   tried and reverted on request ("meglio senza cornice come prima") —
   left borderless/transparent, sitting directly on the page again. */

.woocommerce div.product .flex-control-thumbs {
  margin-top: var(--space-3) !important;
  gap: var(--space-2);
}
.woocommerce div.product .flex-control-thumbs li img {
  border: 1px solid var(--border);
  border-radius: 6px;
  background-color: var(--surface);
  opacity: 0.6;
  filter: brightness(0.9) contrast(0.96);
  transition: opacity var(--transition), border-color var(--transition);
}
.woocommerce div.product .flex-control-thumbs li img.flex-active,
.woocommerce div.product .flex-control-thumbs li img:hover {
  opacity: 1;
  border-color: var(--accent);
}

.woocommerce div.product p.price,
.woocommerce div.product span.price {
  color: var(--accent);
}

.woocommerce div.product .product_meta,
.woocommerce div.product .product_meta a {
  color: var(--muted);
}

.woocommerce table.shop_attributes {
  border-color: var(--border);
}
.woocommerce table.shop_attributes th,
.woocommerce table.shop_attributes td {
  background: var(--surface);
  border-color: var(--border);
  color: var(--foreground);
}

.woocommerce div.product .woocommerce-tabs ul.tabs li {
  background: var(--surface);
  border-color: var(--border);
}
.woocommerce div.product .woocommerce-tabs ul.tabs li.active {
  background: var(--background);
}
.woocommerce div.product .woocommerce-tabs ul.tabs li a {
  color: var(--foreground);
}

/* The "riquadro bianco grande" on product description tabs: several
   products (e.g. Rocker Tubie) have long-form descriptions built the old
   classic-editor way, with `[caption]`-shortcode images
   (`.wp-caption` wrapper + `.wp-caption-text`) — a completely different
   code path from the WooCommerce gallery/loop images already covered
   above, never styled until now. Same photo-on-glass treatment as the
   rest of the product images, framed instead of floating bare white. */
.woocommerce div.product .woocommerce-Tabs-panel--description .wp-caption {
  background-color: var(--surface);
  border: 1px solid var(--border);
  border-radius: var(--radius);
  padding: var(--space-3);
  max-width: 100% !important;
}
.woocommerce div.product .woocommerce-Tabs-panel--description .wp-caption img {
  filter: brightness(0.9) contrast(0.96);
  box-shadow: inset 0 0 24px 5px rgba(0, 0, 0, 0.3);
  border-radius: calc(var(--radius) - 4px);
}
.woocommerce div.product .woocommerce-Tabs-panel--description .wp-caption-text {
  color: var(--muted);
  font-size: 0.85rem;
  padding-top: var(--space-2);
  text-align: center;
}
.woocommerce div.product .woocommerce-Tabs-panel--description img:not(.wp-caption img) {
  filter: brightness(0.9) contrast(0.96);
  border-radius: var(--radius);
  background-color: var(--surface);
  border: 1px solid var(--border);
  padding: var(--space-2);
}

/* WooCommerce's own notice banners (login prompt, coupon prompt, order
   errors) — default solid blue/red/green fills that clash hard with the
   HUD palette (spotted on checkout: a bright blue bar with no relation to
   any of our 4 semantic colors). Same flat-panel + left-accent-border
   language as the rest of the site instead of a solid color flag. */
.woocommerce-info,
.woocommerce-message {
  background-color: var(--surface) !important;
  border-top-color: var(--data) !important;
  color: var(--foreground) !important;
}
.woocommerce-info::before,
.woocommerce-message::before {
  color: var(--data) !important;
}
.woocommerce-error {
  background-color: var(--surface) !important;
  border-top-color: var(--critical) !important;
  color: var(--foreground) !important;
}
.woocommerce-error::before {
  color: var(--critical) !important;
}
.woocommerce-info a,
.woocommerce-message a,
.woocommerce-error a {
  color: var(--accent) !important;
}

/* ==========================================================================
   Cart / Checkout tables — the WooCommerce `table.shop_table` markup shared
   by the cart page and the checkout page's order-review table, never
   styled before this pass (found on a real cart page with an item in it:
   default light-grey WooCommerce table, barely-visible text on light rows).
   ========================================================================== */
.woocommerce table.shop_table {
  border-color: var(--border);
  color: var(--foreground);
}

.woocommerce table.shop_table thead th {
  background-color: var(--surface-raised);
  color: var(--foreground);
  border-bottom: 1px solid var(--border);
  font-weight: 600;
}

.woocommerce table.shop_table tbody tr,
.woocommerce table.shop_table tbody td,
.woocommerce table.shop_table tfoot tr,
.woocommerce table.shop_table tfoot td,
.woocommerce table.shop_table tfoot th {
  background-color: var(--surface);
  border-color: var(--border);
  color: var(--foreground);
}

.woocommerce table.shop_table .product-name a {
  color: var(--foreground);
}
.woocommerce table.shop_table .product-name a:hover {
  color: var(--accent);
}

.woocommerce table.shop_table .product-thumbnail img {
  background-color: var(--background);
  border-radius: 6px;
  border: 1px solid var(--border);
}

.woocommerce table.shop_table .product-remove a {
  color: var(--muted);
}
.woocommerce table.shop_table .product-remove a:hover {
  color: var(--critical);
}

/* Coupon field row (`td.actions` in the cart table) and the shipping-method
   picker inside cart totals — both still showed a plain white box behind
   dark text on a real cart with an item in it (WooCommerce's own default
   styling, un-themed). */
.woocommerce-cart table.cart td.actions,
.woocommerce table.shop_table td.actions {
  background-color: var(--surface) !important;
}

.woocommerce-shipping-methods,
.woocommerce-shipping-totals td,
#shipping_method,
.woocommerce-shipping-calculator {
  background-color: transparent !important;
  color: var(--foreground) !important;
}
.woocommerce-shipping-methods li label,
#shipping_method li label,
.woocommerce-shipping-totals .amount {
  color: var(--foreground) !important;
}

/* Found via a live scan of every element's computed background-color on a
   real checkout page (not a selector guess): `.woocommerce-checkout-review-
   order` — the DIV wrapping the review-order table — carries its own white
   background independent of the `-table` element already covered below. */
.woocommerce-checkout-review-order {
  background-color: transparent !important;
}

/* Grouped-product table (e.g. "Stazione di Controllo per Rocker Tubie Kit
   Base") — a real WooCommerce PRODUCT TYPE (`table.woocommerce-grouped-
   product-list`), completely separate markup from the shop_table above
   (cart/checkout) or the description-tab wp-caption images fixed earlier —
   found via a live scan on this exact page, never covered before. Same
   dark-table treatment as the rest of the site, plus the stock-status
   colour language already established elsewhere (amber = backorder,
   coral = out of stock) applied to this table's own `.stock` notices. */
.woocommerce table.woocommerce-grouped-product-list {
  border-color: var(--border);
}
.woocommerce table.woocommerce-grouped-product-list tr {
  border-bottom: 1px solid var(--border);
  transition: background-color var(--transition);
}
.woocommerce table.woocommerce-grouped-product-list tr:hover {
  background-color: var(--surface-raised);
}
.woocommerce table.woocommerce-grouped-product-list td {
  background-color: var(--surface) !important;
  border-color: var(--border);
  padding: var(--space-2) var(--space-2);
}
.woocommerce table.woocommerce-grouped-product-list .woocommerce-grouped-product-list-item__label a {
  color: var(--foreground);
  font-weight: 500;
}
.woocommerce table.woocommerce-grouped-product-list .woocommerce-grouped-product-list-item__label a:hover {
  color: var(--accent);
}
.woocommerce table.woocommerce-grouped-product-list .woocommerce-grouped-product-list-item__price {
  color: var(--accent);
  font-weight: 600;
}
.woocommerce table.woocommerce-grouped-product-list .woocommerce-price-suffix {
  color: var(--muted);
  font-weight: 400;
}
.woocommerce table.woocommerce-grouped-product-list .stock {
  font-family: var(--font-mono);
  font-size: 0.75rem;
  text-transform: uppercase;
  letter-spacing: 0.03em;
  font-weight: 500;
}
.woocommerce table.woocommerce-grouped-product-list .stock.available-on-backorder {
  color: var(--accent);
}
.woocommerce table.woocommerce-grouped-product-list .stock.out-of-stock {
  color: var(--critical);
}
.woocommerce table.woocommerce-grouped-product-list .quantity input.qty {
  width: 3.5em;
  text-align: center;
}

/* Cart totals / order-review sidebar box (both cart and checkout use
   `.cart_totals` / `.woocommerce-checkout-review-order-table`) */
.woocommerce .cart_totals,
.woocommerce-checkout-review-order-table {
  background-color: var(--surface);
  border: 1px solid var(--border);
  border-radius: var(--radius);
  padding: var(--space-4);
}

/* The "Subtotale"/"Spedizione"/"Totale" cells all kept light boxes behind
   them — Storefront's generic inline rules `table:not(.has-background) th
   { background-color: #f8f8f8 }` and `table:not(.has-background) tbody td
   { background-color: #fdfdfd }` reach into this `.cart_totals` table
   specifically because it's a plain `<table>` without the `.has-background`
   class Storefront's own rule is trying to exempt. Matched both. */
.cart_totals table th,
.cart_totals table td,
.woocommerce-checkout-review-order-table th,
.woocommerce-checkout-review-order-table td {
  background-color: transparent !important;
  color: var(--foreground) !important;
}
.cart_totals table th,
.woocommerce-checkout-review-order-table th {
  color: var(--muted) !important;
}

.woocommerce-checkout #payment {
  background-color: var(--surface) !important;
  border-radius: var(--radius);
}
.woocommerce-checkout #payment div.payment_box {
  background-color: var(--surface-raised) !important;
  color: var(--foreground);
}
.woocommerce-checkout #payment div.payment_box::before {
  border-bottom-color: var(--surface-raised) !important;
}
.woocommerce-checkout #payment ul.payment_methods li label {
  color: var(--foreground);
}

/* Found by reading actual computed styles on a real checkout with items in
   cart, not guessed — three more white boxes independent of the ones
   above: the payment-method `<li>` itself (not just its expanded
   `.payment_box`), WooCommerce Payments' card-fields `<fieldset>`, and the
   `.form-row.place-order` wrapper around the terms checkboxes + submit
   button (all were near-white regardless of #payment's own dark
   background, because each carries its own explicit background-color). */
.woocommerce-checkout ul.payment_methods li.wc_payment_method {
  background-color: var(--surface) !important;
}
.woocommerce-checkout fieldset.wc-payment-form {
  background-color: var(--surface-raised) !important;
  border-radius: 6px;
}
.woocommerce-checkout .form-row.place-order {
  background-color: transparent !important;
}
.woocommerce-checkout .woocommerce-terms-and-conditions-wrapper,
.woocommerce-checkout .woocommerce-privacy-policy-text,
.woocommerce-checkout .woocommerce-terms-and-conditions-wrapper p,
.woocommerce-checkout .woocommerce-privacy-policy-text p {
  color: var(--muted) !important;
}
.woocommerce-checkout .woocommerce-form__label-for-checkbox {
  color: var(--foreground) !important;
}

/* Card-field iframe internals (Stripe/WooPayments) are cross-origin — the
   browser will never let page CSS reach inside them, so the white card
   number/expiry/CVC fields stay white regardless. Framing the fieldset
   above at least stops it reading as a stray floating white card; the
   fields themselves are a real, structural limit, not something left
   unstyled by oversight. */

/* The "Nazione/Country" field renders through Select2 (a JS widget that
   draws its own elements over the native <select>, invisible to a plain
   `select { }` rule) — same near-white-box shape as everything above. */
.select2-container--default .select2-selection--single {
  background-color: var(--surface) !important;
  border: 1px solid var(--border) !important;
  border-radius: 6px !important;
}
.select2-container--default .select2-selection--single .select2-selection__rendered {
  color: var(--foreground) !important;
}
.select2-dropdown {
  background-color: var(--surface-raised) !important;
  border-color: var(--border) !important;
}
.select2-container--default .select2-results__option {
  color: var(--foreground) !important;
}
.select2-container--default .select2-results__option--highlighted[aria-selected] {
  background-color: var(--accent) !important;
  color: var(--accent-foreground) !important;
}
.select2-search--dropdown .select2-search__field {
  background-color: var(--surface) !important;
  color: var(--foreground) !important;
  border-color: var(--border) !important;
}

/* ==========================================================================
   Forms / inputs (cart quantity, checkout, search, comment form)
   ========================================================================== */
input[type="text"],
input[type="email"],
input[type="tel"],
input[type="number"],
input[type="password"],
input[type="search"],
input[type="url"],
textarea,
select {
  background-color: var(--surface) !important;
  border: 1px solid var(--border);
  color: var(--foreground) !important;
  border-radius: 6px;
  padding: 0.6em 0.8em;
}

input:focus,
textarea:focus,
select:focus {
  border-color: var(--accent);
  outline: none;
}

input[type="checkbox"],
input[type="radio"] {
  accent-color: var(--accent);
}

/* Comment form labels — plain <label> text isn't covered by the input rules
   above and was inheriting whatever ambient color a given section left
   behind (illegible on the GDPR consent checkbox specifically). */
.comment-form label,
.comment-form .comment-notes,
.comment-form .required-field-message {
  color: var(--foreground) !important;
}

/* Real layout bug, not just color: Storefront floats the Nome/Email/Sito
   web fields as 3 columns (`.comment-form-author/-email/-url { float:left/
   right; width:29.4% }`, storefront/style.css) and nothing after them
   clears that float — the GDPR-consent checkbox paragraph (added by the
   wp-gdpr-compliance plugin, right after the 3 columns in the DOM) was
   rendering UNDERNEATH/overlapping the floated Sito-web column instead of
   dropping below all three, which is what actually caused the "white box
   overlapping unreadable text" the user saw — not a color problem at all. */
.comment-form-wpgdprc,
.comment-form .form-submit {
  clear: both;
}

/* ==========================================================================
   Cookie consent bar (gdpr-cookie-compliance / "Moove GDPR" plugin) — never
   themed since it went live; still showed its plugin default (white bar,
   dark text) against the dark HUD site. The plugin's own admin-configured
   colours are written into a per-page inline <style> block AFTER this
   stylesheet loads, so plain color overrides here would lose that fight on
   source order alone — same specificity-tie problem as Storefront's
   Customizer inline CSS elsewhere in this file, same fix: !important on
   every rule, not just on the ones that first broke. Selectors taken from
   the plugin's own PHP templates (gdpr-modules/infobar/*.php), not guessed.
   ========================================================================== */
#moove_gdpr_cookie_info_bar {
  background-color: var(--surface-raised) !important;
  border-top: 1px solid var(--border) !important;
  box-shadow: var(--panel-shadow) !important;
  color: var(--foreground) !important;
}

.moove-gdpr-cookie-notice,
.moove-gdpr-cookie-notice p {
  color: var(--foreground) !important;
}

.moove-gdpr-cookie-notice a {
  color: var(--accent) !important;
  text-decoration: underline !important;
}
.moove-gdpr-cookie-notice a:hover {
  color: var(--critical) !important;
}

/* Accept — the one primary action, same amber-fill treatment as every
   other primary CTA sitewide ("Aggiungi al carrello", coupon apply, ecc.). */
#moove_gdpr_cookie_info_bar .mgbutton.moove-gdpr-infobar-allow-all {
  background-color: var(--accent) !important;
  color: var(--accent-foreground) !important;
  border: none !important;
  box-shadow: none !important;
  opacity: 1 !important;
}
#moove_gdpr_cookie_info_bar .mgbutton.moove-gdpr-infobar-allow-all:hover {
  background-color: var(--critical) !important;
  color: var(--critical-foreground) !important;
}

/* Reject / Settings — secondary actions, only rendered at all if enabled in
   the plugin's own settings; outlined rather than filled so Accept stays
   the one obviously "primary" button. */
#moove_gdpr_cookie_info_bar .mgbutton.moove-gdpr-infobar-reject-btn,
#moove_gdpr_cookie_info_bar .mgbutton.moove-gdpr-infobar-settings-btn {
  background-color: transparent !important;
  color: var(--foreground) !important;
  box-shadow: inset 0 0 0 1px var(--border) !important;
  opacity: 1 !important;
}
#moove_gdpr_cookie_info_bar .mgbutton.moove-gdpr-infobar-reject-btn:hover,
#moove_gdpr_cookie_info_bar .mgbutton.moove-gdpr-infobar-settings-btn:hover {
  background-color: var(--surface) !important;
  color: var(--accent) !important;
  box-shadow: inset 0 0 0 1px var(--accent) !important;
}

/* Close (X) — same "dark icon on dark background = invisible" shape as the
   Bloom popup close-button bug fixed earlier in this file, different
   plugin, identical root cause. */
.moove-gdpr-infobar-close-btn {
  color: var(--foreground) !important;
}
.moove-gdpr-infobar-close-btn:hover {
  color: var(--accent) !important;
}
.moove-gdpr-infobar-close-btn .moovegdpr-arrow-close {
  border-color: var(--foreground) !important;
}
.moove-gdpr-infobar-close-btn:hover .moovegdpr-arrow-close {
  border-color: var(--accent) !important;
}

/* ==========================================================================
   Cookie SETTINGS modal ("Impostazioni" link in the consent bar above opens
   this — a completely separate template from the bar itself, gdpr-modules/
   modal/*.php, not gdpr-modules/infobar/*.php) — never themed until now,
   still the plugin's stock white/light "Panoramica privacy" screen even
   after the bar itself was fixed. Selectors straight from those templates.
   ========================================================================== */
#moove_gdpr_cookie_modal .moove-gdpr-modal-content {
  background-color: var(--surface-raised) !important;
  color: var(--foreground) !important;
}
#moove_gdpr_cookie_modal .moove-gdpr-modal-left-content {
  background-color: var(--surface) !important;
  border-right: 1px solid var(--border) !important;
}
#moove_gdpr_cookie_modal .moove-gdpr-modal-right-content {
  background-color: var(--surface-raised) !important;
}
/* The footer bar is its OWN separately-styled element (`background-color:
   #f1f1f1` in the plugin's own CSS), not part of `.moove-gdpr-modal-right-
   content` above despite sitting visually inside it — missed on the first
   pass, which is why "Salva le modifiche" read as washed-out: its (already
   correctly light) text was landing on this still-light background, not a
   broken button, just a contrast collision from an unfixed sibling. */
#moove_gdpr_cookie_modal .moove-gdpr-modal-footer-content {
  background-color: var(--surface) !important;
  border-top: 1px solid var(--border) !important;
}
#moove_gdpr_cookie_modal .moove-gdpr-modal-title,
#moove_gdpr_cookie_modal .tab-title,
#moove_gdpr_cookie_modal .moove-gdpr-tab-main-content,
#moove_gdpr_cookie_modal .moove-gdpr-tab-main-content p,
#moove_gdpr_cookie_modal .moove-gdpr-tab-main-content li {
  color: var(--foreground) !important;
}
#moove_gdpr_cookie_modal hr {
  border-color: var(--border) !important;
}

/* Left sidebar tab list ("Panoramica privacy" / "Cookie strettamente
   necessari" / "Cookie Policy") — plain text buttons by default, the
   active one distinguished only by the plugin's own light-theme
   background; recoloured the same way but on our own dark surfaces. */
#moove_gdpr_cookie_modal .moove-gdpr-tab-nav {
  background-color: transparent !important;
  color: var(--muted) !important;
}
#moove_gdpr_cookie_modal .moove-gdpr-tab-nav:hover {
  color: var(--accent) !important;
}
#moove_gdpr_cookie_modal li.menu-item-on .moove-gdpr-tab-nav,
#moove_gdpr_cookie_modal li.menu-item-selected .moove-gdpr-tab-nav {
  background-color: var(--surface-raised) !important;
  color: var(--accent) !important;
}

/* Footer buttons ("Attiva tutti" / "Salva le modifiche" / "Rifiuta tutti"
   if enabled) — same primary/secondary split as the consent bar itself. */
#moove_gdpr_cookie_modal .mgbutton.moove-gdpr-modal-allow-all {
  background-color: var(--accent) !important;
  color: var(--accent-foreground) !important;
  box-shadow: none !important;
}
#moove_gdpr_cookie_modal .mgbutton.moove-gdpr-modal-save-settings,
#moove_gdpr_cookie_modal .mgbutton.moove-gdpr-modal-reject-all {
  background-color: transparent !important;
  color: var(--foreground) !important;
  box-shadow: inset 0 0 0 1px var(--border) !important;
}
#moove_gdpr_cookie_modal .mgbutton.moove-gdpr-modal-save-settings:hover,
#moove_gdpr_cookie_modal .mgbutton.moove-gdpr-modal-reject-all:hover {
  color: var(--accent) !important;
  box-shadow: inset 0 0 0 1px var(--accent) !important;
}

/* Close (X) — REAL bug, reported with a screenshot: an orange square
   overlapping a blue circle. Both are the SAME button, both a real plugin
   element, not a coincidence with an unrelated popup. `.moove-gdpr-modal-
   close` is a plain `<button>`, so the sitewide blanket `button{...}` rule
   near the top of this file (background/padding/border-radius, meant for
   real text buttons like "Aggiungi al carrello") also caught this one —
   the plugin sizes the button AND its inner icon span both fixed at
   60x60px expecting the button to stay perfectly round with zero padding;
   our added padding shrank the button's own content box well below 60px,
   so the icon span (still 60x60, unaffected — it has its own explicit
   size) overflowed outside the now-smaller, now-orange, now-square button
   box instead of filling it. Fix is two-part: opt this button back out of
   the blanket rule entirely (transparent/round/no padding, like the
   plugin intended), then recolour its icon's own hardcoded plugin blue
   (#0c4da2) to the theme's accent so it doesn't just swap one off-theme
   colour for another. Same reasoning applied to the bar's own close
   button for safety, even though its different inner markup (a bare
   `<i>`, not a `.gdpr-icon` span) meant it never showed the overflow. */
#moove_gdpr_cookie_modal .moove-gdpr-modal-close,
#moove_gdpr_cookie_info_bar .moove-gdpr-infobar-close-btn {
  background-color: transparent !important;
  padding: 0 !important;
  border-radius: 50% !important;
}
#moove_gdpr_cookie_modal .moove-gdpr-modal-close {
  color: var(--foreground) !important;
}
#moove_gdpr_cookie_modal .moove-gdpr-modal-close:hover {
  color: var(--accent) !important;
}
#moove_gdpr_cookie_modal .moove-gdpr-modal-close .gdpr-icon {
  background-color: var(--accent) !important;
  border-color: var(--accent) !important;
  color: var(--accent-foreground) !important;
}
#moove_gdpr_cookie_modal .moove-gdpr-modal-close:hover .gdpr-icon {
  background-color: var(--critical) !important;
  border-color: var(--critical) !important;
}
#moove_gdpr_cookie_modal .moove-gdpr-modal-close .moovegdpr-arrow-close {
  border-color: var(--accent-foreground) !important;
}

/* ==========================================================================
   Comments (WordPress core comment list + Storefront's own comment styles)
   ========================================================================== */
.comment-list .comment-meta cite,
.comment-list .comment-meta .fn {
  color: var(--foreground) !important;
  font-weight: 600;
}

.comment-list .comment-meta a.comment-date,
.comment-list .comment-meta a.comment-date time {
  color: var(--muted) !important;
}
.comment-list .comment-meta a.comment-date:hover {
  color: var(--accent) !important;
}

/* The actual bug: Storefront's inline Customizer CSS sets
   `#comments .comment-list .comment-content .comment-text { background-
   color: #f8f8f8 }` (near-white) — once our own `body { color: ... }` fix
   made text light everywhere, this specific bubble became light text on a
   background that stayed light, the "commenti illeggibili in riquadri
   bianchi" report. Matched selector specificity again rather than guessing. */
.comment-list .comment-content .comment-text,
#comments .comment-list .comment-content .comment-text {
  background-color: var(--surface) !important;
  color: var(--foreground) !important;
  border: 1px solid var(--border);
}

.comment-list .comment-content .comment-text p {
  color: var(--foreground) !important;
}

.comment-list .reply a.comment-reply-link {
  color: var(--accent) !important;
  transition: color var(--transition), transform var(--transition);
}
.comment-list .reply a.comment-reply-link:hover {
  color: var(--critical) !important;
}
.comment-list .reply a.comment-reply-link:active {
  transform: scale(0.97);
}

.comment-reply-title {
  color: var(--foreground) !important;
}

.comment-list .comment-body #respond {
  background-color: var(--background);
  padding: var(--space-4);
  border-radius: var(--radius);
}

/* ==========================================================================
   Homepage — Open Source Projects grid + PEDRO hero (migrated from Divi's
   Theme Builder "Homepage" body template, post 25078 — see the migration
   note in fanbotica_local_wordpress.md).
   ========================================================================== */
.fanbotica-hero-project {
  margin: var(--space-3) 0 var(--space-6);
  padding-bottom: var(--space-6);
  border-bottom: 1px solid var(--border);
}

.fanbotica-hero-project .wp-block-column:last-child {
  padding-left: var(--space-5);
}

.fanbotica-hero-project figure.wp-block-image {
  background-color: var(--surface);
  /* Dashed + hover colour-shift, same signature treatment as the other two
     card systems on this page (.fanbotica-projects-grid below, and
     .fanbotica-archive-card on the Portfolio archive) — was a plain static
     solid border, the one card-like element on the site with no hover
     feedback at all despite wrapping a real link. */
  border: 1px dashed color-mix(in srgb, var(--accent) 55%, transparent);
  border-radius: var(--radius);
  padding: var(--space-4);
  margin: 0;
  box-shadow: var(--panel-shadow);
  transition: border-color var(--transition);
}
.fanbotica-hero-project figure.wp-block-image:hover {
  border-color: var(--accent);
}

.fanbotica-hero-project h2 {
  font-size: 3rem;
  font-family: var(--font-mono);
  letter-spacing: 0.02em;
}

.fanbotica-hero-project p {
  color: var(--muted);
  font-size: 1.0625rem;
}

.fanbotica-projects-heading {
  text-align: center;
  margin: 0 0 var(--space-5);
}

/* ==========================================================================
   Portfolio ARCHIVE cards (/portfolio/) — a richer, separate card from the
   homepage's simple image+title grid below, matched to the real
   fanbotica.com's own /portfolio/ layout (checked directly): dashed
   border, landscape thumbnail, title, and a real excerpt + "leggi tutto"
   link, adapted to the HUD palette/type instead of copying the real
   site's own light Divi theme verbatim.
   ========================================================================== */
/* REAL bug: as a CSS Grid, the gap between rows measured ~100px live
   despite `gap: var(--space-5)` (32px) — the auto row-track height was
   computing larger (561px) than even the tallest stretched card actually
   needed (493px), a known Grid+`aspect-ratio` interaction (the
   `.fanbotica-archive-card__media` box below uses `aspect-ratio: 8/5`)
   where the implicit row-sizing pass over-estimates height before column
   widths are finalised. Neither `align-items: start` nor `grid-auto-rows:
   min-content` changed the measured gap at all when tried live — the
   fix that actually worked was leaving Grid behind for Flexbox wrap,
   which doesn't share this specific two-pass sizing quirk for this
   content shape. */
.fanbotica-archive-card-grid {
  display: flex;
  flex-wrap: wrap;
  gap: var(--space-5);
  margin-bottom: var(--space-6);
}
/* REAL bug — this was the actual gap culprit, not a Grid/Flex row-track
   quirk: Storefront's OWN compiled `style.css` has a plain `.hentry {
   margin: 0 0 4.2358em }` (~68px) — every article, including this card,
   carries `hentry` via `post_class()`, so Storefront's own default
   article spacing was adding on top of our `gap`. Confirmed live via the
   same stylesheet-scan technique used throughout this file: `margin-bottom:
   67.77px` traced directly to `style.css?ver=4.6.2` (Storefront's, not
   ours). Same recurring "bare .hentry rule reaches somewhere it
   shouldn't" shape hit repeatedly this session — this time from
   Storefront itself rather than one of our own rules. */
.fanbotica-archive-card {
  flex: 1 1 320px;
  margin-bottom: 0 !important;
}

.fanbotica-archive-card {
  display: flex;
  flex-direction: column;
  background-color: var(--surface);
  /* Dashed border — the real site's own signature card treatment
     ("quell'effetto tratteggiato"), recoloured from its original blue to
     this theme's amber accent. */
  border: 1px dashed color-mix(in srgb, var(--accent) 55%, transparent);
  border-radius: var(--radius);
  box-shadow: var(--panel-shadow);
  padding: var(--space-4);
  transition: border-color var(--transition), transform var(--transition), box-shadow var(--transition);
}
.fanbotica-archive-card:hover {
  border-color: var(--accent);
  transform: translateY(-3px);
}

/* Landscape frame (~8:5, matching the real site's own 400x250 thumbnails)
   instead of the homepage grid's 1:1 square — our renders are isolated
   transparent-background objects, not full-bleed photography, so they
   stay centred/contained in this wider frame rather than cropped with
   object-fit:cover the way real rectangular photos could be.
   `--surface`, not `--background`, on purpose: matches the card's own
   frame colour (`.fanbotica-archive-card` below) exactly, so a transparent
   PNG blends into the card seamlessly instead of showing as a visibly
   darker box floating inside it. */
.fanbotica-archive-card__media {
  display: flex;
  align-items: center;
  justify-content: center;
  aspect-ratio: 8 / 5;
  background-color: var(--surface);
  border-radius: calc(var(--radius) - 4px);
  overflow: hidden;
  margin-bottom: var(--space-3);
}
/* REAL bug: the Rocker Tubie card's image rendered visibly shrunken —
   traced to `wp_get_attachment_image()` falling back to the FULL-size
   file (1120x800) for this one attachment because it's genuinely missing
   a registered 'medium' size in its metadata (checked directly:
   `wp_get_attachment_metadata()` only had woocommerce_thumbnail/
   woocommerce_gallery_thumbnail/woocommerce_single sizes, no 'medium' at
   all) — but WordPress still writes `width="300" height="214"` HTML
   attributes onto the <img> (the 'medium' box it WOULD have been, had it
   existed). Browsers use those attributes to compute the image's
   intrinsic aspect-ratio for layout even once the real 1120x800 file has
   loaded, so the earlier `width:auto;height:auto;max-width:85%` rule was
   capping the render at literally 300px regardless of how much room the
   card actually had. Switched to definite `width/height:85%` +
   `object-fit:contain`, which sizes the box from CSS alone and lets
   `object-fit` scale the REAL decoded image within it — sidesteps the
   attribute-vs-real-pixels mismatch entirely, for any attachment missing
   a size, not just this one. */
/* !important: Smush's own lazyload inline CSS
   (`.lazyload { width: var(--smush-image-width, var(--smush-placeholder-
   width)) !important }`) was still winning even after this rule — the
   placeholder var falls back to whatever (possibly wrong, see above)
   width WordPress declared in the HTML attributes at page-load, and stays
   pinned there `!important` regardless of the real image. */
.fanbotica-archive-card__media img {
  width: 85% !important;
  height: 85% !important;
  object-fit: contain;
}

.fanbotica-archive-card__body {
  display: flex;
  flex-direction: column;
  flex: 1;
}

/* Sized up from the homepage grid's own title ("un po' più grandi") —
   this card format carries more content (excerpt, meta) so a bigger
   nameplate title reads proportionate, not just bigger for its own sake. */
.fanbotica-archive-card__title {
  font-family: var(--font-display);
  font-size: 1.6rem;
  text-transform: uppercase;
  letter-spacing: 0.02em;
  line-height: 1.2;
  margin: 0 0 var(--space-2);
}
.fanbotica-archive-card__title a {
  color: var(--foreground);
}
.fanbotica-archive-card__title a:hover {
  color: var(--accent);
}

.fanbotica-archive-card__excerpt {
  flex: 1;
  color: var(--muted);
  font-size: 0.9rem;
  line-height: 1.65;
  margin: 0 0 var(--space-3);
}

.fanbotica-archive-card__more {
  align-self: flex-start;
  font-family: var(--font-mono);
  font-size: 0.78rem;
  font-weight: 500;
  letter-spacing: 0.05em;
  text-transform: uppercase;
  color: var(--accent);
}
.fanbotica-archive-card__more:hover {
  color: var(--critical);
}

.fanbotica-projects-grid {
  margin-bottom: var(--space-7);
}

/* Gutenberg wraps a group block's own content in an automatic
   .wp-block-group__inner-container (its "layout support" feature) — the
   11 project figures live one level deeper than the .fanbotica-projects-grid
   div itself, so the grid has to target the inner container, not the
   outer block. Same reasoning applies to .fanbotica-hero-project below. */
.fanbotica-projects-grid > .wp-block-group__inner-container {
  display: grid;
  /* Bumped from 180px — was cramming 6 tiny cards per row at 1280px,
     nowhere near the reference site's own card size ("aumenta le
     dimensioni... alle stesse dimensioni del sito fanbotica originale").
     320px settles at 3 per row on this container, 2 on tablet, 1 on phone. */
  grid-template-columns: repeat(auto-fit, minmax(320px, 1fr));
  gap: var(--space-5);
}

.fanbotica-projects-grid figure.wp-block-image {
  background-color: var(--surface);
  /* Dashed, matching .fanbotica-archive-card's signature treatment
     (Portfolio archive) — this grid had its own plain solid border
     instead, an inconsistency across the site's three separate card
     systems (this grid, the hero, WooCommerce products) rather than a
     deliberate difference. */
  border: 1px dashed color-mix(in srgb, var(--accent) 55%, transparent);
  border-radius: var(--radius);
  padding: var(--space-4);
  margin: 0;
  text-align: center;
  box-shadow: var(--panel-shadow);
  transition: border-color var(--transition), transform var(--transition), box-shadow var(--transition);
  display: flex;
  flex-direction: column;
}

.fanbotica-projects-grid figure.wp-block-image:hover {
  border-color: var(--accent);
  transform: translateY(-3px);
}

/* Scoped to `figure > a` specifically — a plain `.fanbotica-projects-grid
   a` (any descendant anchor) also matched the TITLE link inside
   `figcaption`, forcing IT to the same 1:1 square too (figcaption just
   grows to contain its now-huge child), which is exactly what produced
   the "split into two big boxes" look: an image square, then a second
   near-identical empty square with just a title floating in it. Real bug,
   found by walking the actual computed styles on a live card, not a
   guess. */
.fanbotica-projects-grid figure > a {
  display: flex;
  align-items: center;
  justify-content: center;
  aspect-ratio: 1;
  /* Matches the card's own frame colour (--surface), not --background — a
     visibly darker inner square read as a separate, mismatched panel
     rather than part of the same card ("lo sfondo non ha lo stesso colore
     delle cornici"). The source images have real transparency (background
     genuinely removed at the pixel level) — see remove_white_bg.py in the
     migration note — so whichever colour sits here shows through cleanly
     either way; it just needs to be the card's own colour. */
  background-color: var(--surface);
  border-radius: calc(var(--radius) - 4px);
  overflow: hidden;
}

.fanbotica-projects-grid img,
.fanbotica-hero-project img {
  max-height: 85%;
  max-width: 85%;
  width: auto;
  height: auto;
  margin: 0 auto;
  /* Real per-pixel transparency on the source files now (flood_fill_bg.py,
     see the migration note) — the dark card background just shows through
     directly, no CSS trick needed here. */
}

/* Project titles run from a couple of words ("PEDRO") to full sentences
   ("Accessorio per pannello portautensili FIXKIT") — mono at heading
   weight reads fine for a short label but gets ragged/heavy for a long
   one, and cards were growing uneven heights with it. Switched to the
   body sans (readable at sentence length), a small pilot-light dot to
   keep the instrument-panel identity without needing the full mono
   treatment, and a 2-line clamp + reserved min-height so every card in a
   row lines up regardless of title length. */
/* No leading dot here (removed per explicit feedback against the round
   micro-LED style) — a colored-text badge needs real content to show, and
   there's no per-project status data to put in one honestly. The project's
   own category (jetpack-portfolio-type) would be a legitimate candidate
   for a real HaptiStick-style badge here later, but that needs a template
   change (querying the term) on top of a CSS one — not done yet. */
/* Nameplate title style, matching the real site: all-caps, tall/narrow
   lettering ("caratteri stretti e alti") via the Bebas Neue display face
   instead of the previous regular-weight sans — reads as a vehicle-badge
   label, not running prose, which also happens to suit long project names
   better (the caps-only condensed letterforms stay legible narrower than
   a mixed-case sans at the same width). */
.fanbotica-projects-grid figcaption {
  color: var(--foreground);
  font-family: var(--font-display);
  font-weight: 400;
  font-size: 1.3rem;
  letter-spacing: 0.03em;
  line-height: 1.15;
  text-transform: uppercase;
  margin-top: var(--space-3);
  min-height: calc(1.15em * 2);
}

.fanbotica-projects-grid figcaption a {
  color: inherit;
  display: -webkit-box;
  -webkit-line-clamp: 2;
  -webkit-box-orient: vertical;
  overflow: hidden;
  text-overflow: ellipsis;
}

/* ==========================================================================
   Shop page (/negozio/, post 901) — migrated from Divi's own page content
   (a hero banner + 4 category cards + catalog/deals shop shortcodes), a
   completely separate page from the homepage's Projects section — see the
   migration note in fanbotica_local_wordpress.md about why those two were
   wrongly combined on the homepage at first.
   ========================================================================== */
.fanbotica-shop-hero {
  text-align: center;
  padding: var(--space-6) var(--space-4);
  margin: var(--space-3) 0 var(--space-6);
  background-color: var(--surface);
  border: 1px solid var(--border);
  border-radius: var(--radius);
  position: relative;
}

.fanbotica-shop-hero h1 {
  font-family: var(--font-mono);
}

.fanbotica-shop-hero p {
  color: var(--muted);
  max-width: 640px;
  margin: var(--space-2) auto 0;
  font-size: 1.0625rem;
}

.fanbotica-shop-categories > .wp-block-group__inner-container {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(220px, 1fr));
  gap: var(--space-4);
  margin-bottom: var(--space-6);
}

.fanbotica-shop-category-card {
  background-color: var(--surface);
  border: 1px solid var(--border);
  border-radius: var(--radius);
  padding: var(--space-4);
  text-align: center;
  box-shadow: var(--panel-shadow);
  transition: border-color var(--transition), transform var(--transition), box-shadow var(--transition);
}

.fanbotica-shop-category-card:hover {
  transform: translateY(-3px);
}

.fanbotica-shop-category-card figure.wp-block-image {
  aspect-ratio: 4 / 3;
  display: flex;
  align-items: center;
  justify-content: center;
  /* All 4 images here are now real transparent PNGs (see
     remove_white_bg.py in the migration note) — the dark card shows
     through naturally instead of needing a light plate behind them. */
  background-color: var(--background);
  border-radius: calc(var(--radius) - 4px);
  overflow: hidden;
  margin: 0 0 var(--space-3);
}

.fanbotica-shop-category-card img {
  max-height: 80%;
  max-width: 80%;
  width: auto;
  height: auto;
}

/* Category name as a "spia di avviso" plaque — colored text inside a
   rounded-border chip (the HaptiStick app's own status-tag shape), colour
   driven by a single --cat-color custom property per card instead of
   repeating each colour across border/badge/hover rules separately. No
   round dot any more — text-in-rounded-rectangle is the whole badge now,
   per explicit feedback against the micro-LED dot style. */
.fanbotica-shop-category-card h3 {
  display: inline-block;
  font-family: var(--font-mono);
  font-size: 0.8125rem;
  font-weight: 500;
  letter-spacing: 0.08em;
  text-transform: uppercase;
  padding: 0.4rem 0.9rem;
  border-radius: 999px;
  background: color-mix(in srgb, var(--cat-color) 16%, transparent);
  border: 1px solid color-mix(in srgb, var(--cat-color) 45%, transparent);
  margin-bottom: var(--space-2);
}

.fanbotica-shop-category-card h3 a {
  color: var(--foreground);
}

.fanbotica-shop-category-card p {
  color: var(--muted);
  font-size: 0.9rem;
  margin-bottom: 0;
}

/* Same amber/coral/ice/green accent per category as the original gradient
   cards had (blue/red/orange/teal) — kept as a thin top border instead of
   a full background gradient, matching the HUD system's flat-panel look.
   Each rule only sets --cat-color once; the badge above and the hover
   state below both read from it instead of repeating the colour. */
.fanbotica-shop-category-card.cat-robot { --cat-color: var(--accent); border-top: 3px solid var(--cat-color); }
.fanbotica-shop-category-card.cat-elettronica { --cat-color: var(--critical); border-top: 3px solid var(--cat-color); }
.fanbotica-shop-category-card.cat-meccanica { --cat-color: var(--data); border-top: 3px solid var(--cat-color); }
.fanbotica-shop-category-card.cat-utensili { --cat-color: var(--live); border-top: 3px solid var(--cat-color); }
.fanbotica-shop-category-card:hover { border-color: var(--cat-color); border-top-color: var(--cat-color); }

.fanbotica-shop-section-heading {
  margin: var(--space-6) 0 var(--space-3);
  font-family: var(--font-mono);
  font-size: 1.5rem;
}

.fanbotica-deals-heading {
  color: var(--critical);
}

/* ==========================================================================
   Product filter panel (Themify WooCommerce Product Filter, the plugin
   behind the [searchandfilter] shortcode already on the Shop page) — never
   styled before this pass, rendering with the plugin's own default light
   theme (white panel, browser-default checkboxes, a plain jQuery UI grey
   slider) with zero relation to the HUD palette. The form itself already
   had only a category facet configured; a real price-range slider and
   in-stock/on-sale toggles were added via the plugin's own `wpf_template`
   option (not hardcoded here) so this CSS just needs to skin whatever
   fields that config produces — an actual Amazon-style filter panel
   (category + price range + availability), not a decoration on top of an
   empty one.
   ========================================================================== */
/* Rebuilt as a real dashboard grid instead of one column of full-width
   stacked bars — direct feedback: "barre che occupano tutta la larghezza
   per mostrare poi contenuti che invece sono poco estesi, non ha senso".
   Category (the one facet with real width to it — up to ~40 checkboxes)
   gets a tall left widget with its own internal 2-column grid; Price,
   Disponibilità and Offerta each become their own compact boxed widget
   stacked in a narrower right column, instead of three more full-width
   bars. `.wpf_item_wpf_cat`/`.wpf_item_price`/`.wpf_item_instock`/
   `.wpf_item_onsale` are real classes the plugin already emits per facet
   (confirmed via a live DOM read) — no template/JS change needed, this is
   pure CSS Grid placement on markup that was already there. */
.wpf_items_wrapper {
  display: grid;
  grid-template-columns: 1.6fr 1fr;
  grid-template-areas:
    "cat price"
    "cat instock"
    "cat onsale";
  gap: var(--space-4);
  margin-bottom: var(--space-5);
}
@media (max-width: 900px) {
  .wpf_items_wrapper {
    grid-template-columns: 1fr;
    grid-template-areas: "cat" "price" "instock" "onsale";
  }
}

.wpf_item_wpf_cat { grid-area: cat; }
.wpf_item_price { grid-area: price; }
.wpf_item_instock { grid-area: instock; }
.wpf_item_onsale { grid-area: onsale; }

.wpf_item {
  background-color: var(--surface);
  border: 1px solid var(--border);
  border-radius: var(--radius);
  box-shadow: var(--panel-shadow);
  padding: var(--space-4);
}

.wpf_item_name {
  position: relative;
  font-family: var(--font-mono);
  font-size: 0.78rem;
  font-weight: 500;
  letter-spacing: 0.08em;
  text-transform: uppercase;
  color: var(--accent);
  margin-bottom: var(--space-2);
  padding-right: 1.25rem;
  cursor: pointer;
}

/* The collapse indicator ("−"/"+") was rendering as nothing at all — the
   plugin's own `wpf-public.css` has a MORE specific rule than its own
   icon-font one (`.wpf_items_grouped .wpf_grouped_label::after`, one
   extra ancestor class) that blanks `content` to `""`, apparently meant
   for a different layout variant of the plugin than the one actually in
   use here. Rather than reverse-engineer that variant system, replaced
   the icon outright with a plain text +/− in this theme's own type and
   colour — simpler and guaranteed to render regardless of whether the
   plugin's own icon-font/sprite loads correctly. State (open vs closed)
   is read off the same `.wpf_grouped_close` class the plugin already
   toggles — kept in sync with the real visual state by the script below
   whenever it force-opens a section. */
.wpf_items_grouped .wpf_grouped_label::after {
  content: "\2212" !important; /* − */
  font-family: var(--font-mono) !important;
  color: var(--accent) !important;
  font-size: 1rem !important;
  font-weight: 600 !important;
  position: absolute;
  right: 0;
  top: 0;
}
.wpf_items_grouped .wpf_grouped_label.wpf_grouped_close::after {
  content: "+" !important;
}

/* This is a real 2-level category tree (5 top-level terms, one of them —
   "Elettronica" — with 21 nested children), confirmed live via the DOM,
   not a flat list. Grid-ing the OUTER list directly would put that one
   huge nested cell next to 4 much shorter top-level siblings in the same
   row, an even more lopsided layout than the single column it replaced.
   The multi-column ask ("non si possono organizzare su più colonne i
   check-box?") is answered instead where it actually matters: each
   NESTED `ul.wpf_submenu` (the run of many same-level siblings under one
   parent) becomes its own 2-column grid, indented under that parent —
   real CSS Grid, not the `columns:` shorthand, since multi-col's overflow
   model (spill into MORE columns once content exceeds the cross-size) is
   fundamentally at odds with a fixed max-height + vertical scroll; Grid
   keeps exactly 2 columns and just scrolls past max-height instead. */
.wpf_hierachy {
  list-style: none;
  margin: 0;
  padding: 0 0.5rem 0 0;
  max-height: 340px;
  overflow-y: auto;
  /* Custom scrollbar — the plain light native one ("questa... non è
     elegante") read as a foreign strip stuck onto a dark panel. Firefox
     via scrollbar-color, Chromium/WebKit via the pseudo-elements below. */
  scrollbar-width: thin;
  scrollbar-color: var(--border) transparent;
}
.wpf_hierachy::-webkit-scrollbar {
  width: 7px;
}
.wpf_hierachy::-webkit-scrollbar-track {
  background: transparent;
}
.wpf_hierachy::-webkit-scrollbar-thumb {
  background-color: var(--border);
  border-radius: 999px;
}
.wpf_hierachy::-webkit-scrollbar-thumb:hover {
  background-color: var(--accent);
}

.wpf_hierachy > li {
  margin-bottom: 0.3rem;
}
/* REAL bug: the plugin's own wpf-public.css has a higher-specificity rule
   (`.wpf_layout_vertical .wpf_item .wpf_hierachy li{display:block}`, three
   classes vs our two) that was winning over the flex row below regardless
   of load order — confirmed live via getComputedStyle (`display: block`
   despite this rule being present). With `li` back to block, the checkbox/
   label/count-badge are three separate inline-level siblings (NOT wrapped
   by <label> in this plugin's markup) crammed into the ~117px-wide
   2-column submenu cells — too narrow to fit all three, so the count badge
   line-wrapped onto its own row below the checkbox, reading as "floating"
   detached from its own item ("le voci... sembrano galleggiare alla
   rinfusa"). Switched to CSS Grid with fixed columns instead of flex so
   the three pieces always occupy exactly one row each and stay vertically
   centred on it; `!important` to beat the tied/higher-specificity plugin
   rule for good. */
.wpf_hierachy li {
  display: grid !important;
  grid-template-columns: 18px 1fr auto;
  align-items: center;
  column-gap: 0.5rem;
  row-gap: 0.3rem;
  min-width: 0;
}
.wpf_hierachy li > ul.wpf_submenu {
  grid-column: 1 / -1;
}
.wpf_hierachy label {
  display: flex;
  align-items: center;
  gap: 0.5rem;
  min-width: 0;
  color: var(--foreground);
  font-size: 0.9rem;
  cursor: pointer;
}
/* Top-level term name reads slightly heavier than its own children, so
   the tree's structure is visible at a glance, not just via indentation. */
.wpf_hierachy > li > label {
  font-weight: 600;
}
.wpf_hierachy label span {
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;
}

/* Product-count badge — never themed, was falling back to the plugin's
   own light-grey default (`wpf-public.css`, same tied-specificity/
   later-load-order fight as the checkboxes above — !important again). */
.wpf_item_count {
  font-family: var(--font-mono) !important;
  font-size: 0.68rem !important;
  color: var(--muted) !important;
  background: var(--surface-raised) !important;
  border: 1px solid var(--border) !important;
  border-radius: 999px !important;
  padding: 0.05rem 0.45rem !important;
  flex-shrink: 0;
}

ul.wpf_submenu {
  list-style: none;
  display: grid;
  grid-template-columns: repeat(2, 1fr);
  column-gap: 1rem;
  row-gap: 0.35rem;
  margin: 0.45rem 0 0.7rem 1.7rem;
  padding: 0;
  width: 100%;
}
.wpf_hierachy ul.wpf_submenu label {
  font-size: 0.84rem;
  color: var(--muted);
}
@media (max-width: 480px) {
  ul.wpf_submenu {
    grid-template-columns: 1fr;
  }
}

/* Custom checkbox, replacing the browser's own native circle/square
   ("questi pallini bianchi non sono il massimo come selettori") — a small
   square toggle in the site's own surface/border tones at rest, filling
   amber with a check-mark when selected. Shared across the category list
   and the instock/onsale toggles so every checkbox in this panel reads as
   one consistent control, not three different native widgets.
   `!important` throughout: the plugin's OWN `wpf-public.css`
   (`.wpf_item input[type="checkbox"]`) is tied specificity with ours and
   loads AFTER our stylesheet in the page — same "later stylesheet wins a
   tied-specificity fight regardless of our own load order" pattern
   documented repeatedly elsewhere in this file, just from a plugin this
   time instead of Storefront/core — confirmed live before adding this:
   the plugin's own white 20px/8px-radius circle was winning outright. */
.wpf_hierachy input[type="checkbox"],
.wpf_instock_wrapp input[type="checkbox"],
.wpf_onsale_wrapp input[type="checkbox"] {
  appearance: none !important;
  -webkit-appearance: none !important;
  flex-shrink: 0;
  width: 18px !important;
  height: 18px !important;
  margin: 0 !important;
  background-color: var(--surface-raised) !important;
  border: 1.5px solid var(--border) !important;
  border-radius: 4px !important;
  cursor: pointer;
  position: relative;
  transition: background-color var(--transition), border-color var(--transition);
}
.wpf_hierachy input[type="checkbox"]:hover,
.wpf_instock_wrapp input[type="checkbox"]:hover,
.wpf_onsale_wrapp input[type="checkbox"]:hover {
  border-color: var(--accent) !important;
}
.wpf_hierachy input[type="checkbox"]:checked,
.wpf_instock_wrapp input[type="checkbox"]:checked,
.wpf_onsale_wrapp input[type="checkbox"]:checked {
  background-color: var(--accent) !important;
  border-color: var(--accent) !important;
}
.wpf_hierachy input[type="checkbox"]:checked::after,
.wpf_instock_wrapp input[type="checkbox"]:checked::after,
.wpf_onsale_wrapp input[type="checkbox"]:checked::after {
  content: "";
  position: absolute;
  left: 5px;
  top: 1px;
  width: 5px;
  height: 10px;
  border: solid var(--accent-foreground);
  border-width: 0 2px 2px 0;
  transform: rotate(45deg);
}

/* jQuery UI slider (the plugin enqueues its own jQuery UI theme, all
   light-grey) — recoloured to the same amber "instrument dial" language
   as everything else interactive on the site. */
.wpf_slider.ui-slider {
  background-color: var(--surface-raised) !important;
  border: 1px solid var(--border) !important;
  height: 6px !important;
  border-radius: 999px !important;
  margin: var(--space-3) 0.5rem var(--space-4);
}
.wpf_slider .ui-slider-range {
  background-color: var(--accent) !important;
  border-radius: 999px;
}
.wpf_slider .ui-slider-handle {
  background-color: var(--foreground) !important;
  border: 2px solid var(--accent) !important;
  width: 16px !important;
  height: 16px !important;
  top: -6px !important;
  border-radius: 50% !important;
  outline: none;
  box-shadow: 0 0 0 4px color-mix(in srgb, var(--accent) 20%, transparent);
}
.wpf-slider-label {
  font-family: var(--font-mono);
  color: var(--foreground);
  font-size: 0.9rem;
  text-align: center;
}

.wpf_instock_wrapp,
.wpf_onsale_wrapp {
  display: flex;
  align-items: center;
}

/* REAL bug: "Solo disponibili"/"Solo in offerta" read as glued to the top
   of their own filter card instead of centred in it. Root cause: these two
   cards sit in the same CSS Grid column as "Categoria" (which spans all 3
   rows and is much taller), and the grid's own auto row-track sizing
   distributes part of that extra height onto the shorter "instock"/
   "onsale" rows too — confirmed live (`.wpf_item` box measured 81px tall
   while its actual content, the name+checkbox row, is only ~26px). The
   card itself was plain `display:block`, so there was no way to vertically
   centre that short row within the inflated cell. Also reasserts the
   checkbox ahead of the label via `order` — the plugin's own `float:left`
   hack achieved that same "[checkbox] Label" reading order (matching every
   other control in this panel) by accident, and flexbox ignores `float` on
   its children, so it needs restating explicitly here. */
.wpf_item_instock,
.wpf_item_onsale {
  display: flex !important;
  align-items: center;
  justify-content: center;
  gap: 0.5rem;
}

/* Same "inflated grid cell" cause as above, on the Prezzo card: measured
   26px of padding above the title but 56px of dead space below the slider
   — content pinned to the top instead of centred in the cell. Unlike
   instock/onsale this card has a real vertical stack (title above
   slider+label), so it needs `flex-direction:column`, not a row, to centre
   the whole stack as a block without disturbing that internal order. */
.wpf_item_price {
  display: flex !important;
  flex-direction: column;
  justify-content: center;
}
.wpf_item_instock .wpf_items_group,
.wpf_item_onsale .wpf_items_group {
  order: 1;
}
.wpf_item_instock .wpf_item_name,
.wpf_item_onsale .wpf_item_name {
  order: 2;
  margin: 0;
}

.wpf_reset_btn input[type="reset"] {
  background-color: var(--surface-raised) !important;
  color: var(--muted) !important;
  border: 1px solid var(--border) !important;
  border-radius: 6px !important;
  padding: 0.5em 1em !important;
  font-weight: 500 !important;
  font-size: 0.85rem !important;
  cursor: pointer;
}
.wpf_reset_btn input[type="reset"]:hover {
  border-color: var(--critical) !important;
  color: var(--critical) !important;
}

/* ==========================================================================
   Single-article readability (project write-ups, blog posts) — a real
   critique of the first pass: the site-wide `.content-area` is full-width
   (1280px), fine for the homepage's own designed sections, but wrong for a
   wall of running text — lines that long are genuinely hard to track, and
   pure white-on-#0a0b0d is harsh contrast for paragraph after paragraph.
   Scoped to `.single-*` body classes specifically, NOT `.entry-content` on
   its own, which would also catch the Home/Shop pages' custom full-width
   Gutenberg sections and break their layout.
   ========================================================================== */
/* Widened again, 1040px -> 1598px (4th bump this project: 720/860/1040/
   1598, always per explicit request). A fixed-width breakout wasn't used
   here — that would force horizontal scroll on any real screen narrower
   than ~1650px. Instead the SITE'S container is widened, but only on
   these two page types (single project/post), via `.col-full` below, so
   the rest of the site (shop grids, homepage) keeps its own 1280px layout
   untouched, and this column still degrades responsively like any other
   max-width on a real narrow viewport. */
/* REAL correction, previous pass had this backwards: the outer container
   (.col-full) is NOT widened here any more — category/tag/blog pages stay
   at the sitewide 1280px (reverted, they were never supposed to change),
   and single project/post pages share that same standard container too,
   so the two page types read as the same width side by side, as asked.
   The 1598px article-text target from the earlier request is still real
   (see below) but is achieved as a genuine "breakout" on the
   `.entry-content` column itself — wider than its own 1280px parent, via
   negative margins — ONLY once the viewport is comfortably wide enough to
   show it without forcing horizontal scroll (>=1650px, the same safety
   margin flagged and confirmed with the user). Below that, entry-content
   falls back to its earlier 1040px reading column, nested normally inside
   the standard 1280px container — no breakout, no overflow risk. */
.single-jetpack-portfolio .entry-content,
.single-post .entry-content {
  max-width: 1040px;
  margin: 0 auto var(--space-6);
  background-color: var(--content-surface);
  border: 1px solid var(--border);
  border-radius: var(--radius);
  padding: var(--space-6);
  color: var(--content-foreground);
  font-size: 1.0625rem;
  line-height: 1.75;
}
.single-jetpack-portfolio .comments-area,
.single-post .comments-area {
  max-width: 1040px;
  margin: 0 auto;
}

/* REAL bug, phone only, never caught before because all desktop-browser
   testing this project used a wide viewport: `padding: var(--space-6)`
   above (3rem = 48px PER SIDE) was never given a smaller value for narrow
   screens — it's a flat panel-padding value tuned for a comfortable "boxed
   article" look on desktop/tablet. Stacked on top of Storefront's own
   `.col-full` container padding, it left the actual readable text column
   barely more than a third of the screen width on a real phone (measured:
   ~133px of usable text width on a 375px‑wide viewport) — "layout di
   lettura troppo stretto" was a precise, correct description of the bug,
   not just a subjective ask.

   First pass just shrank the padding (48px -> 16px) but left the card
   nested inside Storefront's own `.col-full` (24px padding + its own
   auto-centering margin on top of that) — still lost ~125px of a 375px
   screen to combined container padding, per direct follow-up feedback
   ("ancora troppo stretto"). This second pass breaks the card OUT of
   `.col-full` entirely on phone-only widths — `100vw`-relative margins,
   the standard "full-bleed" technique, so it fills the screen regardless
   of whatever padding/width `.col-full` happens to compute at a given
   phone size, rather than trying to out-guess and cancel that value.
   `quasi tutta la larghezza` (not literally edge-to-edge, a small margin
   is kept) — hence the +8px in the margin calc, not a bare 50vw. Border-
   radius/border stay (a flush-edge but still visibly "carded" panel);
   internal padding is a little tighter than the first pass since the
   card itself is now much wider, so text still gets real breathing room
   without needing as much of it reserved on the outside. */
@media (max-width: 600px) {
  .single-jetpack-portfolio .entry-content,
  .single-post .entry-content,
  .single-jetpack-portfolio .comments-area,
  .single-post .comments-area {
    width: auto;
    max-width: none;
    margin-left: calc(50% - 50vw + 8px);
    margin-right: calc(50% - 50vw + 8px);
  }
  .single-jetpack-portfolio .entry-content,
  .single-post .entry-content {
    padding: var(--space-2);
  }

  /* Bullet/numbered list indent (1.5em, fine on desktop) eats real
     percentage of the line on a phone-width card — reduced, not removed:
     the marker is real structure (screen readers announce "list, N
     items", Google can and does pull list content into rich snippets),
     dropping to plain paragraphs would be a genuine SEO/accessibility
     downgrade dressed up as a mobile-readability fix. Narrower indent
     only, same real <ul>/<ol> markup. */
  .single-jetpack-portfolio .entry-content ul,
  .single-jetpack-portfolio .entry-content ol,
  .single-post .entry-content ul,
  .single-post .entry-content ol {
    padding-left: 1.1em;
  }
}
/* Breakout DISABLED on request (2026-08-22): the goal shifted to a
   homogeneous/identical body width across every page type on the site,
   which this 1598px widening on large screens directly worked against —
   Portfolio archive stays at the sitewide 1280px always, so single
   project/post pages now match it exactly instead of flaring wider above
   1650px. Explicitly a trial ("proviamo solo se è possibile tornare
   indietro") — kept commented out, not deleted, so re-enabling the
   1598px breakout is a one-line uncomment if it's not liked this way.
@media (min-width: 1650px) {
  .single-jetpack-portfolio .entry-content,
  .single-post .entry-content,
  .single-jetpack-portfolio .comments-area,
  .single-post .comments-area {
    max-width: 1598px;
    margin-left: calc(50% - 799px);
    margin-right: calc(50% - 799px);
  }
}
*/

.single-jetpack-portfolio .entry-content p,
.single-post .entry-content p {
  color: var(--content-foreground);
  margin-bottom: var(--space-4);
}

/* Two-tier heading accent, same idea as the real site's own blue/orange
   heading system (its reference screenshots) reworked in our own palette —
   amber for primary section headings, ice-blue for secondary ones, so a
   long guide stays scannable instead of an unbroken wall of same-colored
   text. Letter-spacing relaxed vs. the sitewide h1/h2 (tuned for a big
   hero headline, too tight/harsh for inline article prose). */
.single-jetpack-portfolio .entry-content h1,
.single-jetpack-portfolio .entry-content h2,
.single-post .entry-content h1,
.single-post .entry-content h2 {
  color: var(--accent) !important;
  letter-spacing: normal;
  font-size: 1.625rem;
  margin-top: var(--space-5);
}

.single-jetpack-portfolio .entry-content h3,
.single-jetpack-portfolio .entry-content h4,
.single-post .entry-content h3,
.single-post .entry-content h4 {
  color: var(--data) !important;
  font-size: 1.25rem;
  margin-top: var(--space-4);
}

.single-jetpack-portfolio .entry-content strong,
.single-post .entry-content strong {
  color: var(--foreground);
  font-weight: 600;
}

.single-jetpack-portfolio .entry-content ul,
.single-jetpack-portfolio .entry-content ol,
.single-post .entry-content ul,
.single-post .entry-content ol {
  margin-bottom: var(--space-4);
  padding-left: 1.5em;
}
.single-jetpack-portfolio .entry-content li,
.single-post .entry-content li {
  margin-bottom: var(--space-2);
}

/* Images inside the article read the same way as everywhere else — a dark
   inset frame the (now genuinely transparent) renders sit inside. */
.single-jetpack-portfolio .entry-content img,
.single-post .entry-content img {
  max-width: 100%;
  height: auto;
  border-radius: 6px;
}

/* ==========================================================================
   Single project (jetpack-portfolio) pages — CTA blocks and step-by-step
   accordions generated by fanbotica_hud_strip_divi_shortcodes() out of the
   original Divi markup (see functions.php).
   ========================================================================== */
.fanbotica-project-cta {
  background-color: var(--surface);
  border: 1px solid var(--border);
  border-left: 3px solid var(--accent);
  border-radius: var(--radius);
  padding: var(--space-4);
  margin: var(--space-4) 0;
}

.fanbotica-project-cta h3 {
  margin-bottom: var(--space-2);
}

.fanbotica-project-step {
  background-color: var(--surface);
  border: 1px solid var(--border);
  border-radius: 6px;
  padding: var(--space-3) var(--space-4);
  margin-bottom: var(--space-2);
}

.fanbotica-project-step summary {
  cursor: pointer;
  font-weight: 600;
  color: var(--foreground);
}

.fanbotica-project-step summary:hover {
  color: var(--accent);
}

.fanbotica-project-step[open] summary {
  color: var(--accent);
  margin-bottom: var(--space-2);
}

/* "Riquadri di enfasi" — text blocks that open with a heading (see
   fanbotica_hud_strip_divi_shortcodes(), the "SCOPO DELLA GUIDA"/"LIVELLO
   DI DIFFICOLTÀ" pattern from the real site) get the same instrument-
   placard identity as the eyebrow tags elsewhere on the site: a small
   amber monospace uppercase label instead of a plain large heading,
   panel depth to match every other surface. Deliberately restrained (a
   left accent border + panel, not a heavy fill) so it still reads fine
   if applied to a longer section, not just a short 2-line callout. */
.fanbotica-emphasis-box {
  background-color: var(--surface);
  border: 1px solid var(--border);
  border-left: 3px solid var(--accent);
  border-radius: var(--radius);
  padding: var(--space-4);
  margin: var(--space-5) 0;
  box-shadow: var(--panel-shadow);
}
.fanbotica-emphasis-box > h1,
.fanbotica-emphasis-box > h2,
.fanbotica-emphasis-box > h3,
.fanbotica-emphasis-box > h4,
.fanbotica-emphasis-box > h5,
.fanbotica-emphasis-box > h6 {
  color: var(--accent);
  font-family: var(--font-mono);
  font-size: 0.9375rem;
  letter-spacing: 0.04em;
  text-transform: uppercase;
  margin-bottom: var(--space-3);
}
.fanbotica-emphasis-box ul,
.fanbotica-emphasis-box ol {
  margin-bottom: 0;
}
.fanbotica-emphasis-box strong {
  color: var(--accent);
}

/* Tables embedded directly in article content ("rifai da zero le tabelle
   con sfondo bianco") — plain browser-default white `<table>` HTML the
   original guides use for parts lists / wiring references, with inline
   `style="width:..."` attributes needing `!important` to override (an
   inline style beats a plain external rule, but not an `!important` one).
   Wrapped in a horizontally-scrollable block so a wide table can't blow
   out the article column on narrow viewports. */
.entry-content table {
  width: 100% !important;
  height: auto !important;
  display: block;
  overflow-x: auto;
  border-collapse: collapse;
  background-color: var(--surface);
  border: 1px solid var(--border);
  border-radius: var(--radius);
  margin: var(--space-5) 0;
  color: var(--foreground);
}
.entry-content table tbody,
.entry-content table thead {
  display: table;
  width: 100%;
}
.entry-content table td,
.entry-content table th {
  border: 1px solid var(--border) !important;
  padding: var(--space-2) var(--space-3);
  background-color: transparent !important;
  color: var(--foreground) !important;
  text-align: left;
}
.entry-content table tr:nth-child(even) td {
  background-color: color-mix(in srgb, var(--surface-raised) 60%, transparent) !important;
}
.entry-content table th,
.entry-content table tr:first-child td {
  background-color: var(--surface-raised) !important;
  color: var(--accent) !important;
  font-weight: 600;
}

/* ==========================================================================
   Blog archive / category listing — was the plain default WordPress loop
   (title, meta, full-width image, content running edge-to-edge, nothing
   visually separating one post from the next) — "categorie del blog...
   abbastanza anonime". Each post becomes a real card matching the rest of
   the site's panel language, not a bespoke one-off treatment.
   ========================================================================== */
.blog .page-header,
.archive .page-header,
.category .page-header,
.tag .page-header {
  text-align: center;
  padding: var(--space-6) var(--space-4);
  margin: var(--space-3) 0 var(--space-6);
  background-color: var(--surface);
  border: 1px solid var(--border);
  border-radius: var(--radius);
  box-shadow: var(--panel-shadow);
}
.page-header .page-title,
.woocommerce-products-header__title.page-title {
  font-family: var(--font-mono);
  text-transform: uppercase;
  letter-spacing: 0.02em;
}
.page-header .taxonomy-description {
  color: var(--muted);
  max-width: 640px;
  margin: var(--space-2) auto 0;
}

/* The blog/category/tag archive-CARD styling that used to live here
   (background/border/padding on `article.hentry`, the H1-vs-H2 size fix,
   the embedded-heading demotion fix) is retired — those rules targeted
   Storefront's own default loop markup (`.entry-title`, a raw
   `.entry-content` teaser), which this theme's own `content.php` +
   `archive.php`/`index.php` overrides replaced with the shared
   `.fanbotica-archive-card` structure below (the SAME card as the
   Portfolio archive, per direct request: "adotta la stessa soluzione
   grafica per gli articoli contenuti nelle categorie"). The underlying
   bugs those old rules fixed (H1 smaller than its own H2, a leaked
   heading outsizing the card title) can't recur on this new markup at
   all — the card's own title/excerpt use dedicated
   `__title`/`__excerpt` classes, never `.entry-title`/`.entry-content`,
   so there's nothing left for those old selectors to match against.
   `.posted-on`/`.byline`/`.cat-links`/etc. below stay — Storefront's own
   `content-single.php` (the single-POST reading view, a different file
   from this archive loop) still uses them. */
article.hentry .posted-on,
article.hentry .byline,
article.hentry .post-comments {
  color: var(--muted);
  font-size: 0.875rem;
  font-family: var(--font-mono);
}
article.hentry .posted-on a,
article.hentry .byline a,
article.hentry .post-comments a {
  color: var(--muted);
}
article.hentry .posted-on a:hover,
article.hentry .byline a:hover {
  color: var(--accent);
}

article.hentry .post-thumbnail img {
  border-radius: 6px;
  border: 1px solid var(--border);
  margin: var(--space-4) 0;
}

article.hentry .entry-summary,
article.hentry .entry-content {
  color: var(--foreground);
}

article.hentry .entry-footer,
.cat-links,
.tags-links {
  color: var(--muted);
  font-size: 0.875rem;
  margin-top: var(--space-3);
}
.cat-links a,
.tags-links a {
  color: var(--accent);
}
.cat-links a:hover,
.tags-links a:hover {
  color: var(--critical);
}

/* ==========================================================================
   HUD chrome utilities — same restrained usage rule as the minisite: only on
   instrument/system chrome (header, eyebrow tags), never on content cards or
   buttons.
   ========================================================================== */
.hud-chamfer {
  clip-path: polygon(10px 0, 100% 0, 100% calc(100% - 10px), calc(100% - 10px) 100%, 0 100%, 0 10px);
}

.hud-scanlines {
  background-image: repeating-linear-gradient(
    to bottom,
    rgba(231, 233, 236, 0.05) 0px,
    rgba(231, 233, 236, 0.05) 1px,
    transparent 1px,
    transparent 3px
  );
}

/* ==========================================================================
   Footer
   ========================================================================== */
/* Storefront's inline Customizer CSS targets .site-footer / footer links /
   footer headings with the exact same or higher-specificity selectors
   (`.site-footer a:not(.button):not(.components-button)`,
   `.site-footer h1..h6, .site-footer .widget .widget-title`) and was
   winning — a light-grey #f0f0f0 footer with #333333 near-black text,
   nearly invisible against this theme's dark palette (the "footer
   illeggibile" report). Matched selector shapes + `!important` throughout,
   same standing policy as the header/nav section above. */
.site-footer {
  background-color: var(--surface) !important;
  border-top: 1px solid var(--border);
  color: var(--muted) !important;
  box-shadow: inset 0 1px 0 rgba(255, 255, 255, 0.06);
  position: relative;
  z-index: 2;
}

.site-footer .widget-title,
.site-footer h1,
.site-footer h2,
.site-footer h3,
.site-footer h4,
.site-footer h5,
.site-footer h6,
.site-footer .widget .widget-title,
.site-footer .widget .widgettitle {
  color: var(--foreground) !important;
}

.site-footer a,
.site-footer a:not(.button):not(.components-button) {
  color: var(--muted) !important;
  transition: color var(--transition), transform var(--transition);
}
.site-footer a:hover {
  color: var(--accent) !important;
}
.site-footer a:active {
  color: var(--critical) !important;
  transform: scale(0.97);
}

/* The "riquadro interno totalmente nero" report: .site-info was painted
   var(--background) (near-black), a full shade darker than the .site-footer
   it sits inside (var(--surface)) — the mismatch alone reads as a stray
   boxed-off rectangle. Same tone as the footer around it, plus a subtle
   divider line instead of a color seam. */
.site-info {
  color: var(--muted) !important;
  background-color: transparent;
  border-top: 1px solid var(--border);
  padding: var(--space-4) 0;
  margin-top: var(--space-4);
}
.site-info::after {
  content: "";
  display: table;
  clear: both;
}

/* ==========================================================================
   Footer widget columns — Informazioni / Links / Seguici / Metodi di
   pagamento, matching the real fanbotica.com footer's 4-column structure
   (Storefront detects the column count itself from how many of our 4
   registered footer-N sidebars have a widget in them, `.footer-widgets.col-4`).
   ========================================================================== */
.footer-widgets {
  padding: var(--space-6) 0 var(--space-3);
}

/* Instrument-cluster divider between the 4 modules — a thin line centered
   in Storefront's own float-grid gutter (an absolutely-positioned pseudo
   rather than a border/padding change, so it doesn't fight the existing
   float+margin math) instead of the columns just floating as 4 unrelated
   blocks. This is the concrete "pannello di controllo di un mezzo" read:
   adjoining instrument modules, not a plain multi-column list. */
.footer-widgets.col-4 > .block {
  position: relative;
}
.footer-widgets.col-4 > .block.footer-widget-1::after,
.footer-widgets.col-4 > .block.footer-widget-2::after,
.footer-widgets.col-4 > .block.footer-widget-3::after {
  content: "";
  position: absolute;
  top: 0.2rem;
  bottom: 0.2rem;
  right: -1.65rem;
  width: 1px;
  background: var(--border);
}
/* Storefront stacks these columns to one-per-row under its own mobile
   breakpoint — a stray vertical line down the middle of a stacked column
   would look like a bug there, so it only appears once there's an actual
   side-by-side gutter to sit in. */
@media (max-width: 768px) {
  .footer-widgets.col-4 > .block::after {
    display: none;
  }
}

/* Column headers as instrument placards — the same eyebrow-tag component
   used above every hero/section heading sitewide, not a plain heading +
   underline (that read as generic; this reads as the same labeling system
   the rest of the site already uses for panel titles). */
.footer-widgets .widget .widget-title {
  display: inline-block;
  font-family: var(--font-mono);
  font-size: 0.72rem;
  font-weight: 500;
  letter-spacing: 0.13em;
  text-transform: uppercase;
  /* !important AND the 3-class `.widget .widget-title` shape (not just
     `.footer-widgets .widget-title`, 2 classes): `.site-footer .widget
     .widget-title` earlier in this file is a 3-class selector too and
     already forces `color: var(--foreground) !important` — a 2-class
     selector here loses on SPECIFICITY (not just cascade order) even
     with matching !important, confirmed live via getComputedStyle before
     this fix (foreground kept winning despite this rule loading later
     and despite its own !important). */
  color: var(--accent) !important;
  background: color-mix(in srgb, var(--accent) 10%, transparent);
  border: 1px solid color-mix(in srgb, var(--accent) 30%, transparent);
  padding: 0.35rem 0.75rem;
  border-radius: 4px;
  margin-bottom: var(--space-4);
}

.footer-widgets .widget {
  margin-bottom: var(--space-4);
}

.footer-widgets .widget ul {
  list-style: none;
  margin: 0;
  padding: 0;
}
.footer-widgets .widget ul li {
  margin-bottom: var(--space-2);
}

/* Real icons on the Links / Seguici list items, redrawn as small dashboard
   "buttons" — a backlit square housing each icon, the actual physical
   vocabulary a control-panel calls for (per direct feedback: "il sito va
   immaginato come se fosse un pannello di controllo di un mezzo... basta
   rifarsi a come funziona l'app HaptiStick"). Recolored to ONE consistent
   amber (`--accent`, the site's single "interactive element" role) instead
   of the earlier two-tone ice/green split — these are navigation, not a
   status readout, so they belong in the same colour as every other link
   and button on the site, not a semantic status colour borrowed for
   decoration ("colore verde non in linea col sito" — the fix is the role,
   not just a different hex). Icon shape now painted directly into the SVG
   (`background-image`, amber fill baked in) instead of the mask+
   background-color trick, since the chip itself needs its own background
   — one pseudo-element can't be both the chip surface and a recolorable
   mask at once. #nav_menu-2 = Links (footer-2), #nav_menu-5 = Seguici
   (footer-3), confirmed via the `widget_nav_menu` option, not guessed. */
/* REAL bug, confirmed live via document.styleSheets enumeration (the same
   technique that solved the nav-hover mystery earlier in this file): the
   "doppia icona" the user kept seeing in TWO different browsers was never
   a browser extension (wrongly suspected in the previous pass) — it's
   Storefront's OWN `assets/css/base/icons.css`, which gives every
   `.widget_nav_menu ul li` a dimmed (`opacity:.35`) Font Awesome glyph via
   `::before` PLUS a reserved `padding-left: 1.618em` gutter for it to sit
   in. That's a real, SEPARATE element from the `<a>` this theme's own
   icon-chip `::before` lives on — one element can only ever have one
   `::before`, which is why that reasoning felt sound at the time, but the
   `<li>` and its child `<a>` are two different elements, each free to
   carry its own pseudo-element. Storefront's own icon was never
   neutralized, so both rendered side by side. Killed here with an ID
   selector (`#nav_menu-2`/`#nav_menu-5`, unbeatable specificity) plus
   `!important`, and the now-unneeded reserved gutter zeroed out — this
   theme's own icon-chip supplies its own spacing via flex `gap` instead. */
#nav_menu-2.widget_nav_menu ul li::before,
#nav_menu-5.widget_nav_menu ul li::before {
  content: none !important;
}
#nav_menu-2.widget_nav_menu ul li,
#nav_menu-5.widget_nav_menu ul li {
  padding-left: 0 !important;
}

#nav_menu-2.widget_nav_menu ul li a,
#nav_menu-5.widget_nav_menu ul li a {
  display: flex;
  align-items: center;
  gap: 0.7rem;
}
#nav_menu-2.widget_nav_menu ul li a::before,
#nav_menu-5.widget_nav_menu ul li a::before {
  content: "";
  width: 28px;
  height: 28px;
  flex-shrink: 0;
  border-radius: 7px;
  background-color: var(--surface-raised);
  background-repeat: no-repeat;
  background-position: center;
  background-size: 14px 14px;
  border: 1px solid var(--border);
  box-shadow: var(--panel-shadow);
  transition: border-color var(--transition), transform var(--transition);
}
#nav_menu-2.widget_nav_menu ul li a:hover::before,
#nav_menu-5.widget_nav_menu ul li a:hover::before {
  border-color: var(--accent);
  transform: translateY(-1px);
}

/* Links column. Default: account/person (Dettagli account, Preordini,
   Ordini, Password dimenticata all land here), overridden for the 3 links
   that are genuinely a different kind of action. */
#nav_menu-2.widget_nav_menu ul li a::before {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'%3E%3Ccircle cx='8' cy='5' r='2.6' fill='%23ffb32c'/%3E%3Cpath d='M2.5 14c0-3.2 2.6-5.2 5.5-5.2s5.5 2 5.5 5.2z' fill='%23ffb32c'/%3E%3C/svg%3E");
}
#nav_menu-2.widget_nav_menu ul li a[href*="/downloads/"]::before {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'%3E%3Cpath d='M8 1.5v7.3M5 6.3 8 9.3 11 6.3' fill='none' stroke='%23ffb32c' stroke-width='1.5' stroke-linecap='round' stroke-linejoin='round'/%3E%3Crect x='2.5' y='11.5' width='11' height='2' rx='0.5' fill='%23ffb32c'/%3E%3C/svg%3E");
}
#nav_menu-2.widget_nav_menu ul li a[href*="richiesta-accesso-ai-dati"]::before {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'%3E%3Cpath d='M8 1.3 13 3.3v4c0 4-2.3 6.5-5 7.4-2.7-.9-5-3.4-5-7.4v-4z' fill='%23ffb32c'/%3E%3C/svg%3E");
}
#nav_menu-2.widget_nav_menu ul li a[href^="http"]:not([href*="fanbotica-redesign.local"])::before {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'%3E%3Cpath d='M6.2 3H3v10h10V9.8' fill='none' stroke='%23ffb32c' stroke-width='1.5' stroke-linecap='round' stroke-linejoin='round'/%3E%3Cpath d='M9 2h5v5M14 2 7.3 8.7' fill='none' stroke='%23ffb32c' stroke-width='1.5' stroke-linecap='round' stroke-linejoin='round'/%3E%3C/svg%3E");
}

/* Seguici column — one real per-platform glyph each, matched off the
   actual social URL (twitter.com, facebook.com, instagram.com, mailto:). */
#nav_menu-5.widget_nav_menu ul li a[href*="twitter.com"]::before {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'%3E%3Cpath d='M2.5 2.5l11 11M13.5 2.5l-11 11' stroke='%23ffb32c' stroke-width='1.8' stroke-linecap='round'/%3E%3C/svg%3E");
}
#nav_menu-5.widget_nav_menu ul li a[href*="facebook.com"]::before {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'%3E%3Cpath d='M10 2H8.2C6.7 2 6 2.9 6 4.3V6.5H4.3V9H6v6h2.6V9h2l.4-2.5H8.6V4.6c0-.6.3-.9.9-.9H10z' fill='%23ffb32c'/%3E%3C/svg%3E");
}
#nav_menu-5.widget_nav_menu ul li a[href*="instagram.com"]::before {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'%3E%3Crect x='1.5' y='4' width='13' height='10' rx='2.5' fill='none' stroke='%23ffb32c' stroke-width='1.4'/%3E%3Ccircle cx='8' cy='9' r='2.6' fill='none' stroke='%23ffb32c' stroke-width='1.4'/%3E%3Ccircle cx='11.7' cy='6.3' r='0.7' fill='%23ffb32c'/%3E%3C/svg%3E");
}
#nav_menu-5.widget_nav_menu ul li a[href^="mailto:"]::before {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'%3E%3Crect x='1.5' y='3.5' width='13' height='9' rx='1.5' fill='none' stroke='%23ffb32c' stroke-width='1.4'/%3E%3Cpath d='M2 4.5l6 5 6-5' fill='none' stroke='%23ffb32c' stroke-width='1.4' stroke-linecap='round' stroke-linejoin='round'/%3E%3C/svg%3E");
}

/* Informazioni column — logo + address, from the custom_html widget.
   The widget's own image was swapped (see the site content, not CSS) from
   `fanbotica_logo_scuro_trasp_01.fw_.png` — a genuinely DARK-on-transparent
   variant meant for a light background, nearly invisible against this
   footer — to the same light-friendly mark already used in the header
   (`fanbotica_logo_04.fw_.png`). A soft glow on top of the correct asset
   reads as a lit instrument badge instead of a flat sticker. */
.footer-widgets .widget_custom_html img {
  max-width: 140px;
  height: auto;
  margin-bottom: var(--space-3);
  filter: brightness(1.08) drop-shadow(0 0 6px rgba(255, 179, 44, 0.25));
}
.footer-widgets .widget_custom_html p {
  color: var(--muted);
  font-size: 0.875rem;
  line-height: 1.7;
}

/* Social icons — real fanbotica.com's own two icon sets (checked live on
   the real site): the "Seguici" footer column (11 platforms, Jetpack's
   Social Icons widget) and a smaller 4-icon set next to the bottom credit
   line. Both replace what used to be plain text links
   ("Fanbotica su Twitter" etc.) with round instrument-style badges,
   consistent with the payment-method icons above and the back-to-top
   button — surface-raised circle at rest, amber on hover. */
.fanbotica-social-icons {
  display: flex;
  flex-wrap: wrap;
  gap: var(--space-2);
  list-style: none;
  margin: 0;
  padding: 0;
}
.fanbotica-social-icons a {
  display: flex;
  align-items: center;
  justify-content: center;
  width: 38px;
  height: 38px;
  background-color: var(--surface-raised);
  border: 1px solid var(--border);
  border-radius: 50%;
  color: var(--muted);
  transition: border-color var(--transition), color var(--transition), transform var(--transition);
}
.fanbotica-social-icons a:hover {
  border-color: var(--accent);
  color: var(--accent);
  transform: translateY(-2px);
}
.fanbotica-social-icons svg {
  width: 18px;
  height: 18px;
  fill: currentColor;
}
.fanbotica-social-icons--compact {
  float: right;
  margin: 0 0 0 var(--space-3);
}
.fanbotica-social-icons--compact a {
  width: 30px;
  height: 30px;
}
.fanbotica-social-icons--compact svg {
  width: 15px;
  height: 15px;
}

/* Payment icons — Font Awesome-style glyphs from the payment-methods
   plugin, sized to actually read at this scale instead of the tiny default. */
.footer-widgets .payment-methods {
  display: flex;
  flex-wrap: wrap;
  gap: var(--space-2);
  list-style: none;
  margin: 0;
  padding: 0;
}
.footer-widgets .payment-methods li {
  background-color: var(--surface-raised);
  /* Dashed, matching the same accent treatment as the archive cards
     ("i contorni... possiamo provarli tratteggiati"). */
  border: 1px dashed var(--border);
  border-radius: 7px;
  box-shadow: var(--panel-shadow);
  padding: 0.4rem 0.6rem;
  font-size: 1.5rem;
  color: var(--muted);
  display: flex;
  align-items: center;
  transition: border-color var(--transition), transform var(--transition);
}
.footer-widgets .payment-methods li:hover {
  border-color: var(--accent);
  transform: translateY(-1px);
}

/* Storefront's mobile-only bottom action bar (account/search/cart) — same
   #ffffff/#404040 light styling from the inline CSS, only ever visible
   under 768px, but still part of "the footer" the user is judging. */
.storefront-handheld-footer-bar,
.storefront-handheld-footer-bar ul li > a,
.storefront-handheld-footer-bar ul li.search .site-search {
  background-color: var(--surface) !important;
  color: var(--foreground) !important;
  border-top: 1px solid var(--border);
}
.site-footer .storefront-handheld-footer-bar a:not(.button):not(.components-button) {
  color: var(--foreground) !important;
}

/* ==========================================================================
   "Torna in cima" button — the real site's Divi "Back to Top" equivalent,
   missing here until now. Same instrument-button language as the footer
   icon chips (surface-raised, border, panel-shadow, amber on hover).
   ========================================================================== */
/* REAL bug: this is a real <button>, so the SITEWIDE generic button rule
   (`.button, button, ... { background-color: var(--accent) !important;
   padding: 0.7em 1.4em !important; border-radius: 6px !important; ... }`)
   was hijacking it — screenshot showed a solid amber ROUNDED-RECT with no
   visible icon, matching that rule exactly instead of this one's own
   surface-raised/circular design. Worse: the forced `padding: 0.7em 1.4em`
   (22.4px each side) on a fixed 44px-wide button left ~0 content width,
   and the flex-child SVG (default `flex-shrink:1`) collapsed to
   `width:0` to fit — the actual reason the icon was invisible, not just
   wrong colours. `!important` on every property the sitewide rule also
   sets, same standing policy used for that rule itself. */
#fanbotica-back-to-top {
  position: fixed;
  right: var(--space-4);
  bottom: var(--space-4);
  z-index: 999;
  width: 44px;
  height: 44px;
  padding: 0 !important;
  display: flex;
  align-items: center;
  justify-content: center;
  background-color: var(--surface-raised) !important;
  color: var(--accent) !important;
  border: 1px solid var(--border) !important;
  border-radius: 50% !important;
  font-weight: normal !important;
  box-shadow: var(--panel-shadow), 0 8px 20px rgba(0, 0, 0, 0.35);
  cursor: pointer;
  opacity: 0;
  visibility: hidden;
  transform: translateY(8px);
  transition: opacity var(--transition), transform var(--transition), border-color var(--transition), visibility var(--transition);
}
#fanbotica-back-to-top svg {
  flex-shrink: 0;
  width: 18px;
  height: 18px;
}
#fanbotica-back-to-top.is-visible {
  opacity: 1;
  visibility: visible;
  transform: translateY(0);
}
#fanbotica-back-to-top:hover {
  border-color: var(--accent);
  color: var(--foreground);
  transform: translateY(-2px);
}
@media (prefers-reduced-motion: reduce) {
  #fanbotica-back-to-top {
    transition: opacity var(--transition), visibility var(--transition);
    transform: none !important;
  }
}

/* Google reCAPTCHA v3 badge — Contact Form 7's `[recaptcha]` field
   (used on the Contatti form) loads this sitewide, floating fixed
   bottom-right. On this LOCAL dev domain it renders as a blank white
   sliver: reCAPTCHA validates the site key against a registered domain
   (the real fanbotica.com), so it silently refuses to render its
   logo/shield for `fanbotica-redesign.local` — not a cert issue, a
   domain-allowlist one, and not something fixable from theme CSS. Hidden
   here purely as a cosmetic local-dev choice, per direct request — the
   real site's own badge is untouched by this (this stylesheet only ever
   runs on this local install), and will render normally there since the
   key is scoped to the real domain. */
.grecaptcha-badge {
  display: none !important;
}

/* REAL bug: Bloom's popup close button ("×") was invisible — its icon-font
   glyph inherited the theme's sitewide --foreground (near-white, meant for
   text on our dark backgrounds), rendered on Bloom's own white popup
   background: white-on-white. Bloom never sets its own color here, so it
   was just inheriting ours. A plain dark grey reads correctly against the
   popup's white panel without touching --foreground itself (which is
   correct everywhere else on the dark-themed site). */
.et_bloom_close_button,
.et_bloom_close_button::before {
  color: #333333 !important;
}

/* ==========================================================================
   Monarch replacement — fixed share sidebar on single posts/projects.
   Same 7 platforms, same left-edge placement, a fraction of the weight.
   ========================================================================== */
.fanbotica-share-sidebar {
  position: fixed;
  left: 0;
  top: 40%;
  z-index: 90;
}
.fanbotica-share-sidebar ul {
  list-style: none;
  margin: 0;
  padding: 0;
  display: flex;
  flex-direction: column;
}
.fanbotica-share-sidebar a {
  display: flex;
  align-items: center;
  justify-content: center;
  width: 42px;
  height: 42px;
  background-color: var(--surface-raised);
  border: 1px solid var(--border);
  border-left: none;
  color: var(--muted);
  transition: color var(--transition), background-color var(--transition), width var(--transition);
}
.fanbotica-share-sidebar a:hover {
  color: var(--accent-foreground);
  background-color: var(--accent);
  width: 48px;
}
.fanbotica-share-sidebar svg {
  width: 18px;
  height: 18px;
  fill: currentColor;
  flex-shrink: 0;
}
@media (max-width: 900px) {
  .fanbotica-share-sidebar {
    display: none;
  }
}

/* ==========================================================================
   Bloom replacement — the "Subscribe!" flyin popup. Colors lifted straight
   from Bloom's own saved config (which already matched this theme's
   tokens), so the visual result is unchanged from before deactivating it.
   ========================================================================== */
.fanbotica-subscribe-popup {
  position: fixed;
  right: 24px;
  bottom: -100%;
  width: 320px;
  max-width: calc(100vw - 48px);
  background-color: var(--surface);
  border-top: 3px dashed var(--border);
  border-radius: var(--radius);
  box-shadow: var(--panel-shadow);
  padding: var(--space-5) var(--space-4) var(--space-4);
  z-index: 200;
  opacity: 0;
  transition: bottom 0.5s ease, opacity 0.5s ease;
}
.fanbotica-subscribe-popup.is-visible {
  bottom: 24px;
  opacity: 1;
}
.fanbotica-subscribe-popup__close {
  position: absolute;
  top: 10px;
  right: 12px;
  background: none;
  border: none;
  color: var(--muted);
  font-size: 1.4rem;
  line-height: 1;
  cursor: pointer;
  padding: 0.2rem;
}
.fanbotica-subscribe-popup__close:hover {
  color: var(--foreground);
}
.fanbotica-subscribe-popup__ribbon {
  display: inline-block;
  background-color: var(--critical);
  color: #fff;
  font-family: var(--font-mono);
  font-size: 0.7rem;
  font-weight: 700;
  letter-spacing: 0.08em;
  padding: 0.25rem 0.9rem;
  border-radius: 3px;
  margin-bottom: var(--space-3);
}
.fanbotica-subscribe-popup h3 {
  color: var(--foreground);
  font-size: 1.15rem;
  margin: 0 0 var(--space-2);
}
.fanbotica-subscribe-popup p {
  color: var(--muted);
  font-size: 0.88rem;
  line-height: 1.5;
  margin: 0 0 var(--space-3);
}
.fanbotica-subscribe-popup input[type="email"] {
  width: 100%;
  background-color: var(--surface-raised);
  border: 1px solid var(--border);
  border-radius: 6px;
  color: var(--foreground);
  padding: 0.65rem 0.8rem;
  font-size: 0.92rem;
  margin-bottom: var(--space-3);
}
.fanbotica-subscribe-popup button[type="submit"] {
  width: 100%;
  background-color: var(--accent);
  color: var(--accent-foreground);
  border: none;
  border-radius: 6px;
  font-weight: 700;
  letter-spacing: 0.03em;
  padding: 0.7rem;
  cursor: pointer;
  transition: filter var(--transition);
}
.fanbotica-subscribe-popup button[type="submit"]:hover {
  filter: brightness(1.08);
}
.fanbotica-subscribe-popup__status {
  text-align: center;
  font-size: 0.82rem;
  color: var(--live);
  min-height: 1.2em;
}
.fanbotica-subscribe-popup__footer {
  font-size: 0.72rem !important;
  color: var(--muted);
  border-top: 1px solid var(--border);
  padding-top: var(--space-3);
  margin-bottom: 0 !important;
}

/* Storefront's own "next/previous product" peek strip (the two edge tabs
   that slide in near the bottom of a product page) — plain white by
   default, the one card on the page still unstyled for this theme. */
.storefront-product-pagination a {
  background-color: var(--surface-raised) !important;
  border: 1px dashed var(--border);
  box-shadow: var(--panel-shadow);
}
.storefront-product-pagination a:hover {
  border-color: var(--accent);
}
.storefront-product-pagination__title {
  color: var(--accent) !important;
}