@cplieger/web-terminal-ui 7.2.0 → 7.2.2

package/css/00-tokens.css

@@ -142,34 +142,10 @@
      rides on that fallback. */
   --font-ui: "Monaspace Neon NF", ui-monospace, monospace;
   --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). 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, 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.
-
-     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. */
+  /* Pre-measurement default for the chip labels' ink centring; the tabs feature
+     writes a measured px value per site (src/features/tabs/ink-centre.ts owns
+     why). Zero: flex centring already lands within 0.4px of the cap band, and is
+     the best answer when the measurement cannot run. Do not tune it by eye. */
   --label-ink-shift: 0em;
   --dur-micro: 0.1s;
   --dur-standard: 0.2s;

package/css/02-terminal.css

@@ -44,13 +44,13 @@
      (WebKit bug 240917), which the switcher-bar gesture relies on. */
   touch-action: pan-x pan-y;
   font-family: var(--font-mono);
+  /* Bold and italic are real faces (page.css); a synthesized stand-in must
+     never be drawn in their place. */
+  font-synthesis: none;
   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. */
+  /* The cell height. The engine reads it (render.ts updateFontMetrics) and sizes
+     the PTY from it. The row background owes it nothing: see the run padding
+     below. */
   line-height: 17px;
   padding: 4px;
   background: var(--bg);
@@ -82,6 +82,14 @@
   content: "\00a0";
 }
 
+/* The cell background is THIS padding, not the font: an inline run paints its
+   font's content area (16px of the 17px row), and shipping Safari has no
+   ascent-override to widen it (webkit.org/b/219735, fixed in trunk 2026-08). */
+:where(.wt-root) .term-row span,
+:where(.wt-root) .term-row a {
+  padding-block: 1px;
+}
+
 /* "earlier output trimmed" marker (vterm renderer inserts .term-trim-marker
    as the first row when history older than the buffer holds was evicted —
    client-side cap or a server-reported resume gap). A quiet, centered,
@@ -91,6 +99,7 @@
   font-size: 0.6875rem;
   text-align: center;
   padding: 2px 0;
+  -webkit-user-select: none;
   user-select: none;
   font-family: var(--font-ui);
 }
@@ -141,12 +150,12 @@
      explicitly and must never let an ancestor override them. `user-select`
      is spec'd as non-inherited but WebKit/Chromium treat it as inherited,
      so a stray `user-select: none` on html/body/.term would silently kill
-     selection here; keep it `text` (modern Safari honors the unprefixed
-     form, so no `-webkit-` pair is needed). `-webkit-touch-callout: default`
+     selection here; keep it `text`. `-webkit-touch-callout: default`
      keeps the iOS callout (a page-level `none` suppresses it) and has no
      standard equivalent. No JS may `preventDefault` a touch/pointer/
      contextmenu over this element or the native selection dies (see the
      kernel focus handling + contextMenu feature). */
+  -webkit-user-select: text;
   user-select: text;
   -webkit-touch-callout: default;
 

package/css/30-tabs.css

@@ -152,6 +152,7 @@
   font-size: 0.8125rem;
   cursor: pointer;
   white-space: nowrap;
+  -webkit-user-select: none;
   user-select: none;
   /* Kills the 300ms double-tap-to-zoom delay, which is what makes a double-TAP
      usable as the touch rename entry: on iPadOS a long-press on this chip starts
@@ -224,81 +225,22 @@
   background: color-mix(in oklch, var(--tab-active-bg), var(--tab-active-fg) 22%);
 }
 
-/* The label flexes to fill the fixed-width tab and truncates with an ellipsis
-   (min-width: 0 lets a flex item shrink below its content width), and it owns the
-   ink-centring geometry the two switcher labels in 31-switcher.css share verbatim.
-
-   Centre the INK, not the line box. A font's metrics box reaches far higher above
-   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 — 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
-     tallest ink by only 0.6px, so an unpadded label shaves the top off every
-     acute accent and caron. 0.125em per side buys 2.2px of clearance at 13px, and
-     being symmetric it does not move the centred text.
-   - 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
-     exactly the engine's ascent below the box top. Any other value leaves
-     (line-height - font box) / 2 to be halved and rounded, and Chromium floors
-     it -- measured with an explicit 1.25 the 14px switcher labels came out a
-     FULL pixel high (line box 17.5 under an 18px font box, so half-leading
-     -0.25 floored to -1) while the 13px strip label was fine, which is exactly
-     the kind of works-where-I-looked bug this rule exists to end.
-
-   --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, 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.
-
-   What this deliberately does NOT use is `text-box: trim-both`, which three of
-   the four previous attempts were built on. It ships in Blink and WebKit only
-   (Firefox 151 still reports false for it), so it can only be applied behind an
-   @supports gate, and a gate means two engines render two different geometries of
-   which only the one the author is looking at ever gets tuned. Trimming to
-   `cap alphabetic` and giving the descender back as asymmetric padding IS
-   size-independent and holds to 0.05px in both engines that implement it — but
-   ungated it swings to 0.39px in Firefox, and a measured shift needs no gate and
-   no second code path to beat it. */
+/* Centres the label's INK (cap top to baseline), not its line box; the shift is
+   measured per site by features/tabs/ink-centre.ts, which owns why. Not
+   `text-box: trim-both` (Firefox lacks it; a gate is two geometries, one
+   untuned), and `line-height` stays `normal`: Chromium floors any other
+   half-leading (1.25 put 14px labels a pixel high). */
 :where(.wt-root) .wt-tab-label {
   flex: 1 1 auto;
   min-width: 0;
   overflow: hidden;
   white-space: nowrap;
   text-overflow: ellipsis;
+  /* The ink allowance `overflow: hidden` needs (the line box clears an accent by
+     ~0.6px); symmetric, so it moves nothing. */
   padding-block: 0.125em;
+  /* Flex centres the MARGIN box, so twice the shift below lifts the border box
+     by one shift without growing the clip. A negative shift is a normal result. */
   margin-block: 0 calc(2 * var(--label-ink-shift));
 }
 
@@ -553,6 +495,7 @@
      even though the property is non-inherited per spec (the same deviation the
      touch model documents for .term-output). Without this, caret placement and
      text selection break inside the field in Safari — i.e. on the iPad. */
+  -webkit-user-select: text;
   user-select: text;
   /* The chip is cursor: pointer; a text field must not inherit that. */
   cursor: text;

package/css/page.css

@@ -28,7 +28,6 @@ body {
      this, rotating a phone to landscape zooms the text. iOS Safari implements
      ONLY the -webkit- prefixed form (the unprefixed property is ignored there),
      so both are required — unprefixed alone left iPhones inflating on rotate. */
-  /* stylelint-disable-next-line property-no-vendor-prefix -- iOS Safari only implements the prefixed form */
   -webkit-text-size-adjust: 100%;
   text-size-adjust: 100%;
   overscroll-behavior: none;
@@ -236,42 +235,14 @@ body {
    either ships its own @font-face or lets both tokens fall back to the platform
    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. */
+   No face carries ascent-override or descent-override: the terminal's cell
+   background is the run padding in 02-terminal.css, never these metrics. */
 @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 {
@@ -280,8 +251,6 @@ body {
   font-weight: 700;
   font-style: normal;
   font-display: block;
-  ascent-override: 99.5%;
-  descent-override: 25%;
 }
 
 @font-face {
@@ -290,8 +259,6 @@ body {
   font-weight: 400;
   font-style: italic;
   font-display: block;
-  ascent-override: 99.5%;
-  descent-override: 25%;
 }
 
 @font-face {
@@ -300,6 +267,4 @@ body {
   font-weight: 700;
   font-style: italic;
   font-display: block;
-  ascent-override: 99.5%;
-  descent-override: 25%;
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cplieger/web-terminal-ui",
-  "version": "7.2.0",
+  "version": "7.2.2",
   "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": "MPL-2.0",
@@ -40,7 +40,7 @@
     "verify": "bash scripts/verify.sh"
   },
   "peerDependencies": {
-    "@cplieger/web-terminal-engine": "^5.1.0"
+    "@cplieger/web-terminal-engine": "^5.2.0"
   },
   "overrides": {
     "qs": "^6.15.2"
@@ -56,7 +56,7 @@
     "@vitest/browser-playwright": "5.0.0",
     "@vitest/coverage-v8": "5.0.0",
     "eslint": "10.10.0",
-    "fast-check": "4.9.0",
+    "fast-check": "4.10.0",
     "html-validate": "11.15.0",
     "knip": "6.35.1",
     "playwright": "1.63.0",
@@ -64,7 +64,7 @@
     "stylelint": "17.15.0",
     "stylelint-config-standard": "40.0.0",
     "typescript": "npm:@typescript/typescript6@6.0.2",
-    "typescript-eslint": "8.69.0",
+    "typescript-eslint": "8.70.0",
     "vitest": "5.0.0"
   },
   "publishConfig": {

package/src/features/tabs/ink-centre.ts

@@ -1,41 +1,11 @@
-// Optical centring for the three chip labels (desktop strip, mobile switcher
-// chip, overview rows), measured in the engine instead of predicted from the
-// font's tables.
-//
-// Flex centring centres a label's LINE BOX. A font's metrics box reaches much
-// further above the baseline than below (the bundled Monaspace Neon NF: 0.995em
-// over, 0.250em under), so the visible text sits low inside the box it is
-// centred by, and the correction is the gap between the box's centre and the
-// text's own.
-//
-// WHICH BAND is the text's own is the load-bearing decision, and the first
-// version of this got it wrong. It centred cap-top-to-DESCENDER-bottom, which
-// reserves descender room below the letters and reads high: measured on the real
-// chip in Blink, the title's cap band sat 1.320px above the chip's centre while
-// the status dot and the close glyph beside it sat at exactly 0.000px, and a
-// title is judged against those two neighbours. So the band is cap-top to
-// BASELINE — the visible mass of a UI label, and the same pair of edges CSS
-// spells `text-box-edge: cap alphabetic`. Descenders overhang it deliberately;
-// the label's `padding-block` (30-tabs.css) is the allowance that keeps them
-// clear of `overflow: hidden`, so nothing is clipped by the choice.
-//
-// The correction is NOT a font-relative constant, which is what four earlier
-// fixes assumed. Engines round the font's ascent and descent to whole CSS pixels
-// before building the line box, so the ideal shift jumps whenever a size crosses
-// a rounding boundary: 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), and the shift moves with it.
-// Engines disagree with each other too (Gecko makes that same 14px box 17px, not
-// 18px), and so do platforms within one engine: iOS resolves metrics through
-// CoreText, Linux WebKit through FreeType, which is why the strip read correct
-// in every local check and high on an iPad. Measured across 11-20px the cap-band
-// shift sawtooths between about -0.010em and +0.028em — small, but still wider
-// than the 0.33px error that was reported as a defect, so it stays measured.
-//
-// So nothing here predicts. Each measurement asks the engine for the line box
-// and baseline it actually produced, asks the font for its actual cap ink, and
-// writes the difference to --label-ink-shift as pixels. The CSS keeps an em
-// default for the pre-measurement paint (see 00-tokens.css); this only ever
-// narrows the error.
+// Optical centring for the three chip labels, measured in the engine rather than
+// predicted from the font's tables. Flex centring centres the LINE BOX, and a
+// font's box reaches further above the baseline than below it, so the text sits
+// low; the correction is the gap from the box's centre to the CAP band's (cap
+// top to baseline, the `text-box-edge: cap alphabetic` edges; a band including
+// descender ink reads high beside the dot and close glyph). Measured, not a
+// constant, because engines round ascent and descent to whole CSS pixels before
+// building the line box, and round differently per engine and platform.
 import { fromHTML } from "../dom.js";
 
 /** Ink extents are measured at this size and scaled back to em: WebKit and Blink

package/src/features/tabs/model.ts

@@ -20,18 +20,9 @@ export type { SessionInfo };
  *  (SessionStatus.progressValue). Both status sources flow through one code path
  *  this way, and the optionality is meaningful: the polling fallback lists
  *  SessionInfo with no percentage at all, which means "no information" and must
- *  not be read as "the percentage was cleared".
- *
- *  `activity`/`activityCount` are declared here as a FORWARD declaration: the
- *  published engine's SessionInfo does not carry them yet. Drop both from this
- *  intersection once it does, so the wire shape has one home again — if the
- *  intersection then narrows anything, the engine's declaration is the wrong
- *  one. Both are `string`/`number` rather than unions for the same reason
- *  `status` is: the stream is parsed, not validated. */
+ *  not be read as "the percentage was cleared". */
 export type StatusRecord = SessionInfo & {
   readonly progressValue?: number;
-  readonly activity?: string;
-  readonly activityCount?: number;
 };
 
 // The status vocabulary, module-private on purpose: every consumer asks one of