@cplieger/web-terminal-ui 5.3.0 → 5.4.0

package/README.md

@@ -425,4 +425,4 @@ This project was built with AI-assisted tooling using [Claude](https://claude.co
 
 ## License
 
-GPL-3.0-or-later. See [LICENSE](LICENSE).
+MPL-2.0. See [LICENSE](LICENSE).

package/css/00-tokens.css

@@ -144,27 +144,33 @@
   --font-mono: "Monaspace Neon NF", monospace;
   /* How far a chip label's INK sits below its line box's centre, so flex
      centring can be corrected by exactly that much (see .wt-tab-label in
-     30-tabs.css).
+     30-tabs.css). The band is the CAP band — cap top to baseline, the visible
+     mass of a label — not cap-to-descender, which reserves empty descender room
+     below the letters and reads high (measured: 1.32px above the chip's centre
+     at 13px, while the dot and close glyph beside it sat at 0.00px).
 
      This value is only the PRE-MEASUREMENT DEFAULT — what the first paint uses
      before the tabs feature replaces it, per site, with a pixel value measured
      in the live engine (src/features/tabs/ink-centre.ts). It is not the answer,
      because no single value can be: engines round the font's ascent and descent
      to whole CSS pixels before building the line box, so the ideal shift is a
-     sawtooth in font size rather than a ratio. Against the bundled font in
-     WebKit it is 0.1190em at 13px and 0.0915em at 14px, since 0.25em x 13 =
-     3.25 rounds to 3 (a 16px box) while 0.25em x 14 = 3.5 rounds to 4 (an 18px
-     box). Engines then disagree with each other (Firefox makes that 14px box
-     17px) and platforms disagree within one engine (iOS reads metrics through
-     CoreText, Linux WebKit through FreeType). Four fixes were hardcoded
-     constants and each was correct only where it was tuned.
+     sawtooth in font size rather than a ratio, and on the cap band it does not
+     even keep one sign. Measured against the bundled font it runs from about
+     -0.021em (Blink 151 at 13px, a 17px box) to +0.028em (Gecko at 14px, where
+     the box is 17px against Blink's 18px), and platforms disagree inside one
+     engine too (iOS reads metrics through CoreText, Linux WebKit through
+     FreeType) — which is why four hardcoded constants each held only where they
+     were tuned.
 
-     0.1147em is kept as the default because it is the midpoint of that
-     sawtooth: worst case 0.34px before the measurement lands, versus 1.5px for
-     no correction at all. Do not tune it by eye — a wrong default is invisible
-     the moment the measured value arrives, so eye-tuning it optimises nothing
-     and pins the wrong number in place. */
-  --label-ink-shift: 0.1147em;
+     ZERO is the default because the whole range is within ~0.03em of it: flex
+     centring of the font box is already within 0.4px of cap-band centring, so
+     the first paint starts uncorrected and the measurement lands within a frame.
+     That is also the best behaviour if the measurement never runs at all (no
+     canvas, a display:none probe): 0.4px out rather than the 1.3px a
+     descender-inclusive constant was. Do not tune it by eye — a wrong default is
+     invisible the moment the measured value arrives, so eye-tuning it optimises
+     nothing and pins the wrong number in place. */
+  --label-ink-shift: 0em;
   --dur-micro: 0.1s;
   --dur-standard: 0.2s;
   --dur-enter: 0.25s;

package/css/01-scope.css

@@ -15,6 +15,16 @@
 .wt-root.wt-viewport {
   position: fixed;
   inset: 0;
+  /* Clip like the container mode below, so the two layout modes agree. Inert
+     today: the root's box IS the viewport here and page.css already hides
+     document overflow, so nothing can currently paint outside it, and
+     position:fixed descendants escape a clip regardless. It exists so the
+     asymmetry cannot be mistaken for a deliberate difference, and so a future
+     transform on .term (see docs/tab-switch-repaint.md) is bounded by a
+     declaration rather than by the viewport happening to coincide with the box.
+     overflow:clip specifically, not hidden: no scroll container, no block
+     formatting context, nothing programmatically scrollable. */
+  overflow: clip;
 }
 
 .wt-root.wt-container {

package/css/02-terminal.css

@@ -45,6 +45,12 @@
   touch-action: pan-x pan-y;
   font-family: var(--font-mono);
   font-size: 14px;
+  /* The cell height. It is PAIRED with the bundled font's overridden vertical
+     metrics (page.css): a cell's background is painted by an inline span, whose
+     box comes from the font's ascent + descent, so those must stay >= this value
+     or every row boundary shows an unpainted stripe. Changing either number
+     alone reopens that gap. The engine reads this as its cell height
+     (render.ts updateFontMetrics) and sizes the PTY from it. */
   line-height: 17px;
   padding: 4px;
   background: var(--bg);

package/css/30-tabs.css

@@ -215,9 +215,16 @@
    the baseline than below it (the bundled font: 0.995em over, 0.250em under),
    while the ink of a mixed-case title runs ~0.734em over (cap height) to ~0.203em
    under (descender). Flex centring centres the BOX, which leaves the visible text
-   --label-ink-shift low — about 1.5px at this size — reading as baseline-aligned
-   with the activity dot's bottom edge instead of level with its centre. Two
-   declarations, one job, and a third that must NOT be added:
+   --label-ink-shift low — reading as baseline-aligned with the activity dot's
+   bottom edge instead of level with its centre. Two declarations, one job, and a
+   third that must NOT be added:
+
+   The band being centred is cap top to BASELINE. Descender ink is deliberately
+   outside it: including it reserves empty room below the letters, and the label
+   then reads HIGH — measured on this chip at 13px, the title's cap band sat
+   1.32px above the chip's centre while the dot and the close glyph beside it sat
+   at 0.00px. Same edges as `text-box-edge: cap alphabetic`. Descenders overhang
+   the band, which is what the padding below is for.
 
    - padding-block is the ink allowance, not spacing. `overflow: hidden` (which
      the ellipsis requires) clips at the padding box, and the line box clears the
@@ -227,6 +234,9 @@
    - margin-block hangs TWICE the shift below the box. Flex centring centres the
      MARGIN box, so a bottom-heavy margin lifts the border box by half of it --
      exactly one shift -- and unlike padding it does not enlarge the clipping box.
+     The shift can be NEGATIVE (a top-heavy margin, pushing the box down) at sizes
+     where the engine's rounding already overshoots; that is a normal outcome of
+     the measurement, not a sign the arithmetic is inverted.
    - line-height stays at `normal`, deliberately. Setting it looks like the
      responsible thing to do and it is the trap: `normal` is the ONE value whose
      half-leading is zero by definition, which is what makes the baseline sit at
@@ -240,16 +250,19 @@
    --label-ink-shift is MEASURED, not declared. The tabs feature writes a pixel
    value per site from the line box the running engine produced for this font at
    this size (src/features/tabs/ink-centre.ts); the em value in 00-tokens.css is
-   only what the first paint uses. Four earlier fixes were constants, and the
-   reason none held is that engines round the font's ascent and descent to whole
-   CSS pixels before laying out the line box, so the required shift is a sawtooth
-   in font size, not a ratio: in WebKit 0.1190em at 13px against 0.0915em at 14px,
-   because 0.25em x 13 = 3.25 rounds to 3 (a 16px box) while 0.25em x 14 = 3.5
-   rounds to 4 (an 18px box). The three engines also report slightly different ink
-   extents for one font file (cap 0.7344 / 0.7350 / 0.7300em in WebKit, Blink and
-   Gecko), Firefox makes that 14px box 17px rather than 18px, and iOS resolves
-   metrics through CoreText where Linux WebKit uses FreeType — which is why the
-   13px strip measured centred in every local check and still read high on an
+   only what the first paint uses, and it is 0 because the cap-band correction is
+   within 0.4px of nothing on every engine measured. Four earlier fixes were
+   constants, and the reason none held is that engines round the font's ascent and
+   descent to whole CSS pixels before laying out the line box, so the required
+   shift is a sawtooth in font size, not a ratio: on the cap band it runs from
+   about -0.021em (Blink 151 at 13px, a 17px box) to +0.0279em (Gecko at 14px,
+   where the box is 17px against Blink's 18px), changing sign along the way,
+   because 0.25em x 13 = 3.25 and 0.25em x 14 = 3.5 round to different whole
+   pixels. The three engines
+   also report slightly different ink extents for one font file (cap 0.7344 /
+   0.7350 / 0.7300em in WebKit, Blink and Gecko), and iOS resolves metrics through
+   CoreText where Linux WebKit uses FreeType — which is why the 13px strip
+   measured centred in every local check and still read high on an
    iPad. Nothing here is tunable by eye; if the centring looks wrong, run
    scripts/verify-chip-geometry.mjs and fix what it measures.
 
@@ -482,9 +495,81 @@
   }
 }
 
-/* The tab being dragged (reorder) dims while it moves. */
-:where(.wt-root) .wt-tab-dragging {
-  opacity: 0.5;
+/* ===== Pending drop edge (tabs feature, desktop drag) =====
+   The exact boundary the dragged tab will be inserted at, marked while the hold runs
+   and filling from nothing to full over the hold's own duration (the tabs feature
+   sets the duration inline from REORDER_DWELL_MS, so the bar and the timer cannot
+   drift apart).
+
+   It rides the neighbouring chip: the leading edge of the chip being pushed aside,
+   or the trailing edge of the last chip when the tab is heading past the end of the
+   strip (.wt-tab-dwell-end). The chip is already position: relative for its progress
+   bar, and its overflow clip keeps the rail inside the same rounded padding box.
+
+   3px of solid accent rather than a dashed treatment: the dashed vocabulary belongs
+   to the SLOT, which is a destination that has been decided. This is a boundary
+   still being chosen, so it reads as a caret. inset-block keeps it clear of the
+   chip's rounded corners without needing its own radius arithmetic. */
+:where(.wt-root) .wt-tab-dwell {
+  position: absolute;
+  inset-block: var(--sp-1);
+  inset-inline-start: 0;
+  width: 3px;
+  border-radius: var(--radius-sm);
+  background: var(--accent);
+  /* Grows upward like a gauge. The feature writes scaleY inline; a transform on this
+     element cannot collide with the chip's own animations because it is a separate
+     element, which is the whole reason the rail is not a pseudo-element on the chip. */
+  transform-origin: bottom;
+  pointer-events: none;
+}
+
+:where(.wt-root) .wt-tab-dwell-end {
+  inset-inline: auto 0;
+}
+
+/* ===== Reorder drop slot (tabs feature, desktop drag) =====
+   The dragged chip stays in the strip's flow for the whole gesture and renders as
+   the SLOT it will land in: an empty dashed outline in the accent over a faint
+   accent wash. It used to be a dimmed copy of the tab, and with a solid drag
+   image already following the pointer that put three tab-shaped things on screen
+   at once — the slot it left, the chip it hovered, and the copy under the
+   pointer — none of which read as the answer to "where will this land". One
+   solid thing under the pointer, one hollow thing where it will land.
+
+   Staying in the flow is what keeps the geometry honest: the slot IS the gap,
+   exactly one chip wide, so nothing has to synthesise a placeholder box or agree
+   with the chip about how wide a tab is. It is also what lets the reorder animate
+   at all — the strip's other chips slide around a real box (index.ts, commitSlot).
+
+   The outline is the chip's OWN reserved border switched to `dashed`: every tab
+   carries a transparent 1px border for exactly this kind of toggle (see .wt-tab),
+   so the treatment costs no layout and lands on the same --radius-inner corners
+   as every other chip state.
+
+   Scoped through .wt-tab-scroll on purpose, and it is not decoration. A drag
+   reorder exists only inside the desktop scroller, and the extra compound is what
+   carries the rule past the two rungs it has to out-rank without any of the usual
+   tricks: the press rung (.wt-tab:not(.wt-tab-active):active, which a mousedown
+   that starts a drag leaves applied for the whole gesture in Blink, so the slot
+   would otherwise paint as a pressed tab under the dashes), and the per-status
+   dot rules far below, which would otherwise keep the status dot lit inside an
+   outline that is meant to be empty. */
+:where(.wt-root) .wt-tab-scroll .wt-tab.wt-tab-dragging {
+  background: color-mix(in oklch, var(--accent) 12%, transparent);
+  border-color: color-mix(in oklch, var(--accent) 60%, transparent);
+  border-style: dashed;
+}
+
+/* Nothing inside the slot: the outline is the whole message, and the tab's
+   identity is already in the drag image under the pointer. Fading the CONTENT
+   rather than the chip is what keeps the dashes at full strength — an opacity on
+   the chip dimmed the outline along with everything else, which is exactly how
+   the old treatment ended up reading as a faded tab rather than as a gap. The dot
+   is included by inheritance: opacity multiplies onto its glow and ripple
+   pseudo-elements, so one declaration silences the whole dot. */
+:where(.wt-root) .wt-tab-scroll .wt-tab.wt-tab-dragging > * {
+  opacity: 0;
 }
 
 /* ===== Inline rename (tabs feature) =====

package/css/31-switcher.css

@@ -196,11 +196,12 @@
 
 /* Ink-centring geometry, identical to .wt-tab-label: a symmetric ink allowance
    the ellipsis clipping needs, plus a bottom margin of twice --label-ink-shift
-   that lifts the ink to the row centre. These labels are 14px against the strip's
+   that lifts the CAP band (cap top to baseline, never cap-to-descender) to the row
+   centre. These labels are 14px against the strip's
    13px, which is exactly why --label-ink-shift is MEASURED per site at runtime
    (src/features/tabs/ink-centre.ts) rather than declared once: the shift an engine
-   needs is a sawtooth in font size, not a ratio, so the single em constant that
-   served both sizes was correct at 13px and 0.33px high here. See 30-tabs.css for
+   needs is a sawtooth in font size, not a ratio — it does not even keep one sign
+   across the two sizes. See 30-tabs.css for
    the full derivation, for why line-height must stay `normal`, and for why a
    measured shift beats a text-box trim behind an @supports gate. */
 :where(.wt-root) .wt-switcher-label {
@@ -471,11 +472,12 @@
 
 /* Ink-centring geometry, identical to .wt-tab-label: a symmetric ink allowance
    the ellipsis clipping needs, plus a bottom margin of twice --label-ink-shift
-   that lifts the ink to the row centre. These labels are 14px against the strip's
+   that lifts the CAP band (cap top to baseline, never cap-to-descender) to the row
+   centre. These labels are 14px against the strip's
    13px, which is exactly why --label-ink-shift is MEASURED per site at runtime
    (src/features/tabs/ink-centre.ts) rather than declared once: the shift an engine
-   needs is a sawtooth in font size, not a ratio, so the single em constant that
-   served both sizes was correct at 13px and 0.33px high here. See 30-tabs.css for
+   needs is a sawtooth in font size, not a ratio — it does not even keep one sign
+   across the two sizes. See 30-tabs.css for
    the full derivation, for why line-height must stay `normal`, and for why a
    measured shift beats a text-box trim behind an @supports gate. */
 :where(.wt-root) .wt-switcher-row-label {

package/css/40-animations.css

@@ -27,15 +27,48 @@
     display var(--dur-standard) allow-discrete;
 }
 
-/* Tab chrome micro-transitions (hover/active color shifts). */
+/* Tab chrome micro-transitions (hover/active colour shifts, and a chip's hand-off
+   into the reorder drop slot). border-color rides along because the slot IS a
+   border-colour change plus a dashed style (30-tabs.css): without it the chip
+   snapped from tab to outline in a single frame, which is the same instant
+   rearrangement the reorder preview exists to remove. The dash pattern itself still
+   appears at once — border-style does not interpolate — so the slot reads as an
+   outline drawing itself in rather than as a tab bleaching out. */
 :where(.wt-root.wt-animate) .wt-tab,
 :where(.wt-root.wt-animate) .wt-tab-close,
 :where(.wt-root.wt-animate) .wt-tab-new {
   transition:
     background-color var(--dur-micro) var(--ease-standard),
+    border-color var(--dur-micro) var(--ease-standard),
     color var(--dur-micro) var(--ease-standard);
 }
 
+/* The chip's content dissolves as it becomes the drop slot, and comes back when the
+   drag ends (30-tabs.css fades every child to nothing). One rule on the children,
+   not four per-part rules: the label, the status dot, the progress bar and the close
+   all leave together, because they leave for one reason. */
+:where(.wt-root.wt-animate) .wt-tab > * {
+  transition: opacity var(--dur-micro) var(--ease-standard);
+}
+
+/* The drop slot fades in at each position the reorder preview commits it to
+   (index.ts, flashSlot). The chips it displaces SLIDE there — a JS FLIP, because the
+   distance is only known at commit time — while the slot itself deliberately does
+   not travel: a hole crossing the strip alongside the solid drag image the pointer
+   is already carrying is two things moving at once, which is what made the old
+   instant reorder unreadable. It appears where the strip has just opened, which is
+   the frame that says the reorder took. */
+:where(.wt-root.wt-animate) .wt-tab-slotted {
+  animation: wt-slot-in var(--dur-enter) var(--ease-enter);
+}
+
+@keyframes wt-slot-in {
+  from {
+    opacity: 0;
+    transform: scale(0.97);
+  }
+}
+
 /* New tab enters with a fade + scale-in. Only runtime-added tabs get
    .wt-tab-enter (the tabs feature's `started` gate). A closing tab is removed
    immediately with no exit animation, so the strip reflows in one frame (a

package/css/page.css

@@ -215,13 +215,44 @@ body {
    different typeface per engine (see --label-ink-shift in 00-tokens.css). An
    embedder does not serve these files and never inherits these URLs, so it
    either ships its own @font-face or lets both tokens fall back to the platform
-   monospace stack. */
+   monospace stack.
+
+   EVERY face overrides the font's vertical metrics to 0.995em over the baseline
+   and 0.250em under, and that is load-bearing for the terminal, not taste.
+
+   A cell's background is painted by an inline span, and an inline box paints its
+   FONT's content area, never the line box: at `font-size: 14px` with
+   `line-height: 17px` (02-terminal.css) a font whose ascent + descent is under
+   17px leaves an unpainted stripe between consecutive rows, so an application
+   drawing a solid column of background (kiro-cli's green and purple block
+   gutters) renders as dashes. GitHub's own Monaspace webfont declares
+   ascent 1890/2000 and descent 400/2000 with USE_TYPO_METRICS set, which is
+   0.945em + 0.200em = 16.03px at 14px, and Chromium rounds that to a 16px box
+   inside a 17px row: a 1px gap on every row boundary, measured in the sidecar.
+
+   0.995em + 0.250em is what the nerd-fonts-patched MonaspiceNe NFM OTFs carried
+   until 5.3.0 swapped them for these WOFF2 files (the swap was gated on
+   horizontal advances only, which is how the regression shipped). It rounds to
+   an 18px box, so a row's background overhangs its box by 1px and consecutive
+   rows meet with no seam — and the baseline does not move (13px from the row's
+   top edge, before and after), so no glyph shifts by restoring it. It is also
+   the metric pair the rest of this package is already tuned and documented
+   against: --label-ink-shift's sawtooth and ink-centre.ts both derive from
+   0.995em / 0.250em by name.
+
+   Do not "modernise" these away, and do not close the gap by lowering
+   `line-height` instead: that shrinks the cell, so it changes how many rows fit
+   a viewport and what the engine reports to the PTY. If a Monaspace bump ever
+   changes the outlines enough that a 0.995em ascent clips them, re-measure both
+   halves together — the terminal needs ascent + descent >= the cell height. */
 @font-face {
   font-family: "Monaspace Neon NF";
   src: url("/vendor/fonts/MonaspaceNeonNF-Regular.woff2") format("woff2");
   font-weight: 400;
   font-style: normal;
   font-display: block;
+  ascent-override: 99.5%;
+  descent-override: 25%;
 }
 
 @font-face {
@@ -230,6 +261,8 @@ body {
   font-weight: 700;
   font-style: normal;
   font-display: block;
+  ascent-override: 99.5%;
+  descent-override: 25%;
 }
 
 @font-face {
@@ -238,6 +271,8 @@ body {
   font-weight: 400;
   font-style: italic;
   font-display: block;
+  ascent-override: 99.5%;
+  descent-override: 25%;
 }
 
 @font-face {
@@ -246,4 +281,6 @@ body {
   font-weight: 700;
   font-style: italic;
   font-display: block;
+  ascent-override: 99.5%;
+  descent-override: 25%;
 }

package/package.json

@@ -1,9 +1,9 @@
 {
   "name": "@cplieger/web-terminal-ui",
-  "version": "5.3.0",
+  "version": "5.4.0",
   "type": "module",
   "description": "Reference touch-first browser UI for @cplieger/web-terminal-engine: a composable kernel + feature modules (tabs, activity monitor, mobile toolbar, context menu, IME, predictive echo, viewport handling) and CSS. One createTerminal() call.",
-  "license": "GPL-3.0-or-later",
+  "license": "MPL-2.0",
   "exports": {
     ".": "./src/index.ts",
     "./startup-copy": "./src/kernel/startup-copy.ts",
@@ -40,7 +40,7 @@
     "verify": "bash scripts/verify.sh"
   },
   "peerDependencies": {
-    "@cplieger/web-terminal-engine": "^3.7.0"
+    "@cplieger/web-terminal-engine": "^3.10.0"
   },
   "overrides": {
     "qs": "^6.15.2"