/* tooltips stay in the layout tree (display:block) even while invisible
     so their opacity/visibility fade can be delayed on hide - that means
     an off-screen or near-edge tooltip's box still counts toward the
     page's scrollable width even when nobody can see it. Clip that at the
     root so it can never produce a horizontal scrollbar. */
  html, body { overflow-x: hidden; }
  body { min-height: 100vh; }
  .site-header {
    display: flex; align-items: center; justify-content: space-between;
    padding: 1rem 1.5rem; border-bottom: 1px solid rgba(255,255,255,0.08);
  }
  .site-header .brand { display:flex; align-items:center; gap:.75rem; }
  .site-header img.logo { width: 42px; height: 42px; border-radius: 9999px; }
  .site-header h1 { font-size: 1.25rem; font-weight: 700; margin:0; }
  .offline-note {
    font-size: .8rem; opacity: .7; padding: .25rem 1.5rem 0;
  }
  main { max-width: 1200px; margin: 0 auto; padding: 1.5rem; }
  /* a build card needs ~710px (portrait + title + perk diamond); two side by
     side need ~1450px, more than the 1200px default. Widen main only when
     the viewport can actually fit two, so the 2-column build grid never
     kicks in without the room for it. */
  @media (min-width: 1560px) {
    main { max-width: 1560px; }
  }
  .intro { max-width: 800px; margin: 0 auto 1rem; line-height: 1.6; }
  .killer-grid-wrap { text-align: center; margin: 2rem 0; }
  .killer-grid-wrap a.killer-link { display: inline-block; cursor: pointer; text-decoration: none; }
  .killer-grid-wrap img { border-radius: .5rem; }
  .killer-grid-wrap a.killer-link.active img {
    outline: 3px solid #7582ff; outline-offset: 2px; border-radius: .5rem;
  }
  /* at 320-375px (iPhone SE, plenty of Android phones) two 150px+margin
     portraits (166px each) need 332px but the container is only ~327px,
     so it fell back to a single column - a ~9000px scroll to reach the
     last killer. Shrinking the thumbnail a little on narrow screens lets
     two comfortably fit per row instead. */
  @media (max-width: 480px) {
    .killer-grid-wrap a.killer-link img {
      max-width: 110px !important;
      margin-left: 4px !important; margin-right: 4px !important;
    }
  }
  .back-to-top {
    display:block; text-align:center; margin: 2rem auto; opacity:.7;
  }
  #currentKillerCont { scroll-margin-top: 1rem; }

  /* perk/addon hover tooltips.
     Two things caused the "spazzes out when I move my cursor" flicker:
     1) a margin-top gap between the icon and the tooltip - moving the mouse
        from one into the other crossed a dead strip with nothing hovered,
        instantly hiding the (display:none) tooltip before the cursor ever
        reached it.
     2) pointer-events:none on the tooltip meant that once the mouse *did*
        reach the tooltip's rendered area, its hover/clicks fell straight
        through to whatever sat underneath (a neighboring perk/addon icon),
        stealing the hover and swapping tooltips out from under the cursor.
     Fixed by closing the gap, letting the tooltip capture its own hover,
     and fading out on a short delay (via visibility, not display) so a
     tooltip stays alive - and rehoverable - through any momentary gap. */
  .wrapper { position: relative; }
  .ctooltip {
    top: 100%; left: 50%; transform: translateX(-50%);
    margin-top: 0; width: min(500px, 92vw); max-width: 92vw;
    box-shadow: 0 8px 24px rgba(0,0,0,.5); pointer-events: auto;
    display: block; opacity: 0; visibility: hidden;
    transition: opacity .12s ease, visibility 0s linear .2s;
  }
  .wrapper:hover .ctooltip, .wrapper:focus .ctooltip, .wrapper:focus-within .ctooltip,
  .ctooltip:hover {
    opacity: 1; visibility: visible; transition-delay: 0s; z-index: 50;
  }

  /* The 4 perk icons are laid out as overlapping squares to form a tight
     diamond (each square shares a 75x75px corner with its two neighbors),
     so the square hit-boxes overlap even though the diamond artwork
     doesn't. Hovering right around a shared corner - which lands almost
     exactly on a perk icon's visual center - could hit whichever
     neighboring square happened to paint on top, flipping the tooltip
     between two different perks as the cursor drifted by a pixel.
     .perkhit is an invisible sibling clipped to the actual diamond shape;
     it (not the full square) is now what's actually hoverable, so the
     dead corner shared with a neighbor no longer reacts to either one. */
  .perks .wrapper { pointer-events: none; }
  .perks .perkhit {
    position: absolute; inset: 0; cursor: help;
    clip-path: polygon(50% 0%, 100% 50%, 50% 100%, 0% 50%);
  }
  .perks .perkhit:hover ~ .wrapper .ctooltip, .perks .perkhit:focus ~ .wrapper .ctooltip {
    opacity: 1; visibility: visible; transition-delay: 0s; z-index: 50;
  }

  /* lay the 3 build cards out in a grid instead of one straight column */
  .builds-cont {
    display: grid;
    grid-template-columns: repeat(auto-fit, minmax(min(710px, 100%), max-content));
    align-items: start;
    justify-content: center;
    gap: 1.5rem;
    width: 100%;
  }
  .builds-cont .buildcont { margin: 0; }
  .name { min-width: 0; }
  .name > div { min-width: 0; white-space: normal; }

  /* the perk diamond (.perks) sits in the grid's 3rd column, which was a bare
     1fr track. A percentage-sized (w-full/h-full) flex child doesn't count
     toward that track's intrinsic size, so the track collapsed thinner than
     the 300px perk box actually needs and the diamond spilled into/over the
     next card. A range (minmax(size,1fr)) still gets treated as "auto" for
     intrinsic-size purposes, so pin the column to the perk box's exact size
     instead of a range. */
  .buildcont {
    grid-template-columns: 150px 225px var(--perk-cont-size, 300px) !important;
  }
  .portrait { overflow: hidden; }
  .portrait img { width: 100%; height: 100%; object-fit: cover; display: block; }

  /* keep build cards from overflowing small screens */
  @media (max-width: 700px) {
    /* :root sets a global --perk-cont-size: 300px default that .buildcont
       inherits directly (it's not a descendant of the .perkbox div the JS
       below scopes the 180px override to), so var(--perk-cont-size) here
       would still resolve to 300px. Hardcode the 180px this query actually
       uses instead of relying on inheritance. */
    .buildcont {
      grid-template-columns: 100px 180px !important;
      grid-template-areas: "portrait title" "portrait addons" "portrait perks";
      grid-template-rows: auto auto auto;
      row-gap: .5rem;
    }
    .addons { flex-direction: column; }
    /* --perk-size / --perk-margin are declared once at :root as calc()s off
       --perk-cont-size, so their *computed* value (150px/75px, from the
       root's 300px) is what gets inherited everywhere - overriding
       --perk-cont-size lower in the tree doesn't recompute them. Re-declare
       the calc()s here too so they resolve against this element's own
       180px instead of leaking the root's 300px value down to the diamond. */
    .perkbox {
      --perk-cont-size: 180px !important;
      --perk-size: calc(var(--perk-cont-size) / 2) !important;
      --perk-margin: calc(var(--perk-cont-size) / 4) !important;
    }
  }