/* =====================================================================
   COOKIE CONSENT — BANNER (first layer)
   Step 4 scope: the banner only. The preferences panel (step 5) will add
   its own rules here, reusing .cc-banner__btn and the same tokens.

   Structure, same DOM on every breakpoint, only CSS reflows it:
     .cc-banner
       .cc-sr-only (label)
       .cc-banner__text  → intro sentence, "Політика cookie" inline <a>
       .cc-banner__actions → grid, 3 named areas:
         accept    = "Прийняти всі"   (row 1, full width)
         reject    = "Відхилити всі"  (row 2, left half)
         customize = "Налаштувати"    (row 2, right half)
   Landscape/desktop remap the same three areas into one row instead.

   Visual language reused from existing components, nothing invented:
   - Card chrome matches .iti__dropdown-content (style.css) — a floating
     card that sits directly over arbitrary page content with no
     darkening backdrop behind it, same situation this banner is in.
     NOT .modal's frosted rgba(184,184,184,0.4) look, which only reads
     correctly over its own dark .modal-backdrop (72% black) — this
     banner has no backdrop (explicit requirement: page stays fully
     usable, no scroll lock), so a near-opaque dark background
     (rgba(10,10,10,0.92), same as the phone dropdown) is what stays
     legible over hero imagery, light sections, anything.
   - Radius: --radius-card (20px), not .modal's 40px — that value was
     tuned for a large centered dialog, disproportionate on a ~440px
     corner card.
   - Buttons: .btn--ghost (style.css) as the shared base for all three —
     same height/padding/font/radius. Accept additionally gets
     --color-accent as its border plus a hover/focus glow (explicit
     exception — Reject and Customize stay on the plain white-border
     treatment, same as each other, so the only thing distinguishing
     Accept is color, never size/weight/position within its own row).
   - z-index: 900 — above .navbar (100) and .navbar__lang-menu (300),
     safely below .vmodal-backdrop (1100) and .modal-backdrop (2000), so
     any opened modal still covers the banner instead of visually
     fighting it.
===================================================================== */

/* One new token — no green exists anywhere in style.css's palette
   (--color-accent/--color-accent-dark are both red). Muted/desaturated
   on purpose (not a neon/material green) so it reads as "this site's
   dark theme, one more color" rather than a foreign UI kit; checked for
   adequate contrast against this file's own rgba(10,10,10,0.92) sheet
   background, which is what it's actually used against (border/glow,
   not body text, so WCAG's stricter text-contrast ratios don't apply —
   1.4.11 non-text contrast, ~3:1, is the relevant bar, comfortably
   cleared). Declared on :root here (not style.css) since it's specific
   to the cookie-consent UI, not a site-wide design token. */
:root {
  --cc-accept: #3fae76;
}

.cc-banner {
  position: fixed;
  z-index: 900;
  box-sizing: border-box;
  background: rgba(10, 10, 10, 0.92);
  backdrop-filter: blur(20px);
  -webkit-backdrop-filter: blur(20px);
  border: 1px solid rgba(255, 255, 255, 0.12);
  border-radius: var(--radius-card);
  box-shadow: 0 8px 32px rgba(0, 0, 0, 0.4);
  color: rgba(255, 255, 255, 0.92);
  font-family: var(--font-body);

  /* Hidden by default via plain CSS — no JS needed to reach this state,
     and nothing JS does ever needs to "wait" for it. .is-visible (added
     once, see cookie-consent.js) is the only thing that changes it.
     visibility's own transition-delay — not a JS transitionend handler
     — is what keeps the banner out of the accessibility tree/tab order
     while hidden, and is what pulls it back in once shown; the SAME
     mechanism removes it after the fade-out on hide. This is pure CSS,
     so the end state is correct even if the transition itself never
     runs (reduced motion, a backgrounded tab that skips paints, etc.) —
     exactly the "must not depend on transitionend" requirement. */
  opacity: 0;
  visibility: hidden;
  pointer-events: none;
  transform: translateY(16px);
  transition: opacity 0.3s ease, transform 0.3s ease, visibility 0s linear 0.3s;
}
.cc-banner.is-visible {
  opacity: 1;
  visibility: visible;
  pointer-events: auto;
  transform: translateY(0);
  transition: opacity 0.3s ease, transform 0.3s ease, visibility 0s linear 0s;
}
@media (prefers-reduced-motion: reduce) {
  .cc-banner { transform: none; transition: opacity 0.15s linear, visibility 0s linear 0.15s; }
  .cc-banner.is-visible { transition: opacity 0.15s linear, visibility 0s linear 0s; }
}

/* Standard clip-based visually-hidden pattern — used once, for the
   banner's own aria-label text (no visible heading exists per the
   design: just the one sentence). No equivalent utility existed
   anywhere else in the codebase to reuse. */
.cc-sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

.cc-banner__text {
  margin: 0 0 14px;
  font-size: 14px;
  line-height: 1.4;
}

/* Inline exception to the 44px rule (explicit direction) — stays
   visually inline with the sentence, still gets a little padding for
   easier tapping. display:inline-block is what makes vertical padding
   actually apply to an inline-flow element predictably across browsers.
   2026-10-14 bug-hunt decision #2 adds a real ≥44px tap AREA on top of
   that without touching the visible size — an invisible ::after, same
   technique/reasoning as style.css's own "TOUCH TAP-TARGET FLOOR"
   section — so both directions are satisfied at once: looks exactly
   like inline text, tap target is still floor-compliant. */
.cc-banner__link {
  display: inline-block;
  position: relative;
  padding: 2px 0;
  color: #fff;
  text-decoration: underline;
  text-underline-offset: 2px;
}
.cc-banner__link:hover { color: var(--color-accent); }
.cc-banner__link:focus-visible {
  outline: 2px solid var(--color-accent);
  outline-offset: 2px;
}
@media (max-width: 1023px), (pointer: coarse) {
  .cc-banner__link::after,
  .cc-policy__link::after {
    content: '';
    position: absolute;
    top: 50%;
    left: 50%;
    width: max(44px, 100%);
    height: max(44px, 100%);
    transform: translate(-50%, -50%);
  }
}

/* Grid everywhere (not flex) — same 3 named areas remapped per
   breakpoint below is simpler and more explicit than flex-wrap guessing
   where 3 items break across rows. */
.cc-banner__actions {
  display: grid;
  gap: 10px;
  grid-template-columns: 1fr 1fr;
  grid-template-areas:
    "accept accept"
    "reject customize";
}
/* Scoped to .cc-banner__actions specifically (2026-10-15 bug report) —
   was a bare [data-cc-action] selector with no ancestor scope, so it
   ALSO matched the panel's row2 buttons (same class + attribute,
   different component). grid-area:accept/reject with no matching
   named area in THAT grid (.cc-panel__row2 has none — it's a plain
   1fr/1fr grid, no grid-template-areas) doesn't just get ignored: it
   implicitly creates its own named grid LINES, fragmenting row2's
   intended 2-column track list into 4 (confirmed live — computed
   grid-template-columns came back as 4 tracks, not 2) and collapsing
   reject/accept on top of each other instead of side by side. */
.cc-banner__actions .cc-banner__btn[data-cc-action="accept"]    { grid-area: accept; }
.cc-banner__actions .cc-banner__btn[data-cc-action="reject"]    { grid-area: reject; }
.cc-banner__actions .cc-banner__btn[data-cc-action="customize"] { grid-area: customize; }

/* .btn--ghost's own default text (rgba(255,255,255,0.64)) and border
   (rgba(255,255,255,0.29)) are tuned for sitting next to brighter
   primary buttons elsewhere, where looking secondary is the point —
   every button this class reaches (banner's 3, panel's Save + its own
   Reject/Accept) needs to read as equally active, not muted/disabled.
   color is shared by all (white label, explicit requirement); border is
   NOT — see the accept/save override right below this rule.
   Double-class selector (.cc-banner/.cc-panel .cc-banner__btn, not just
   .cc-banner__btn) is deliberate, not decorative — .btn--ghost and a
   single-class .cc-banner__btn have EQUAL specificity (0,1,0 each), so
   whichever stylesheet happens to be linked later in <head> would win
   the tie; confirmed live more than once this round that properties
   were silently losing to .btn--ghost's own defaults without this.
   This guarantees the override regardless of <link> order on whatever
   page includes this file next. Listed for both ancestors since the
   panel (added this step) reuses the exact same button class. */
.cc-banner .cc-banner__btn,
.cc-panel .cc-banner__btn {
  color: #fff;
  border-color: rgba(255, 255, 255, 0.4);
  transition: border-color 0.2s ease, box-shadow 0.2s ease;
}

/* Accept (banner) and Save (panel) only — explicit exception: a muted
   green border (--cc-accept) plus a subtle glow, hover/focus only.
   Everything else about these buttons (height, padding, font-size,
   font-weight) is identical to Reject/Customize — same .btn--ghost
   base — so the only thing that sets them apart is color, not size,
   weight, or (on the banner) being alone on its own row, which is a
   layout necessity (3 Ukrainian labels don't fit one row on a 320px
   sheet), not a deliberate emphasis choice. Was accent-red; changed per
   explicit direction — red reads as "decline" in UX convention. */
.cc-banner .cc-banner__btn[data-cc-action="accept"],
.cc-panel .cc-banner__btn[data-cc-action="save"] {
  border-color: var(--cc-accept);
}
.cc-banner .cc-banner__btn[data-cc-action="accept"]:hover,
.cc-banner .cc-banner__btn[data-cc-action="accept"]:focus-visible,
.cc-panel .cc-banner__btn[data-cc-action="save"]:hover,
.cc-panel .cc-banner__btn[data-cc-action="save"]:focus-visible {
  /* rgba form of --cc-accept (#3fae76) — no -rgb variant token exists
     to derive this from the custom property directly. */
  box-shadow: 0 0 12px rgba(63, 174, 118, 0.5);
}

/* .btn--ghost itself (style.css) only styles :hover — no :focus-visible
   anywhere in the codebase for it. Real gap to fill for real <button>s
   reached by keyboard, not a style being "reused" from elsewhere. */
.cc-banner__btn:focus-visible {
  outline: 2px solid var(--color-accent);
  outline-offset: 2px;
}

/* ===================== DESKTOP (>768px) — same two-tier grid ========= */
@media (min-width: 769px) {
  .cc-banner {
    left: 24px;
    bottom: 24px;
    width: 440px;
    max-width: calc(100vw - 48px);
    padding: 24px;
  }
}

/* ===================== MOBILE (<=768px) — bottom sheet, portrait ===== */
@media (max-width: 768px) {
  .cc-banner {
    left: 0;
    right: 0;
    bottom: 0;
    width: 100%;
    border-radius: var(--radius-card) var(--radius-card) 0 0;
    border-width: 1px 0 0 0;
    /* Phone-confirmed: the base box-shadow (0 8px 32px, falls below-right
       — correct for the desktop floating card) reads as nothing on a
       bottom sheet, since there's no content below it to cast onto.
       Flipped to fall upward instead, same color/blur/spread family as
       the desktop shadow — not a new value, just the one direction that
       actually separates a BOTTOM sheet from the content above it. */
    box-shadow: 0 -8px 24px rgba(0, 0, 0, 0.4);
    /* Tightened repeatedly across phone checks — every value here is the
       smallest that still reads as deliberate spacing, not the smallest
       possible in isolation. Text/buttons stay at the 14px/44px floors;
       this only squeezes the space AROUND them. */
    padding: 14px var(--pad-x) max(10px, calc(env(safe-area-inset-bottom, 0px) + 10px));
    transform: translateY(100%); /* slides up from fully off-screen, not just a fade */
  }
  .cc-banner.is-visible { transform: translateY(0); }

  .cc-banner__text { margin-bottom: 10px; }

  /* .cc-banner/.cc-panel prefix required, not cosmetic — same equal-
     specificity tie against .btn--ghost as the color/border rule above,
     caught live here too: font-size/padding/white-space were all
     silently losing to .btn--ghost's own 13px/14px-32px/nowrap before
     this fix, which would have meant text never actually wrapped at
     320px at all. */
  .cc-banner .cc-banner__btn,
  .cc-panel .cc-banner__btn {
    /* 52px (was 44px) — 2026-10-15 bug report, explicit spec for the
       panel's 3 footer buttons; applied via the same shared selector
       the banner already reuses (see this rule's own comment above),
       so the banner's identical 3-button pattern gets the same
       comfortable, consistent tap target rather than a special case. */
    min-height: 52px;
    font-size: 14px;
    /* .btn--ghost's own white-space:nowrap would force an overflow/
       horizontal-scroll situation at 320px instead of wrapping —
       explicit requirement is wrap, never shrink below 14px or ellipsis,
       so this is the one base-class property that has to be undone
       here. Tightened padding (vs. btn--ghost's 14px/32px, tuned for
       full-width desktop buttons) to reduce how OFTEN wrapping is
       needed in the first place, without relying on it alone. */
    white-space: normal;
    padding: 10px 12px;
    text-align: center;
  }
}

/* Landscape phone: one row of three equal columns — same three grid
   areas, just remapped into a single row instead of the 2-tier portrait
   layout. "sheet stays compact" explicit requirement, doubly true in
   landscape where the viewport is often under 400px tall altogether. */
@media (max-width: 768px) and (orientation: landscape) {
  .cc-banner {
    padding-top: 10px;
    padding-bottom: max(10px, calc(env(safe-area-inset-bottom, 0px) + 10px));
  }
  .cc-banner__text { margin-bottom: 10px; }
  .cc-banner__actions {
    grid-template-columns: 1fr 1fr 1fr;
    grid-template-areas: "accept reject customize";
  }
  .cc-banner .cc-banner__btn { min-height: 40px; white-space: normal; padding: 8px 10px; }
}

/* =====================================================================
   PREFERENCES PANEL
   Reuses .modal-backdrop/.modal/.modal__close/is-open as-is (style.css)
   — same dark overlay, same glassy card chrome, same close button —
   per explicit direction. .cc-panel is a MODIFIER class alongside
   .modal (not a replacement), so these rules only ever affect this one
   modal instance, never the CTA/lead/ask/video modals that also use
   .modal.

   Structure:
     .modal-backdrop#ccPanelBackdrop
       .modal.cc-panel
         .modal__close
         .cc-panel__scroll   → title, intro, one .cc-panel__cat per
                                category (switch + desc + collapsible
                                service/cookie details)
         .cc-panel__actions  → "Зберегти вибір" (full width, green) then
                                .cc-panel__row2 (Reject | Accept, 50/50,
                                plain .cc-banner__btn reused for all 3 —
                                see the shared color/border rules above)
   .modal's own overflow-y:auto is REPLACED by a flex-column layout
   (.cc-panel: display:flex, overflow:hidden) with .cc-panel__scroll as
   the one scrolling child and .cc-panel__actions as a sibling, not a
   child, of the scroll area — simpler and more robust than
   position:sticky for "body scrolls, footer never does": the footer is
   just outside the scroll container entirely, not trying to stick
   within it.
===================================================================== */
.cc-panel {
  display: flex;
  flex-direction: column;
  padding: 0;
  overflow: hidden;
}
.cc-panel__scroll {
  flex: 1 1 auto;
  min-height: 0; /* lets a flex child actually shrink below its content size enough to scroll, instead of forcing the whole column taller */
  overflow-y: auto;
  padding: 56px 55px 32px;
}
.cc-panel__title {
  margin: 0 0 12px;
  font-family: var(--font-display);
  font-size: 28px;
  color: #fff;
}
.cc-panel__intro {
  margin: 0 0 24px;
  font-size: 14px;
  line-height: 1.5;
  color: rgba(255, 255, 255, 0.75);
}

.cc-panel__cat {
  padding: 18px 0;
  border-top: 1px solid rgba(255, 255, 255, 0.12);
}
.cc-panel__cat:first-of-type { padding-top: 0; border-top: none; }
.cc-panel__cat-header {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: 16px;
}
.cc-panel__cat-title {
  margin: 0;
  font-size: 16px;
  font-weight: 600;
  color: #fff;
}
.cc-panel__cat-desc {
  margin: 6px 0 0;
  font-size: 14px;
  line-height: 1.4;
  color: rgba(255, 255, 255, 0.7);
}
.cc-panel__always-on {
  font-size: 13px;
  color: rgba(255, 255, 255, 0.6);
  white-space: nowrap;
}

/* Toggle track + thumb. Checkbox itself stays in the DOM and focusable
   (1px, opacity:0 — never display:none/visibility:hidden, both of which
   would pull it out of the tab order and break keyboard use) rather
   than visually hidden the usual clip-based way, since its own box
   doesn't need to match its visual size here. padding on the label is
   what reaches the 44px tap target without the track itself needing to
   be that tall — same "padding, not a bigger visible shape" technique
   used for .cc-banner__link. */
.cc-switch {
  position: relative;
  display: inline-flex;
  align-items: center;
  flex-shrink: 0;
  padding: 11px 0;
  cursor: pointer;
}
.cc-switch input {
  position: absolute;
  width: 1px;
  height: 1px;
  opacity: 0;
  margin: 0;
}
.cc-switch__track {
  position: relative;
  width: 40px;
  height: 22px;
  border-radius: 11px;
  background: rgba(255, 255, 255, 0.15);
  border: 1px solid rgba(255, 255, 255, 0.3);
  transition: background 0.2s ease, border-color 0.2s ease;
}
.cc-switch__thumb {
  position: absolute;
  top: 2px;
  left: 2px;
  width: 16px;
  height: 16px;
  border-radius: 50%;
  background: #fff;
  transition: transform 0.2s ease;
}
.cc-switch input:checked ~ .cc-switch__track {
  background: var(--cc-accept);
  border-color: var(--cc-accept);
}
.cc-switch input:checked ~ .cc-switch__track .cc-switch__thumb {
  transform: translateX(18px);
}
.cc-switch input:disabled ~ .cc-switch__track {
  opacity: 0.7;
}
.cc-switch input:disabled {
  cursor: not-allowed;
}
.cc-switch input:focus-visible ~ .cc-switch__track {
  outline: 2px solid var(--color-accent);
  outline-offset: 2px;
}

.cc-panel__details-toggle {
  display: inline-block;
  margin-top: 10px;
  padding: 6px 0;
  background: none;
  border: none;
  color: #fff;
  font-family: var(--font-body);
  font-size: 14px;
  text-decoration: underline;
  text-underline-offset: 2px;
  cursor: pointer;
}
.cc-panel__details-toggle:hover { color: var(--color-accent); }
.cc-panel__details-toggle:focus-visible {
  outline: 2px solid var(--color-accent);
  outline-offset: 2px;
}
.cc-panel__details {
  margin-top: 10px;
  padding: 12px 14px;
  background: rgba(255, 255, 255, 0.05);
  border-radius: 10px;
  font-size: 14px;
  line-height: 1.5;
  color: rgba(255, 255, 255, 0.75);
}
.cc-panel__service { margin-bottom: 10px; }
.cc-panel__service:last-child { margin-bottom: 0; }
.cc-panel__service-name { margin: 0 0 4px; font-weight: 600; color: #fff; }
.cc-panel__cookie { margin: 0 0 2px 12px; }

.cc-panel__actions {
  flex: 0 0 auto;
  padding: 20px 55px calc(20px + env(safe-area-inset-bottom, 0px));
  border-top: 1px solid rgba(255, 255, 255, 0.12);
}
.cc-panel__save {
  display: block;
  width: 100%;
  margin-bottom: 10px;
  text-align: center;
}
/* display:flex, gap:10px here (base/desktop) — UNCHANGED, deliberately
   (2026-10-15 bug report is explicitly mobile/tablet-scoped, desktop
   must stay pixel-identical). This rule has the exact same "buttons
   size to content instead of filling the row" bug at desktop width
   too, but fixing that is out of scope here — see the mobile-only
   grid override in the @media (max-width:768px) block below, which is
   where the real fix lives. */
.cc-panel__row2 {
  display: flex;
  gap: 10px;
}

/* ===================== DESKTOP (>768px) ===================== */
@media (min-width: 769px) {
  .cc-panel {
    width: 640px;
    max-height: calc(100vh - 80px);
  }
}

/* ===================== MOBILE (<=768px) — near-full-height sheet ===== */
@media (max-width: 768px) {
  .cc-panel {
    width: 100%;
    max-height: 92vh;
    border-radius: 28px;
  }
  .cc-panel__scroll { padding: 32px var(--pad-x) 24px; }
  .cc-panel__title { font-size: 22px; }
  .cc-panel__actions { padding: 16px var(--pad-x) calc(16px + env(safe-area-inset-bottom, 0px)); }
  /* grid 1fr 1fr (2026-10-15 bug report, mobile/tablet only — desktop's
     own rule above stays untouched) — was display:flex with no
     flex-basis on either button, so each sized to its own content
     ("Відхилити всі"/"Прийняти всі" are different lengths) and the row
     fell short of .cc-panel__save's own full width above it by however
     much shorter their combined content was — measured ~11px of dead
     space on the right, accept's own right edge not reaching save's.
     minmax(0,1fr), not bare 1fr — a bare `1fr` track's real floor is
     `minmax(auto,1fr)`, so its minimum is its content's min-content
     width; "Відхилити" has no space to wrap inside, so at 320px that
     one word's own min-content width exceeded its fair half-share and
     dragged the whole grid past save's own right edge too (measured
     ~12px overshoot) while leaving the two tracks visibly unequal.
     minmax(0,1fr) drops that content floor so both columns always
     split the row's actual width evenly, label wrapping inside its own
     column (explicitly allowed down to 320px) instead of pushing past
     it. */
  .cc-panel__row2 {
    display: grid;
    grid-template-columns: minmax(0, 1fr) minmax(0, 1fr);
    gap: 12px;
  }
}

/* =====================================================================
   WITHDRAWAL TOAST
   Same hidden/.is-visible + transition-delay-on-visibility mechanism as
   .cc-banner — see that rule's own comment for why this never depends
   on a JS transitionend handler either.
===================================================================== */
.cc-toast {
  position: fixed;
  left: 50%;
  bottom: 24px;
  transform: translate(-50%, 8px);
  z-index: 950; /* above the banner (900), still below any modal (1100+) */
  display: flex;
  align-items: center;
  gap: 14px;
  max-width: calc(100vw - 48px);
  padding: 14px 18px;
  background: rgba(10, 10, 10, 0.95);
  border: 1px solid rgba(255, 255, 255, 0.15);
  border-radius: var(--radius-btn);
  box-shadow: 0 8px 24px rgba(0, 0, 0, 0.45);
  color: #fff;
  font-family: var(--font-body);
  font-size: 14px;
  line-height: 1.4;

  opacity: 0;
  visibility: hidden;
  pointer-events: none;
  transition: opacity 0.25s ease, transform 0.25s ease, visibility 0s linear 0.25s;
}
.cc-toast.is-visible {
  opacity: 1;
  visibility: visible;
  pointer-events: auto;
  transform: translate(-50%, 0);
  transition: opacity 0.25s ease, transform 0.25s ease, visibility 0s linear 0s;
}
.cc-toast__reload {
  flex-shrink: 0;
  padding: 8px 14px;
  background: none;
  border: 1px solid rgba(255, 255, 255, 0.4);
  border-radius: var(--radius-btn);
  color: #fff;
  font-family: var(--font-body);
  font-size: 14px;
  cursor: pointer;
}
.cc-toast__reload:hover { border-color: #fff; }
.cc-toast__reload:focus-visible {
  outline: 2px solid var(--color-accent);
  outline-offset: 2px;
}
@media (max-width: 768px) {
  .cc-toast {
    left: var(--pad-x);
    right: var(--pad-x);
    bottom: max(16px, calc(env(safe-area-inset-bottom, 0px) + 16px));
    transform: translateY(8px);
    max-width: none;
  }
  .cc-toast.is-visible { transform: translateY(0); }
}

/* =====================================================================
   COOKIE POLICY PAGE (cookies.html)
   Lives inside the same .light-wrapper every other content page (faq.
   html) uses — light background, dark text, the established "document"
   look on this site. #1a1a1a is the same literal dark-on-light text
   color used elsewhere (style.css — no --color-text-dark token exists
   to reference instead). No animations (explicit requirement) — every
   rule below is static layout/color, nothing transitions.
===================================================================== */
.cc-policy {
  max-width: 760px;
  margin: 0 auto;
  padding: 80px var(--pad-x) 120px;
  color: #1a1a1a;
  font-family: var(--font-body);
}
.cc-policy__title {
  margin: 0 0 8px;
  font-family: var(--font-display);
  font-size: 40px;
  line-height: 1.1;
  color: #1a1a1a;
}
.cc-policy__date {
  margin: 0 0 48px;
  font-size: 14px;
  color: rgba(26, 26, 26, 0.6);
}
.cc-policy h2 {
  margin: 48px 0 16px;
  font-family: var(--font-body);
  font-weight: 700;
  font-size: 22px;
  line-height: 1.3;
  color: #1a1a1a;
}
.cc-policy h2:first-of-type { margin-top: 0; }
.cc-policy p {
  margin: 0 0 16px;
  font-size: 16px;
  line-height: 1.7;
}
.cc-policy ul {
  margin: 0 0 16px;
  padding-left: 22px;
  font-size: 16px;
  line-height: 1.7;
}
.cc-policy li { margin-bottom: 8px; }
.cc-policy strong { color: #1a1a1a; }
.cc-policy__link {
  position: relative;
  color: #1a1a1a;
  text-decoration: underline;
  text-underline-offset: 2px;
}
.cc-policy__link:hover { color: var(--color-accent); }
.cc-policy__link:focus-visible {
  outline: 2px solid var(--color-accent);
  outline-offset: 2px;
}

/* Standalone style (NOT .btn--ghost + the .cc-banner/.cc-panel
   specificity-fix pattern used elsewhere in this file) — deliberately:
   that pattern exists only to win a specificity TIE against .btn--ghost
   on an element that also carries it, which this single one-off button
   doesn't need to enter into at all if it just matches the same values
   directly instead. Border/glow colors match "Зберегти вибір" exactly
   (--cc-accept) for visual consistency with the panel's own primary
   action, per explicit direction. */
.cc-policy__settings-btn {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  margin: 8px 0 24px;
  padding: 14px 32px;
  background: transparent;
  border: 1px solid var(--cc-accept);
  border-radius: var(--radius-btn);
  color: #1a1a1a;
  font-family: var(--font-body);
  font-size: 14px;
  font-weight: 500;
  letter-spacing: 0.5px;
  cursor: pointer;
  transition: box-shadow 0.2s ease;
}
.cc-policy__settings-btn:hover,
.cc-policy__settings-btn:focus-visible {
  box-shadow: 0 0 12px rgba(63, 174, 118, 0.5);
}
.cc-policy__settings-btn:focus-visible {
  outline: 2px solid var(--color-accent);
  outline-offset: 2px;
}

/* ---- Cookie table ---- */
.cc-policy__table-group {
  margin: 24px 0 10px;
  font-size: 16px;
  font-weight: 700;
  color: #1a1a1a;
}
.cc-policy__table-group:first-of-type { margin-top: 12px; }
.cc-policy__table {
  width: 100%;
  margin-bottom: 8px;
  border-collapse: collapse;
  font-size: 14px;
  line-height: 1.5;
}
.cc-policy__table th,
.cc-policy__table td {
  padding: 10px 12px;
  text-align: left;
  vertical-align: top;
  border-bottom: 1px solid rgba(26, 26, 26, 0.15);
}
.cc-policy__table th {
  font-weight: 700;
  color: #1a1a1a;
  white-space: nowrap;
}
.cc-policy__table td { color: rgba(26, 26, 26, 0.85); overflow-wrap: anywhere; }

/* ===================== MOBILE (<=768px) ===================== */
@media (max-width: 768px) {
  .cc-policy { padding: 48px var(--pad-x) 80px; }
  .cc-policy__title { font-size: 28px; }
  .cc-policy h2 { font-size: 19px; margin: 36px 0 12px; }
  .cc-policy p,
  .cc-policy ul { font-size: 15px; }

  /* Table → stacked cards. No horizontal scroll, nothing cut, long
     cookie names wrap — a <table> laid out this way (each cell its own
     block row, header row hidden) IS the "card", not a second markup
     built in JS for mobile specifically (see renderCookieTable in
     cookie-consent.js: one table, rendered once, for every width). */
  .cc-policy__table thead { display: none; }
  .cc-policy__table,
  .cc-policy__table tbody,
  .cc-policy__table tr,
  .cc-policy__table td { display: block; width: 100%; }
  .cc-policy__table tr {
    margin-bottom: 14px;
    padding: 12px 14px;
    background: rgba(26, 26, 26, 0.04);
    border: 1px solid rgba(26, 26, 26, 0.12);
    border-radius: 10px;
  }
  .cc-policy__table td {
    padding: 4px 0;
    border-bottom: none;
    overflow-wrap: anywhere;
  }
  .cc-policy__table td::before {
    content: attr(data-label);
    display: block;
    margin-bottom: 2px;
    font-size: 12px;
    font-weight: 700;
    color: rgba(26, 26, 26, 0.55);
  }
}