/*
 * Consent banner for the console — the ask `mixpanel.js` mounts for a user who has recorded no decision.
 *
 * The website's `.cookie-consent` rules from `public/styles.css`, mirrored declaration for declaration
 * including both of its responsive tiers, so one product shows one ask: a centred card floating clear of the
 * bottom edge, translucent navy behind a blur, brand green outlined buttons. The docs pages carry the same
 * card in `src/styles/starlight-brand.css` but style the buttons differently, because Starlight has no `.btn`
 * to defer to; the main site's form is the one followed here.
 *
 * Its own file rather than a block in `xmemory-console.css`: `login.html`, `welcome.html`,
 * `accept_invite.html` and `access_denied.html` do not load that stylesheet, so rules living there would
 * reach only part of the console. Every page that loads `mixpanel.js` links this one, which
 * `pages::tests::pages_loading_mixpanel_also_link_the_consent_stylesheet` is what keeps true.
 *
 * No font family is declared, exactly as on the website: the ask inherits the page's own face, which is
 * Manrope on the console shell and Inter on the standalone sign-in and invite pages.
 */

/*
 * Fixed, and that is what the whole design rests on: the card is out of the page's flow, so it moves no
 * layout and nothing is laid out around it. It covers the strip it sits over for as long as it is up.
 *
 * The stacking tier is the one the local-run banner in `pages.rs` uses: above `console-bootstrap-overlay`
 * and `#xm-quota-upsell` (both 100000) and above `.support-chat-drawer` (99997), because consent has to stay
 * reachable while the bootstrap overlay covers the page. Two rules render above it —
 * `.kdt-row-drawer__enum-list` at 100020 and 100200 — which is correct: an open dropdown inside a drawer has
 * to stay usable over everything. Sharing the tier with the local-run banner is safe: that one owns the top
 * of the viewport and this one the bottom. The website sits at 1500, which is under everything the console
 * layers over its page, so this is the one declaration that deliberately differs from the mirrored source.
 */
#xm-cookie-consent {
  position: fixed;
  left: 50%;
  bottom: 20px;
  transform: translateX(-50%);
  width: min(960px, calc(100vw - 32px));
  box-sizing: border-box;
  padding: 16px 18px;
  border: 0.5px solid rgba(255, 255, 255, 0.2);
  background: rgba(12, 21, 32, 0.92);
  backdrop-filter: blur(10px);
  -webkit-backdrop-filter: blur(10px);
  z-index: 100001;
  display: flex;
  align-items: center;
  gap: 16px;
}

#xm-cookie-consent-text a,
.xm-cookie-consent__btn {
  pointer-events: auto;
}

#xm-cookie-consent-text {
  margin: 0;
  color: #788ca4;
  font-size: 14px;
  line-height: 1.4;
  font-weight: 300;
}

#xm-cookie-consent-text a {
  color: #ffffff;
  text-decoration: underline;
}

.xm-cookie-consent__actions {
  margin-left: auto;
  display: flex;
  gap: 10px;
  flex-shrink: 0;
}

/*
 * The website's `.btn` as its banner uses it, plus `.cookie-consent__btn`'s own width floor. Both of its
 * buttons render this way: `.btn--outline` only re-states the transparent background `.btn` already has, so
 * the ask offers two buttons of equal weight rather than steering towards accepting.
 */
.xm-cookie-consent__btn {
  font-family: inherit;
  font-size: 16px;
  font-weight: 300;
  color: #ffffff;
  height: 40px;
  padding: 0 24px;
  border-radius: 8px;
  background: transparent;
  border: 1px solid #66bf45;
  box-shadow: 0 0 0 4px rgba(102, 191, 69, 0.3);
  display: inline-flex;
  align-items: center;
  justify-content: center;
  cursor: pointer;
  min-width: 160px;
  white-space: nowrap;
}

.xm-cookie-consent__btn--outline {
  background: transparent;
}

.xm-cookie-consent__btn:focus-visible {
  outline: 2px solid rgba(102, 191, 69, 0.6);
  outline-offset: 2px;
}

@media (max-width: 900px) {
  #xm-cookie-consent {
    flex-direction: column;
    align-items: flex-start;
  }

  .xm-cookie-consent__actions {
    margin-left: 0;
    width: 100%;
    gap: 8px;
  }

  .xm-cookie-consent__btn {
    min-width: 0;
    flex: 1 1 auto;
  }
}

@media (max-width: 390px) {
  #xm-cookie-consent {
    width: calc(100vw - 20px);
    /*
     * A bare offset, with no `env(safe-area-inset-bottom)` added to it. None of the pages that carry this
     * banner set `viewport-fit`, so it keeps its `auto` default, the layout viewport is already inset out of
     * the unsafe area, and the inset resolves to zero -- the addition would move the card by nothing. Setting
     * `viewport-fit: cover` anywhere would make it live again, and would mean re-measuring this card.
     */
    bottom: 14px;
    padding: 18px;
    /*
     * Click-through, and only at this width. The console itself is never underneath: it hides `.app-layout`
     * outright below 900px and shows its "Desktop only" placeholder instead, so what this card covers on a
     * phone is sign-in and onboarding. Those it covers badly. On a 320px screen the card takes the whole
     * create-organisation button and most of the e-mail submit, and a phone has no room to scroll out from
     * under it, so without click-through a small screen could not finish signing up at all while the
     * decision was open.
     *
     * Wider, the trade reverses: the card is a ~90px strip against a console with room around it, and a
     * control in the covered band would take a click aimed at a banner the user can see perfectly well --
     * on the Users page that control deactivates an account with no confirmation step.
     *
     * It does not stop the card's own buttons from taking a click meant for the page; they keep
     * `pointer-events: auto`, as they must to be clickable at all.
     */
    pointer-events: none;
  }

  #xm-cookie-consent-text {
    font-size: 15px;
  }

  .xm-cookie-consent__actions {
    display: grid;
    grid-template-columns: 1fr 1fr;
    gap: 8px;
  }

  .xm-cookie-consent__btn {
    min-height: 0;
    height: clamp(36px, 10vw, 44px);
    padding: 0 clamp(8px, 2.8vw, 14px);
    font-size: clamp(10px, 3.2vw, 14px);
    line-height: 1;
  }
}