/* ============================================================================
   THE PROJECT NAVBAR — one bar, three sub-pages
   ----------------------------------------------------------------------------
   Amanda: "the recruiters struggled to find the brand design, they need to do
   some extra clicks and scrolls to find it." So the three views of a project --
   the web design preview, the brand design, and the case study -- stop being a
   scroll gesture and become three tabs that are always on screen.

   THE BAR IS FIXED AND ALWAYS VISIBLE. It never hides on scroll. The host page
   makes room for it by reading --pf-nav-h, which is why that one custom
   property is declared on :root and every other token here is not: five
   hand-built pages each own their own meaning of --nav-h, --bg and --line, and
   css/pf-chrome.css's header explains what happens when a shared file forgets
   that. --pf-nav-h is new, prefixed, and used by no page for anything else.

   THE HAMBURGER LIVES HERE NOW. Amanda: "we don't use the floating hamburger
   anymore. Instead, that will be placed on the new navbar as well." The markup
   and js/pf-chrome.js are untouched; the overrides at the bottom of this file
   take .pf-dock out of the viewport corner and sit it in the bar. That includes
   un-hiding it under 760px, where pf-chrome.css hides it -- the reason it hid
   (two hamburgers in the same floating corner) does not apply to a burger that
   is inside a bar.

   Load AFTER css/pf-chrome.css. The dock overrides below win on specificity
   (.pf-projnav .pf-dock is 0-2-0 against 0-1-0) but the type tokens they
   inherit are declared there.
   ========================================================================== */

:root {
  --pf-nav-h: 64px;
}
@media (max-width: 760px) {
  :root { --pf-nav-h: 52px; }
}

.pf-projnav,
.pf-projnav *,
.pf-projnav *::before,
.pf-projnav *::after {
  box-sizing: border-box;
}

/* ---- the bar --------------------------------------------------------------
   z-index 9500 sits above pf-chrome's dock (9000) and every host page's own
   header (identity's is 60, the master header's is 100). */
.pf-projnav {
  position: fixed;
  top: 0;
  left: 0;
  right: 0;
  z-index: 9500;
  height: var(--pf-nav-h);
  margin: 0;
  padding: 0;
  background: #FFFFFF;
  border-bottom: 1px solid rgba(17, 17, 17, 0.10);
  font-family: "Figtree", system-ui, -apple-system, "Segoe UI", sans-serif;
  color: #111111;
  line-height: 1.2;
  letter-spacing: -0.01em;
  -webkit-font-smoothing: antialiased;
}

/* The bar is out of flow, so the page has to be pushed down by hand. On the
   panel wrapper rather than on body: body carries the host page's own
   background and several of these pages animate it. */
.pf-panels { padding-top: var(--pf-nav-h); }

/* Three columns, not space-between: the tab group has to be centred on the
   VIEWPORT, and space-between would centre it between the name and the dock --
   which are different widths, so it would sit off-centre. Measured on
   "New project nav - Website.png": the tab group spans 493-1087 of 1580, whose
   midpoint is 790. The viewport midpoint is 790. */
.pf-projnav__inner {
  height: 100%;
  display: grid;
  grid-template-columns: 1fr auto 1fr;
  align-items: center;
  gap: 16px;
  padding-inline: clamp(16px, 1.8vw, 28px);
}

.pf-projnav__name {
  justify-self: start;
  font-size: 20px;
  font-weight: 700;
  letter-spacing: -0.03em;
  white-space: nowrap;
  color: inherit;
  text-decoration: none;
}
.pf-projnav__name:hover { opacity: 0.62; }
.pf-projnav__name:focus-visible { outline: 2px solid #111111; outline-offset: 3px; }

/* ---- the tabs -------------------------------------------------------------
   Sketch-calibrated at first: the active pill measures 242 x 57 in the sketch
   and the gap between two inactive labels measures ~72px there, which is what
   the original 18px text + 32px padding either side + 8px gap reproduced.
   Amanda then reviewed the built bar on localhost and asked for it stepped
   down -- "the new top navbar height should be reduced, right now it feels
   too large" -- so the numbers below (16px text, 26px padding, 6px gap) are
   deliberately smaller than the sketch measurement, not a drift from it. Do
   not "restore" the sketch values from this comment; they describe the
   sketch, not the target. */
.pf-projnav__tabs {
  justify-self: center;
  display: flex;
  align-items: center;
  gap: 6px;
}

.pf-projnav__tab {
  appearance: none;
  -webkit-appearance: none;
  display: inline-flex;
  align-items: center;
  height: 44px;
  margin: 0;
  padding-inline: 26px;
  border: 0;
  border-radius: 999px;
  background: transparent;
  color: #111111;
  font: inherit;
  font-size: 16px;
  font-weight: 500;
  letter-spacing: -0.02em;
  white-space: nowrap;
  cursor: pointer;
  transition: background 0.3s cubic-bezier(0.22, 0.61, 0.36, 1),
              color 0.3s cubic-bezier(0.22, 0.61, 0.36, 1),
              opacity 0.3s cubic-bezier(0.22, 0.61, 0.36, 1);
}
.pf-projnav__tab:hover { opacity: 0.6; }
.pf-projnav__tab:focus-visible { outline: 2px solid #111111; outline-offset: 2px; }

.pf-projnav__tab[aria-selected="true"] {
  background: #111111;
  color: #FFFFFF;
  opacity: 1;
}

/* ---- the reading-progress bar --------------------------------------------
   Same 3px black bar, same scaleX(0) rest state and same left origin as
   .cs-progress on the case study pages and #tbar on the hazen page. Amanda
   asked for "the progress bar underneath the nav bar just like the case study
   pages and the hazen page", so it is that bar, not a new one. It is not
   .cs-progress itself because that class lives in css/case-study.css, which
   carries a global reset these pages must not load. */
.pf-projnav__progress {
  position: absolute;
  left: 0;
  right: 0;
  bottom: -1px;
  height: 3px;
  z-index: 1;
  pointer-events: none;
}
.pf-projnav__bar {
  display: block;
  height: 100%;
  width: 100%;
  background: #111111;
  transform: scaleX(0);
  transform-origin: left;
  will-change: transform;
}

/* ---- the dock, relocated --------------------------------------------------
   Every declaration here undoes one from css/pf-chrome.css. The menu becomes
   absolutely positioned against the bar rather than stacking under a floating
   button, so it hangs below the bar's bottom edge. */
.pf-projnav .pf-dock {
  position: static;
  justify-self: end;
  display: block;
  z-index: auto;
}
.pf-projnav .pf-dock__btn {
  width: 44px;
  height: 44px;
  border: 0;
  border-radius: 0;
  background: transparent;
  box-shadow: none;
}
.pf-projnav .pf-dock__btn:hover { transform: none; box-shadow: none; opacity: 0.6; }
.pf-projnav .pf-dock__bars { width: 26px; height: 13px; }
.pf-projnav .pf-dock__bars i { height: 2px; }
.pf-projnav .pf-dock__bars i:nth-child(1) { top: 0; }
.pf-projnav .pf-dock__bars i:nth-child(2) { top: 5.5px; }
.pf-projnav .pf-dock__bars i:nth-child(3) { top: 11px; }
.pf-projnav .pf-dock.is-open .pf-dock__bars i:nth-child(1) { transform: translateY(5.5px) rotate(45deg); }
.pf-projnav .pf-dock.is-open .pf-dock__bars i:nth-child(3) { transform: translateY(-5.5px) rotate(-45deg); }
.pf-projnav .pf-dock__menu {
  position: absolute;
  top: calc(var(--pf-nav-h) + 8px);
  right: clamp(16px, 1.8vw, 28px);
}

/* pf-chrome.css hides the dock under 760px. In the bar it stays -- see the
   header. This override must repeat the breakpoint, not just raise
   specificity, because the rule it beats is itself inside a media query. */
@media (max-width: 760px) {
  .pf-projnav .pf-dock { display: block; }
  .pf-projnav__name { display: none; }
  .pf-projnav__inner { grid-template-columns: minmax(0, 1fr) auto; gap: 6px; padding-inline: 10px; }

  /* THE minmax(0, 1fr) ABOVE IS LOAD-BEARING, and the plain `1fr` it replaces
     was a real bug. A grid item's min-width defaults to auto, which refuses to
     shrink below its content -- so at 375px the three tabs did not compress,
     they shoved the 44px hamburger 34px past the right edge, clipped and
     unreachable. Nothing reported it: the bar is position: fixed, so it never
     widened the document and scrollWidth stayed equal to clientWidth. Measure
     the button's own getBoundingClientRect().right against innerWidth; an
     overflow check on the document cannot see this.

     overflow-x is the safety valve for viewports too narrow to hold three
     legible tabs at all (320px cannot). At 375px the sizes below leave ~12px
     spare, so it never engages there. Amanda picked "drop the name, keep 3
     tabs + hamburger" over a scrolling tab row, and this keeps that true
     everywhere it is physically possible. */
  .pf-projnav__tabs {
    justify-self: stretch;
    /* `safe` is load-bearing. A plain `center` that overflows puts half the
       overflow on the LEADING side, and scrollLeft clamps at 0 -- so the
       first tab's left edge goes unreachable (21px lost at 320px) with
       scrollbar-width:none removing any hint that it happened. `safe` falls
       back to flex-start the moment the track overflows. */
    justify-content: safe center;
    min-width: 0;
    overflow-x: auto;
    scrollbar-width: none;
    -ms-overflow-style: none;
    gap: 2px;
  }
  .pf-projnav__tabs::-webkit-scrollbar { display: none; }

  /* flex: none keeps a tab's label from being squeezed. The dock needs no
     equivalent and must not be given one: .pf-projnav__inner is display:grid
     at every breakpoint, so .pf-dock is a GRID item and flex:none on it is
     inert. What actually protects the dock is its `auto` track above, which
     is sized to content before the minmax(0, 1fr) track gets anything. */
  .pf-projnav__tab { height: 38px; padding-inline: 8px; font-size: 12.5px; flex: none; }
  .pf-projnav .pf-dock__menu { right: 10px; top: calc(var(--pf-nav-h) + 6px); }
}

/* The loaders must not punch a hole in the bar.
   css/pf-chrome.css hides the dock while a page is still loading --
   html[data-motion="pending"] on kayn, body.is-loading on nobi. That is right
   for a dock floating loose over a page mid-intro, and wrong for one that is
   the third cell of a bar: the bar itself stays painted, so hiding only the
   hamburger leaves a gap where a control should be.

   Both of those selectors compute 0-2-1, which beats a plain
   `.pf-projnav .pf-dock` at 0-2-0 -- so this has to restate the ancestor
   condition rather than just naming the dock again. */
html[data-motion="pending"] .pf-projnav .pf-dock,
body.is-loading .pf-projnav .pf-dock {
  opacity: 1;
  pointer-events: auto;
}

/* ---- the panels -----------------------------------------------------------
   Exactly one is in the flow at a time. Not a horizontal track: identity's
   deck and gradient both read window.scrollY and documentElement.scrollHeight,
   and neither works inside an overflow container. So the sub-pages take turns
   being the document, and the left/right push is supplied by the view
   transition in js/pf-projectnav.js rather than by moving these boxes.

   NOTHING HERE MAY SET transform, filter, perspective, backdrop-filter OR
   contain. Each of those makes the panel a containing block for its fixed
   descendants, and .gradient-field and .nav inside the web panel are both
   position: fixed. That is also why the push is done with pseudo-elements. */
.pf-panel {
  position: relative;
  display: block;
  margin: 0;
  padding: 0;
}
/* The attribute alone is not enough: identity's reset does not restate the UA
   default, and a host page's `display` rule on a descendant selector would
   win over it. */
.pf-panel[hidden] { display: none; }

/* ============================================================================
   THE PUSH
   ----------------------------------------------------------------------------
   Amanda: "There should also be a pushing left and right transition when
   switching between sub pages." Forward through the tabs, the outgoing
   sub-page is pushed off to the left and the new one arrives from the right;
   backward, the reverse.

   Drawn by the View Transitions API over a snapshot the browser takes for us,
   so no real element moves and nothing here can become a containing block for
   the fixed .gradient-field and .nav inside the web panel.

   ::view-transition-group(root) is everything WITHOUT a view-transition-name,
   and the root snapshot is viewport-sized however tall the page is -- so this
   costs one screen-sized capture per switch.

   THE BAR DOES NOT MOVE. It is named, which lifts it out of the root group,
   and its group's animation is switched off so the new state (a different pill
   lit, the bar reset to 0) simply appears. Amanda: the navbar "should be always
   on top and always visible", and a bar that slid out with the page would not
   be.

   js/pf-projectnav.js falls back to an instant swap when
   document.startViewTransition is missing, so nothing here needs a fallback of
   its own. Reduced motion is handled there too, for the same reason.
   ========================================================================== */

.pf-projnav { view-transition-name: pf-projnav; }

::view-transition-group(pf-projnav) { animation: none; }

@keyframes pf-slide-out-left  { to   { transform: translateX(-100%); } }
@keyframes pf-slide-in-right  { from { transform: translateX(100%); } }
@keyframes pf-slide-out-right { to   { transform: translateX(100%); } }
@keyframes pf-slide-in-left   { from { transform: translateX(-100%); } }

/* Both snapshots animate at once and neither fades: a cross-fade under a
   translate reads as a dissolve, not a push. The default root animation IS a
   cross-fade, which is why every one of these sets its own. */
html[data-pf-slide]::view-transition-old(root),
html[data-pf-slide]::view-transition-new(root) {
  animation-duration: 0.52s;
  animation-timing-function: cubic-bezier(0.22, 0.61, 0.36, 1);
  animation-fill-mode: both;
  mix-blend-mode: normal;
}
html[data-pf-slide]::view-transition-old(root) { opacity: 1; }
html[data-pf-slide]::view-transition-new(root) { opacity: 1; }

html[data-pf-slide="forward"]::view-transition-old(root) { animation-name: pf-slide-out-left; }
html[data-pf-slide="forward"]::view-transition-new(root) { animation-name: pf-slide-in-right; }
html[data-pf-slide="back"]::view-transition-old(root)    { animation-name: pf-slide-out-right; }
html[data-pf-slide="back"]::view-transition-new(root)    { animation-name: pf-slide-in-left; }

/* NOTE, on the horizontal overflow a translate normally causes: it does not
   apply here. The ::view-transition tree is rendered in the top layer, against
   the snapshot containing block -- it is not a descendant of anything in the
   document and it contributes no scrollable overflow, so a snapshot sliding a
   full viewport to the right does not widen the page. There is deliberately no
   `overflow-x: hidden` guard for it: an untargeted one would clip the page's
   own content for the rest of the visit, and the obvious targeted form,
   `html:has(::view-transition)`, is not a valid selector -- :has() matches
   elements, never pseudo-elements. Task 5's verification measures scrollWidth
   DURING a switch precisely so this claim is checked rather than trusted. If
   it ever does overflow, the fix is `:root { overflow-x: clip; }` scoped to
   these project pages, not a global hidden. */