/* Works page only: full-bleed canvas hero + resonance filter pills */

html, body { height: 100%; overflow: hidden; }

.wrap {
  position: relative;
  width: 100%;
  height: 100vh;
  overflow: hidden;
  background: #000;
}

canvas { display: block; }

/* nav overlays the canvas here, unlike the in-flow nav on about.html. Scoped
   to this page via works.css itself (only index.html loads it), not by
   nesting under .wrap -- nav now lives outside .wrap in the markup so it can
   go back to a normal in-flow header on mobile (see media query below). */
.nav {
  position: absolute;
  top: 0; left: 0; right: 0;
  z-index: 10;
}

.nav-name,
.nav-right a { color: var(--neon); }
.nav-right a { opacity: 0.75; }
.nav-right a:hover,
.nav-right a.active { opacity: 1; }

.bottombar {
  position: absolute;
  bottom: 0; left: 0; right: 0;
  display: flex; gap: 6px; padding: 10px 22px;
  align-items: center; flex-wrap: nowrap;
  overflow-x: auto; z-index: 10;
}
.bottombar::-webkit-scrollbar { display: none; }

.rpill {
  font-size: 17px; letter-spacing: 0.06em;
  padding: 6px 14px; border-radius: 20px;
  border: 0.5px solid rgba(var(--neon-rgb),0.35);
  color: rgba(var(--neon-rgb),0.6);
  cursor: pointer; white-space: nowrap; flex-shrink: 0;
  transition: color 0.2s, border-color 0.2s; background: none;
}
.rpill:hover { color: var(--neon); border-color: rgba(0,255,100,0.6); }
.rpill.on { color: var(--neon); border-color: var(--neon); background: rgba(0,255,100,0.07); }

/* MOBILE — conventional scrolling card list instead of the hover-driven
   canvas constellation, which has no equivalent for touch (no hover, no
   mouseleave to end it -- a tap gets stuck "hovering" the last node it hit).
   js/works.js skips building the canvas/animation loop entirely below this
   width and builds #mobileCards instead; this query just swaps which one
   is visible. */
.mobile-list { display: none; }

/* Also matches on `hover: none` alone, not just narrow width -- a phone in
   landscape is wider than 700px but still has no mouse, so it needs this
   layout too (see js/works.js's MOBILE_QUERY for the full reasoning). */
@media (max-width: 700px), (hover: none) {
  html, body { height: auto; overflow: visible; }
  .wrap { display: none; }

  /* Only the positioning changes for mobile (back to a normal in-flow
     header) -- the neon-on-black colors above stay exactly as they are on
     desktop, so the page reads as the same site, not a different theme. */
  .nav { position: static; }

  /* A misty backdrop like the desktop canvas's drifting blobs, but drawn
     entirely in CSS (soft-edged radial-gradients, no filter/blur needed --
     the softness comes from the gradient's own transparent falloff) instead
     of a JS-driven canvas. A canvas version of this existed before and
     failed silently in restricted in-app browsers (WhatsApp, Instagram),
     leaving mobile visitors opening a shared link there with a blank black
     screen -- a background-image can't fail that way, it's exactly as
     supported as any other CSS background. Tiled at one viewport height and
     repeated down the page (not scoped to the tallest possible content, and
     no JS needed to measure it) so the density looks the same regardless of
     how many works there are to scroll through. */
  .mobile-list {
    display: block;
    padding: 44px 18px 48px;
    background-color: #000;
    background-repeat: repeat-y;
    background-size: 100% 100vh;
    /* Each blob's center/radius is chosen so its full extent (center +
       radius, where the gradient has faded to transparent anyway) stays
       within the tile -- e.g. a blob at 12% with a 30% radius reaches to
       -18%, past the top edge, and gets hard-clipped there before the next
       tile repeats, which is exactly the visible "seam"/cut a repeating
       background shouldn't have. Kept a safe margin in from every edge
       instead so each tile is plain black right at its own top/bottom, and
       one tile's black edge always meets the next tile's black edge --
       nothing to see a cut in. */
    background-image:
      radial-gradient(32% 16% at 18% 22%, #242424 0%, transparent 70%),
      radial-gradient(36% 18% at 82% 40%, #1c1c1c 0%, transparent 70%),
      radial-gradient(28% 15% at 25% 60%, #2a2a2a 0%, transparent 70%),
      radial-gradient(34% 16% at 78% 78%, #141414 0%, transparent 70%);
  }

  .mobile-cards {
    display: flex;
    flex-direction: column;
    align-items: center;
    /* Wide enough that the wobbly rings below (each bleeding out past its
       own circle) don't run into the card before/after it. */
    gap: 110px;
  }

  .work-card { display: block; position: relative; }

  /* Inner ring: a plain, static circle right against the photo -- matching
     the reference image's clean double ring, no wobble on this one. Outer
     ring: a real inline <svg><path> (built and rewritten every frame in
     js/works.js's animateRings), so the wave actually travels around the
     ring -- the same noise-driven wobble the constellation's connection
     lines get on desktop hover, not just a fixed wobbly shape spinning as a
     rigid whole. That's why this one needs JS driving it frame by frame
     instead of a CSS animation: animating an SVG path's own shape has no
     plain-CSS equivalent. */
  .work-card-ring {
    position: absolute;
    pointer-events: none;
  }
  .work-card-ring-inner {
    inset: 0;
    border-radius: 50%;
    border: 4px solid rgba(var(--neon-rgb), 0.55);
  }
  .work-card-ring-outer {
    /* top/left only -- deliberately NOT the `inset` shorthand (which would
       also set right/bottom) together with an explicit width/height below.
       Setting all four offsets AND width/height is over-constrained: per
       spec the browser then has to drop right/bottom and re-derive them
       from top/left/width/height, which anchors the box at top-left
       instead of centering it -- exactly the "outer ring is offset from
       the circle" bug this used to have on real devices. Declaring only
       top/left leaves right/bottom auto, so there's nothing to conflict
       with the explicit size and the box comes out symmetric: 140% width/
       height (1.4x the circle, matching RING_MIN_R/RING_MAX_R's local
       0..300 units in works.js) positioned -20%/-20%, bleeding out evenly
       on every side. The explicit width/height itself is still needed --
       an SVG is a replaced element with no intrinsic size of its own, and
       relying on the browser to derive its box purely from top/left/right/
       bottom percentages is exactly the kind of sizing calculation WebKit
       has been inconsistent about across iOS versions (affects Chrome on
       iOS too, since it's WebKit under the hood there as well). */
    top: -20%;
    left: -20%;
    width: 140%;
    height: 140%;
    display: block;
    overflow: visible;
  }

  /* Same circular-crop idea as the constellation's nodes, just static and
     centered instead of floating/hover-driven -- the photo fills the circle
     (fx/fy positions it, same focal-point fields the desktop nodes use) and
     the title sits directly on top of it, centered. */
  .work-card-circle {
    position: relative;
    width: min(62vw, 260px);
    /* height mirrors width explicitly, not just `aspect-ratio: 1/1` alone --
       this element is also a flex container (for centering the title), and
       aspect-ratio-derived sizing on a flex container is one of the more
       fragile corners of CSS across WebKit versions. Setting height too
       means the circle keeps its size even on an engine that mishandles
       aspect-ratio here, instead of collapsing/stretching to fit content. */
    height: min(62vw, 260px);
    aspect-ratio: 1 / 1;
    border-radius: 50%;
    overflow: hidden;
    background-size: cover;
    background-repeat: no-repeat;
    /* Thin and dim -- just a clean edge for the photo's own crop. The
       visible, organic double ring lives on .work-card::before instead,
       see below. */
    border: 0.5px solid rgba(var(--neon-rgb), 0.3);
    display: flex;
    align-items: center;
    justify-content: center;
  }
  /* Darkens toward the edges (not a flat tint) so the centered title stays
     legible regardless of where a given photo is naturally light or dark,
     without flattening the whole image. */
  .work-card-circle::after {
    content: '';
    position: absolute;
    inset: 0;
    background: radial-gradient(circle, rgba(0,0,0,0.1) 0%, rgba(0,0,0,0.6) 100%);
  }

  .work-card-title {
    position: relative;
    z-index: 1;
    color: #fff;
    font-size: 18px;
    font-style: italic;
    font-weight: 350;
    text-align: center;
    line-height: 1.3;
    padding: 0 20px;
    text-shadow: 0 1px 8px rgba(0,0,0,0.6);
  }
}