/**
 * nav-menu.css — the two things the Webflow Designer cannot express for the
 * full-screen menu. Everything else lives on the .nav-menu* classes in the
 * Designer, where it belongs.
 */

/* 1 ------------------------------------------------------------------------
 * Scroll containment.
 *
 * The open panel scrolls its own overflow when the links do not fit. Without
 * this, a scroll gesture that reaches the end of the panel chains to the page
 * behind it, which is still there — just inert. Webflow exposes `overflow` but
 * not `overscroll-behavior`, so this one declaration has to live in a file.
 */
[data-nav-menu] {
  overscroll-behavior: contain;
}

/* 2 ------------------------------------------------------------------------
 * The clip-path carrier.
 *
 * nav-menu.js injects a zero-size <svg> holding the <clipPath> whose path is
 * redrawn each frame. The panel references it with `clip-path: url(#…)`, so the
 * panel is what animates in — nothing sweeps over the top of it and no shape is
 * ever painted. This element renders nothing itself and must never affect
 * layout.
 *
 * It exists in no Webflow page, so a Designer class for it would be applied to
 * nothing and the next dead-style sweep would correctly remove it. Hence a file.
 */
.nav-menu_clip {
  position: absolute;
  width: 0;
  height: 0;
  overflow: hidden;
  pointer-events: none;
}

/* 3 ------------------------------------------------------------------------
 * The narrow-desktop band: 1200px down to the tablet breakpoint.
 *
 * This is the one range in the nav's design that Webflow cannot express. Its
 * breakpoints are fixed — the nearest above the tablet cutoff is 1280 — so a
 * design that changes at 1200 has nowhere to live in the Designer. Everything
 * else in this nav uses native breakpoints; only this band is hand-written.
 *
 * Lower bound is 992 rather than 991 so it stops exactly where Webflow's
 * `medium` (max-width: 991px) takes over. Overlapping them would mean two
 * rules fighting over a single pixel, decided by source order.
 *
 * Loaded after Webflow's stylesheet, so equal-specificity selectors win here
 * without needing !important.
 */
@media (min-width: 992px) and (max-width: 1200px) {
  /* Type steps down: 140 -> 100 primary, 48 -> 42 secondary. */
  .nav-menu_display {
    font-size: 100px;
    line-height: 100px;
  }

  .nav-menu_display.is-secondary {
    font-size: 42px;
    line-height: 42px;
  }

  /* The left column stops reserving 685px and spreads its four rows instead:
   * four 100px rows in a 440px dialog leaves 40px, distributed between them
   * rather than pooled at the bottom. */
  .nav-menu_left {
    min-width: 0;
    justify-content: space-between;
  }

  /* The right column stops stretching and becomes content-width, with a fixed
   * 60px between the contact block and the link list in place of the
   * space-between the wider layout uses. */
  .nav-menu_right {
    flex: 0 0 auto;
    justify-content: flex-start;
    row-gap: 60px;
    padding-bottom: 8px;
  }
}

/* 4 ------------------------------------------------------------------------
 * The menu toggle reserves the width of its longest label, always.
 *
 * The button's text alternates between "menu" and "close". Those are different
 * widths (55.5px vs 65.3px at 767), and `.nav-top_right` is `justify-content:
 * flex-end`, so every time the menu opened the button grew leftwards and shoved
 * the mode switcher 10px sideways. Opening a menu should not move an unrelated
 * control.
 *
 * Rather than hardcode a width, the button carries a hidden copy of the longer
 * word and both occupy the same grid cell. The box is therefore always exactly
 * as wide as the widest label, at every breakpoint and font size, and it stays
 * correct if the wording ever changes — the only thing to keep in step is the
 * `content` string below and the labels in nav-menu.js.
 *
 * `display: grid` and the end/centre alignment are on `.nav-label.nav-action
 * .is-menu` in the Designer; only the parts Webflow cannot author are here.
 * The ::after inherits `text-transform: uppercase` from `.nav-label`, so it
 * measures the same glyphs that actually render.
 */
[data-nav-toggle] > [data-nav-label],
[data-nav-toggle]::after {
  grid-area: 1 / 1;
}

[data-nav-toggle]::after {
  content: "close";
  visibility: hidden;
  pointer-events: none;
}

/* 5 ------------------------------------------------------------------------
 * Social links become icon buttons at 767 and below.
 *
 * Figma annotation on the mobile-horizontal frames: "swap to icons". The three
 * links keep their words for screen readers and voice control and show only the
 * brand mark, in a round 44x44 target.
 *
 * Above 767 the icons are display:none and the words render normally, so this
 * is the same shape as the mode switcher in src/mode-toggle.css — and it is
 * here for the same reason: the Designer's only way to hide the text is
 * display:none, which would strip each link's accessible name and leave three
 * unlabelled links (WCAG 4.1.2). The round box, size and background token are
 * on `.nav-menu_display.is-secondary.is-social` in the Designer, where they
 * belong.
 *
 * The icon paths are fill="currentColor", so they take the link's colour token
 * in both modes with nothing declared here.
 */
[data-social-icon] {
  display: none;
}

@media (max-width: 767px) {
  [data-social-label] {
    position: absolute;
    width: 1px;
    height: 1px;
    margin: -1px;
    padding: 0;
    border: 0;
    overflow: hidden;
    clip-path: inset(50%);
    white-space: nowrap;
  }

  [data-social-icon] {
    display: block;
    width: 24px;
    height: 24px;
    flex: 0 0 auto;
  }
}

/* 6 ------------------------------------------------------------------------
 * Centring the menu must never hide the top of it.
 *
 * `.nav-menu` centres its content and also scrolls (`overflow: auto`). Those
 * two together have a well-known failure: when the content is TALLER than the
 * box, `justify-content: center` overflows it equally in both directions, and
 * the part above the top edge cannot be scrolled to — there is no scroll
 * position further back than zero. The menu then looks bottom-aligned and its
 * first links are simply unreachable.
 *
 * That is not hypothetical here. It happened at 767 while the display type was
 * still at the tablet size (content 1500px in an 889px box put the first link
 * at -310px), and it is waiting to happen again at 390, where nav-top is
 * 176-205px tall depending on which tagline the cycler is showing and the space
 * left for the menu changes as it rotates.
 *
 * `safe` says: centre while it fits, fall back to flex-start the moment it does
 * not, so the overflow all goes downwards where it can be scrolled to. A
 * browser that does not understand the keyword drops the whole declaration and
 * keeps Webflow's plain `center`, which is exactly today's behaviour — so this
 * can only improve things.
 *
 * Scoped to 991 and below because that is where the menu is a single tall
 * column; above it the two-column layout is nowhere near the viewport height.
 */
@media (max-width: 991px) {
  .nav-menu {
    justify-content: safe center;
  }
}

/* 7 ------------------------------------------------------------------------
 * The menu's email drops to the designed 24px at 767 and below.
 *
 * Both the mobile-horizontal and mobile-portrait frames set this text at 24px;
 * live it renders 29-32px, inherited from `.copy-email-text__wrap`.
 *
 * Scoped by ancestor rather than by class on purpose. copy-email is a COMPONENT
 * with two instances on most pages — one in this menu, one in the page footer —
 * and a component's internals are shared, so there is no class that reaches
 * only the menu's copy. `.nav-menu` as an ancestor is the only selector that
 * separates them, and the Designer cannot author ancestor-scoped rules.
 *
 * The footer's email is deliberately NOT changed: its size at mobile is not in
 * the frames this came from, and it is a different surface.
 *
 * Only font-size is set. `.copy-email-text__wrap` sizes its height as `1.2em`
 * and its line-height as a unitless 1.2, so the roller's clip window and its
 * three stacked states all follow from this one value.
 */
@media (max-width: 767px) {
  .nav-menu .copy-email-text__wrap {
    font-size: 24px;
  }
}

/* 4 ------------------------------------------------------------------------
 * Menu handoff: the incoming page arrives already covered by the menu.
 *
 * menu-handoff.js (blocking, in the header) sets .nav-handoff on <html> when
 * this navigation started from a menu link, so the panel is painted in the
 * first frame and nav-menu.js can retreat the diagonal edge off it. Without a
 * rule here the panel would stay hidden until the footer script ran, and the
 * new page would flash before being covered.
 *
 * Inline styles from nav-menu.js override this the moment it takes over, and
 * the class is removed on a timer regardless, so a failed script cannot leave
 * the panel stuck over the page.
 */
.nav-handoff [data-nav-menu] {
  opacity: 1;
  visibility: visible;
}

/* 5 ------------------------------------------------------------------------
 * Plain handoff: the diagonal without the menu.
 *
 * Bottom-bar links (guidelines, space) get the same reveal as a menu link, but
 * the panel must arrive EMPTY — rows the visitor never opened flashing past
 * would read as the menu opening itself. The panel colour and the edge do all
 * the work. nav-menu.js keeps the rows parked for this case; this rule covers
 * the frames before it runs.
 */
.nav-handoff-plain [data-nav-menu] .nav-menu_inner {
  opacity: 0;
}