fix(website): bridge the dead zone between a nav trigger and its panel

The desktop nav's panel shell hung off `top: 100%` of the nav row, so the
row's own `py-4 md:py-5` padding sat between the trigger's bottom edge and
the panel's top edge belonging to neither element. Crossing it fired
mouseleave on .nav-desktop and scheduled a close; only arriving at the panel
could cancel it. A traverse slower than the 150ms grace therefore dismissed
the panel mid-move and left the pointer over empty space with nothing left
to fire mouseenter on — the panel was gone and did not come back. That is a
real defect for anyone moving their mouse deliberately, and it turned main
red: nav-panels.spec.ts failed all three attempts on CI while passing on
faster local hardware.

The fix removes the gap rather than lengthening the timeout. A longer grace
would only move the threshold and stay broken for a slower movement. Instead
.nav-panel-shell starts its box at the trigger row's bottom edge and pays the
difference back as transparent top padding, so the band is part of the shell
and mouseenter fires the instant the pointer leaves the trigger. The visible
.nav-panel does not move: measured at y=80 on marketing and y=57 on docs both
before and after. The new --nav-row-pad tracks the row's real padding (16px,
20px from md, and a flat 16px inside docs, which flattens the step).

.nav-desktop also gains `align-self: stretch`. The row is items-center, so on
docs — where the 25px logo sets the content height — that box floated 2.5px
above where the bridge begins, leaving a smaller copy of the same dead zone.
Stretching pins the two hit areas together and moves nothing, since the links
stay centred by the element's own items-center.

The test now crosses the band deliberately slowly — three stops of 120ms,
past CLOSE_DELAY_MS — so it asserts the bridge rather than the speed of the
machine it runs on. Verified by reverting the CSS: the strengthened test
fails against the old geometry and passes against the new.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: blove

apps/website/e2e/nav-panels.spec.ts

@@ -102,13 +102,43 @@ test.describe('desktop nav panels', () => {
     );
     await expect(page.locator('.nav-panel')).toBeVisible({ timeout: 2000 });
 
-    // The dead zone between the trigger row and the panel belongs to neither
-    // element; crossing it schedules a close that entering the panel must cancel.
+    // Read the resting geometry: the entrance animation translates the panel
+    // by 4px, so an un-settled box would move the waypoints below.
+    await page.locator('.nav-panel').evaluate((el) =>
+      Promise.all(el.getAnimations().map((animation) => animation.finished)),
+    );
+    const rowBox = await page.locator('.nav-desktop').boundingBox();
+    const panelBox = await page.locator('.nav-panel').boundingBox();
     const itemBox = await page
       .locator('.nav-panel .nav-panel-item')
       .first()
       .boundingBox();
-    if (!itemBox) throw new Error('Panel item has no box');
+    if (!rowBox || !panelBox || !itemBox)
+      throw new Error('Nav geometry has no box');
+
+    // The band between the trigger row's bottom edge and the panel's top edge
+    // is the row's own `py-4 md:py-5` padding. It is real space the pointer
+    // has to cross, and it used to belong to neither element: leaving the row
+    // scheduled a close, and only arriving at the panel could cancel it.
+    const gapTop = rowBox.y + rowBox.height;
+    const gapBottom = panelBox.y;
+    expect(gapBottom).toBeGreaterThan(gapTop);
+
+    // Cross that band DELIBERATELY SLOWLY — three stops of 120ms, ~360ms in
+    // total, comfortably past NavDesktop's CLOSE_DELAY_MS of 150ms. A quick
+    // traverse merely outruns the close timer, so it passes on fast hardware
+    // whether or not the gap is bridged (that is how this shipped red on CI
+    // and green locally). Dwelling longer than the grace asserts the thing
+    // that actually keeps the panel open: .nav-panel-shell's transparent
+    // top padding makes the band part of the shell, so the pointer never
+    // leaves the panel's own subtree and no close is ever scheduled.
+    const x = triggerBox.x + triggerBox.width / 2;
+    for (const y of [gapTop + 1, (gapTop + gapBottom) / 2, gapBottom - 1]) {
+      await page.mouse.move(x, y, { steps: 5 });
+      await page.waitForTimeout(120);
+    }
+    await expect(page.locator('.nav-panel')).toBeVisible();
+
     await page.mouse.move(
       itemBox.x + itemBox.width / 2,
       itemBox.y + itemBox.height / 2,

apps/website/src/styles/chrome.css

@@ -25,13 +25,22 @@
  * the docs column, and the mobile drawer (top: nav-h - 1px) hung 14px below the
  * nav it is supposed to be attached to. These are measured, not derived, so
  * only a real browser can hold them honest: e2e/nav-height.spec.ts asserts
- * nav.height === --nav-h at each of the three steps. */
+ * nav.height === --nav-h at each of the three steps.
+ *
+ * --nav-row-pad is that same row's block padding on its own — the `py-4
+ * md:py-5` half of `px-6 py-4 md:px-8 md:py-5`. It has only TWO steps, not
+ * three: padding grows at md and never again, so the lg entry below is
+ * deliberately absent and 20px carries through. .nav-panel-shell reads it to
+ * bridge the gap between a trigger and its panel (see the note there), so a
+ * wrong value here is a dead zone, not a cosmetic drift. */
 :root {
   --nav-h: 58px;
+  --nav-row-pad: 16px;
 }
 @media (min-width: 768px) {
   :root {
     --nav-h: 66px;
+    --nav-row-pad: 20px;
   }
 }
 @media (min-width: 1024px) {
@@ -52,6 +61,12 @@
  * marketing bar. */
 :root:has(.nav-bar[data-route='docs']) {
   --nav-h: 58px;
+  /* Docs pins the row's padding to a flat 16px at every width (see the
+   * `.nav-bar[data-route='docs'] > div` rule below), so the bridge has to
+   * shrink with it. Left at the marketing 20px the shell would start 4px
+   * ABOVE the trigger row's bottom edge and lie over the triggers, swallowing
+   * the mouseenter that switches from one panel to the next. */
+  --nav-row-pad: 16px;
 }
 
 /* Footer */
@@ -399,7 +414,15 @@
 }
 .nav-panel-shell {
   position: absolute;
-  top: 100%;
+  /* Hit area starts at the trigger's bottom edge, not the row's. The row's
+   * py-4/md:py-5 padding used to sit between trigger and panel belonging to
+   * neither, so a traverse slower than CLOSE_DELAY_MS closed the panel and
+   * left the pointer over nothing that could reopen it. The padding below is
+   * a transparent bridge: it makes the gap part of the shell, so mouseenter
+   * fires the instant the pointer leaves the trigger. The visible .nav-panel
+   * does not move. e2e/nav-panels.spec.ts drives this with a stepped move. */
+  top: calc(100% - var(--nav-row-pad));
+  padding-top: var(--nav-row-pad);
   left: 0;
   right: 0;
   z-index: 60;
@@ -513,6 +536,18 @@
  * here — keeping .nav-panel-shell's containing block on .nav-bar > div below. */
 .nav-desktop {
   position: static;
+  /* The row is `items-center`, so this box would otherwise shrink to its own
+   * tallest child and float in the middle of the row's content. On docs that
+   * left 2.5px between its bottom edge and where .nav-panel-shell's bridge
+   * starts — a second, smaller version of the dead zone the bridge exists to
+   * close, since the row's content height there is set by the 25px logo, not
+   * by these 20px links. Stretching pins the bottom edge to the content box
+   * so the two hit areas meet exactly. Children stay centred by this
+   * element's own `items-center`, so nothing moves: measured on /docs, the
+   * panel still rests at y=57 and the bar still measures 58px. On marketing
+   * the 40px CTA already made this box the full content height, so there
+   * stretching is a no-op. */
+  align-self: stretch;
 }
 .nav-bar > div {
   position: relative;