@brightspot/ui 5.0.3-css-bloat.1 → 5.0.3

package/src/legacy/tool-ui/src/main/webapp/v4/rte/plugins/table_manager/views/ProseMirror-table.less

@@ -126,12 +126,39 @@
     }
 
     .ProsemirrorEnhancementMenu-container-button:is(
-        .edit,
         .arrow_upward,
         .arrow_downward,
         .open_with
       ) {
       display: none;
     }
+
+    .Enhancement.readOnly {
+      align-items: center;
+      display: flex;
+      flex-wrap: wrap;
+      overflow: hidden;
+    }
+
+    .Enhancement-label {
+      min-width: 0;
+      overflow: hidden;
+      text-overflow: ellipsis;
+      white-space: nowrap;
+    }
+
+    .ProsemirrorEnhancementMenu {
+      margin-left: auto;
+    }
+
+    .ProsemirrorEnhancementMenu-container.is-block {
+      position: static;
+    }
+
+    .Enhancement-preview,
+    .Enhancement-initialBody {
+      flex: 1 1 100%;
+      min-width: 0;
+    }
   }
 }

package/dist/storybook/assets/if-defined-CzvBkd64.js

@@ -1 +0,0 @@
-import{E as r}from"./iframe-Bi6noyvR.js";const m=o=>o??r;export{m as o};

package/docs/adr/0001-monolith-css-delivery.md

@@ -1,20 +0,0 @@
----
-status: accepted
----
-
-# Monolith CSS delivery; reject per-component CSS
-
-Every consumer of `@brightspot/ui` renders **inside a CMS page** where the host-built Monolith (`v5.<hash>.css`) is already present, and the library's components are Light-DOM class-appliers that ship no CSS of their own. We therefore keep the **host-built Monolith as the single CSS delivery vehicle** for all consumers: a consumer "picks and chooses" purely by importing the component **JS** it needs, and the corresponding `btu-*` CSS is materialized once, centrally, in the Monolith. The work to make this correct is (1) **de-bloat** the Monolith by decoupling cross-referencing plugins (Option A) and (2) **complete** it by registering the plugins consumers use (e.g. tooltip/popover) plus a safelist for runtime-written classes.
-
-## Considered options
-
-- **Direction 1 — Precompiled per-component CSS (self-contained components).** The library compiles a static `.css` per component and ships it next to the JS, so consumers bundle exactly what they import. **Rejected:** every consumer is in-CMS, so the Monolith is already on the page — bundling component CSS only **duplicates** what's already served (confirmed: platform-automation ships ~0 `btu-*` CSS today and relies on the Monolith).
-- **Direction 2 — Per-consumer Tailwind (JIT).** Add a Tailwind/PostCSS pipeline to `@brightspot/ui-builder` so each consumer compiles the classes it uses. **Rejected:** forces every consumer to adopt Tailwind (abandoning the deliberate vanilla-Vite simplicity), re-ships overlapping `btu-*` + utility CSS per consumer, and reintroduces cross-multiplication per-consumer.
-- **Direction 3 — Keep and fix the Monolith.** **Chosen.**
-
-## Consequences
-
-- Components intentionally ship **no** styling; they are inert without a Monolith on the page. "Pick-and-choose" is a JS-import concern, not a CSS one.
-- **Appearance theming** stays runtime-overridable via `--btu-theme-*` custom properties; **structural theming** (scales, new color families, variants) remains a compile-time concern owned centrally, not by consumers.
-- A consumer that needs a class the Monolith doesn't contain (today: tooltip/popover) **cannot** fix it locally — the fix must land where the Monolith is built (host CMS config and/or the published preset). This is the root cause of the tooltip-styles-missing defect.
-- If a true **standalone** (non-CMS) consumer ever appears, this decision must be revisited — Direction 1 would come back on the table for that consumer class.

package/docs/adr/0002-complete-component-preset.md

@@ -1,26 +0,0 @@
----
-status: accepted
----
-
-# Published preset registers the complete component set
-
-The published `@brightspot/ui` preset (`src/tailwind.config.ts`) registers the **full** component-plugin set plus an explicit `safelist` for runtime-written classes (tooltip/popover position/offset/no-arrow), rather than the minimal `pagination` + `empty-state` list it carried historically. Consumers — including the host CMS — extend the preset and get every component's CSS without maintaining their own per-plugin registration.
-
-### Cost (measured)
-
-**Host impact (the only number that matters for production):** switching the host CMS from its current 10-plugin list to the complete preset adds **≈ +16.9 KB** to the v5.css component layer (≈ +25–34 KB after postcss-rtl). tooltip+popover specifically account for **≈ +7.9 KB** of that, closing the headline tooltip-missing defect. The host's v5.css already ships the heaviest plugins (`button`, `badge`, `icon`, `heading`, `loader`, `scroll-shadow`, `contrast`, `ring-contrast`, `theme`, `container-queries`) — Phase 3 only newly adds the lighter components (action-bar, avatar, button-group, checkbox, dropdown, popover, switch, tabs, tooltip, upload).
-
----
-
-*Footnote — preset-intrinsic cost:* the standalone preset's component layer grows from ~2.7 KB (bare 2-plugin) to ~1.36 MB (complete). This is **not** the host impact (no production consumer compiles the bare preset — in-CMS consumers rely on the host Monolith per [ADR 0001](./0001-monolith-css-delivery.md)); it's an intrinsic-cost figure. The preset's broad color/size `safelist` patterns force-emit every *registered* component's runtime-applied variants (e.g. `btu-button-primary`, `btu-badge-lg`), so unused components do **not** purge to zero. The original rationale on this page claimed "addComponents is content-purged, so a complete preset costs ~0 for unused components" — that is incorrect when safelist patterns match the component's variants (which they do for most components). The reason completion is cheap *for the host* is that the host already registers the heavy plugins, not purging.
-
-## Why
-
-- Consumers previously hand-maintained their own `plugins[]` list (the host registered ~10 itself), which drifted out of sync. The omission of `tooltip`/`popover` there is exactly why those classes were missing from the Monolith — the tooltip-styles-missing defect. A complete preset removes the per-consumer registration step and the whole class of "forgot to register X" bugs.
-- Runtime-written classes (e.g. `TooltipMixin`'s POSITION_CLASSES/OFFSET_CLASSES) are invisible to content scanning, so they must be safelisted in the preset itself — consumers can't be expected to rediscover them.
-
-## Consequences
-
-- The host `cms/tool-ui` config can drop its manual `plugins[]` list and rely on `presets: [require('@brightspot/ui')]`. Before removing it, preset parity must cover everything the host registered (`theme`, `contrast`, `ring-contrast`, `@tailwindcss/container-queries`).
-- **Gated on [ADR 0003](./0003-plugin-selector-isolation.md).** Registering cross-referencing plugins (button-group, pagination, dropdown, upload) into the shipped preset is only safe once their foreign `.btu-*` selectors are decoupled — otherwise the `@apply` cross-multiplication detonates (≈ +2.75 MB for button-group alone). Sequence: **isolate first, then complete the preset.**
-- See [ADR 0001](./0001-monolith-css-delivery.md): the preset feeds the host-built Monolith, which is the single CSS delivery vehicle for all (in-CMS) consumers.

package/docs/adr/0003-plugin-selector-isolation.md

@@ -1,24 +0,0 @@
----
-status: accepted
----
-
-# Plugin selectors must not reference foreign component classes
-
-A `tailwind-plugin-<name>.ts` may only use `.btu-*` class tokens from **its own namespace** in its selectors. Referencing another component's `.btu-*` class — bare, in a combinator, or wrapped in `:where()`/`:is()` — is forbidden. To affect another component, use (a) the inner element / custom-element **tag** selector, (b) a CSS custom property the other component consumes, or (c) the component's own scoped class.
-
-## Why
-
-Tailwind's `@apply` resolver clones every rule whose selector contains a class token, once per `@apply <that-class>` site in the compiled CSS. So `.btu-pagination-controls > btu-icon-button > .btu-button { … }` is duplicated once per `@apply btu-button` site — ~178 in the host build — then doubled by postcss-rtl and fanned by variants → ≈ 917 KB of cross-multiplied rules for pagination's 7 selectors alone. The token's presence in the selector is the sole trigger; `:where()`/`:is()` do **not** help (verified — the walker matches the token regardless of wrapping).
-
-## We enforce; we do not auto-fix
-
-There is no safe library-side "magic" that neutralizes a stencil: the clone fires in the **host's** Tailwind pass (not the library's), the only internal skip-flag (`raws.tailwind.layer`) also removes the class from the apply cache and so breaks the legitimate `@apply btu-button` reuse path, and a codemod can't infer which element a foreign selector intended to target. So the rule is enforced, not corrected:
-
-- **`no-foreign-btu-class`** grep rule in `scripts/check-conventions.mjs` (pre-commit + CI) — flags any foreign `.btu-*` token in a plugin selector. Ownership is resolved by longest-matching plugin name (`btu-button` → `button`, `btu-button-group` → `button-group`).
-- **Flat-slope regression test** — compiles the preset against N = 0/10/100 `@apply btu-button` sites and fails if output is not independent of N. Catches reintroductions the grep can't see (e.g. selectors built from variables).
-
-## Considered and rejected
-
-`:where()`/`:is()` wrapping (token still clones), static CSS (re-multiplies unless injected *after* Tailwind — no host slot exists in the "ship raw CSS for the consumer's pipeline" model), `@scope` (Baseline Dec-2025 floor; the donut form still needs the element selector to reach the button), inverted ownership (selector still carries the token), Shadow DOM / `::part` (contradicts [ADR 0001](./0001-monolith-css-delivery.md)), patching `@apply` behavior (wrong repo; breaks the reuse API).
-
-This rule is the gate that makes [ADR 0002](./0002-complete-component-preset.md) safe and keeps Monolith growth linear (~3–6 KB per new component). Authoring guidance: `.ai/LESSONS-PLUGIN-ISOLATION.md`; complementary "compose, don't reinvent" rule: `.ai/LESSONS-BUTTON-REUSE.md` §3.

package/docs/adr/0004-dynamic-icon-names-route-through-runtime-injectors.md

@@ -1,50 +0,0 @@
----
-status: accepted
----
-
-# Dynamic icon names route through runtime injectors, not per-name CSS
-
-Every Brightspot path that renders a Lucide icon whose name is **chosen at runtime** (editor selections via `@ToolUi.IconName`, plugin code calling `createNavAreaHeader(..., "chart-pie")`, Material-to-Lucide compat lookups for `data-icon-button-name` elements, ProseMirror toolbar buttons, the `<btu-icon symbol="…">` web component itself) resolves the name in **JavaScript** and applies the SVG via **inline CSS custom properties** on the host element. None of these paths reads the Preset's per-name `.btu-icon-via-mask-NAME` rules. Therefore the Preset's **Safelist** must not force-emit those per-name rules — doing so ships ~1.18 MB of `v5.css` that the browser fetches, parses, and never consults.
-
-## Why
-
-The icon Component Plugin (`tailwind-plugin-icon.ts`) generates 1,792 per-name rules — one per Lucide icon — each inlining the entire SVG as a URL-encoded data URL. Until this decision they were force-emitted to v5.css by two redundant safelist patterns (`/btu-icon-via-mask-.+/` and `/^btu-icon(-.*)?$/`). Measured: 2,638 emitted rules (postcss-rtl doubles the directional ones), 1,182,531 bytes, **24.9% of v5.css**.
-
-Every actual rendering path bypasses these rules:
-
-| Dynamic path | Resolution mechanism | CSS slot the SVG lands in |
-| --- | --- | --- |
-| `<btu-icon symbol="X">` (Nav-rail, content widgets) | `Icon.ts` calls `getIcon(name)`, inlines the SVG as Light-DOM markup with a `<mask>` `<defs>`, sets `style="--mask-url: url(#X)"` | `--mask-url` (highest-priority slot in the base rule's `var()` chain) |
-| `<button data-icon-button-name="X">` (Right-rail / IconButton) | `v5.ts:applyIconProperties` (an `onFind`-registered host injector) maps Material → Lucide, calls `getIcon(name)`, sets `style="--compat-icon-via-mask: url(…)"` | `--compat-icon-via-mask` (third slot in the base rule's `var()` chain) |
-| ProseMirror toolbar (RTE-blacklisted) | `resolveIconCompat.js` fires a `btu-resolve-icon` custom event that re-enters `applyIconProperties` from outside the RTE blacklist | same as above |
-| `@apply btu-icon-via-mask-NAME` in developer CSS | Tailwind's `@apply` resolver copies the rule body from the plugin's internal registry into the consumer's selector at build time | the consumer's own rule (per-name source rule is not required in output) |
-| `<i class="btu-icon-via-mask-NAME">` in scanned source | Tailwind's content scanner emits the per-name source rule | the per-name source rule itself (~6 names total today) |
-
-The base rule the runtime injectors target is unchanged:
-
-```css
-.btu-icon-via-mask {
-  mask: var(--mask-url, var(--icon-svg, var(--compat-icon-via-mask))) center / contain no-repeat;
-  …shared properties…
-}
-```
-
-The base rule survives any safelist edit that excludes only `btu-icon-via-mask-X` (X non-empty). The runtime injectors continue to work because they consume the **base** rule via inline custom properties — they never depended on the per-name rules.
-
-The remaining ~1,786 names exist in v5.css purely as safelist artifacts. They are dead bytes.
-
-## Consequences
-
-- The Preset's safelist explicitly excludes the per-name via-mask namespace. Concretely, no safelist pattern may match a class of the form `btu-icon-via-mask-X` for any X — enforced by a convention guard in `scripts/check-conventions.mjs` alongside the existing `no-foreign-btu-class` and `safelist-runtime-classes` rules.
-- The Component Plugin remains unchanged. It continues to register all 1,792 per-name rules into Tailwind's internal registry so that **Cross-multiplication** for `@apply btu-icon-via-mask-NAME` in developer CSS keeps working (Tailwind copies the rule body into the consumer regardless of whether the source class survives output purging).
-- The ~6 statically-discoverable raw-class names (`eye`, `eye-closed`, `file-text`, `sparkles`, `upload`, `zap` as of this writing) continue to emit per-name rules because Tailwind's content scanner finds them. New static-class names self-emit on first use; no maintenance step.
-- A new raw-class name added by a downstream consumer in **non-scanned content** (e.g. a hand-built `<i class="btu-icon-via-mask-some-name">` injected at runtime by JS or by a template engine Tailwind doesn't scan) will **not** render its mask, because no rule will match. The supported alternatives are:
-  - Use `<btu-icon symbol="some-name">` (preferred — already runtime-resolved).
-  - Use the `data-icon` / `data-icon-name` / `data-icon-button-name` pattern (handled by `applyIconProperties`).
-  - Add the class to `additional-tailwind-classes.txt` so Tailwind scans it.
-- A byte-budget regression test in `test/css-bloat/` asserts the aggregate size of per-name mask rules in v5.css stays under 20 KB — leaving headroom for the natural growth of statically-discoverable names while catching any reintroduction of force-emission.
-- This ADR is the load-bearing premise for the Lever #1 safelist change in [`../../plans/lever-1-icon-emission-prd.md`](../../plans/lever-1-icon-emission-prd.md). It is reachable through any of the runtime-injector files (`src/legacy/tool-ui/src/v5.ts`, `src/legacy/tool-ui/src/main/webapp/v4/dom/resolveIconCompat.js`, `src/components/icon/Icon.ts`, `src/LucideDynamicLoader.ts`).
-
-If a future requirement appears where dynamic icon names *must* render through the raw class form without scanning and without using `data-icon*` attributes, this ADR is the place to revisit. Two follow-up paths are sketched in the Lever #1 PRD's design discussion: (a) plugin refactor splitting shared behavior onto the base class so a library-side runtime scanner can complete the rule from inline style, and (b) per-element `<style>`-block injection. Neither is needed under the current consumer contract; both would be reopened only if the contract changed.
-
-See also: [ADR 0001](./0001-monolith-css-delivery.md) (the Monolith is the single CSS delivery vehicle), [ADR 0002](./0002-complete-component-preset.md) (the Preset registers the complete component set; safelist patterns govern which variants force-emit), [ADR 0003](./0003-plugin-selector-isolation.md) (cross-referencing plugin selectors are forbidden).

package/docs/adr/0005-rtl-conditional-overlay.md

@@ -1,44 +0,0 @@
----
-status: accepted
----
-
-# RTL ships as a conditional overlay, not doubled into the Monolith
-
-Brightspot resolves text direction as a per-user setting server-side (`Localization.isCurrentUserRtl()`), emitted once into the `<html dir>` attribute. The Tool UI **Monolith** (`v5.css`), however, ships **both** directions to **every** user: `postcss-rtl` doubles each directional rule into `[dir="ltr"]` and `[dir="rtl"]` halves (plus bare-`[dir]` scoping), so ~25% of the post-Lever-#1 bundle is direction-prefixed and roughly half of that is dead weight on any given page. We therefore **split direction out of the Monolith**: all users load a direction-neutral base `v5.css`; RTL users *additionally* load a small `[dir="rtl"]`-only overlay `v5-rtl.css`, gated by the same `Localization.isCurrentUserRtl()` call that drives `<html dir>`. This **refines [ADR 0001](./0001-monolith-css-delivery.md)**: the Monolith stays the single styling vehicle, but materializes as a base + conditional overlay pair rather than one doubled bundle.
-
-## How the split is produced
-
-The base and overlay are a **clean partition of the same source CSS**, produced by one paren-aware direction-filter run with opposite predicates:
-
-| Bundle | Pipeline | Keeps |
-| --- | --- | --- |
-| `v5.css` (base) | postcss **without** postcss-rtlcss, then **strip-`[dir=rtl]`** | every rule except `[dir="rtl"]`-scoped parts; physical properties stay at their LTR-default values, unscoped |
-| `v5-rtl.css` (overlay) | postcss **with** `postcss-rtlcss` `mode: 'override'`, then **keep-only-`[dir=rtl]`** (which also prunes the at-rule wrappers it empties) | only `[dir="rtl"]`-scoped rules — the mirrored overrides, the authored `[dir="rtl"]` rules, and Tailwind `rtl:`-variant output |
-
-`base ⊎ overlay` reconstructs correct rendering for both users with **no gap and no overlap**: an LTR user gets the base alone; an RTL user gets the base (LTR-default physical props) plus the overlay's `[dir="rtl"]` overrides, which win on specificity regardless of load order.
-
-The two filters are **one module, two predicates**, sharing a top-level comma splitter that respects `(`/`[` nesting — so `.a, [dir=rtl] .b { … }` is partitioned, not mangled.
-
-Each stage runs as an **isolated postcss pass** (postcss-rtlcss → filter → cssnano), not one chained pipeline: postcss-rtlcss must fully finish adding `[dir=rtl]` overrides before keep-rtl runs, and keep-rtl must finish before cssnano — otherwise cssnano's empty-discard races keep-rtl's rule removal and the emptied `@media`/`@container` wrappers survive (measured: ~46 KB of husks, ~32% of the overlay). The filter therefore prunes empty at-rules in its own `OnceExit` rather than relying on cssnano.
-
-## Why postcss-rtlcss `override` + keep-rtl (verified empirically)
-
-`postcss-rtlcss` v6 `mode: 'override'` was confirmed (2026-06-02, sandbox `/private/tmp/rtlcss-verify`) to emit **no** `[dir="ltr"]` halves and **no** bare-`[dir]` scaffolding — but it **keeps every unscoped original rule** alongside the `[dir="rtl"]` overrides. Override-alone is therefore not a lean overlay (it would carry a full copy of the base). The keep-rtl filter drops those originals, leaving the `[dir="rtl"]`-only overlay.
-
-Override mode also emits the explicit cascade-resets the overlay needs (e.g. `[dir="rtl"] .x { border-left: none; border-right: … }`). This is what makes it beat the considered alternatives:
-
-- **`mode: 'combined'`** — reproduces postcss-rtl's doubling (`[dir=ltr]` + `[dir=rtl]` halves). Rejected.
-- **`mode: 'diff'`** — emits flipped declarations **unscoped** (relying on load order, not specificity) and **silently drops authored `[dir="rtl"]` rules**. Rejected.
-- **"postcss-rtl extraction"** (filter postcss-rtl's doubled output down to its `[dir=rtl]` half) — the originally-feared fallback. Unnecessary, and *less correct*: postcss-rtl puts the cascade-resets in the `[dir=ltr]` half, so the extracted `[dir=rtl]` half would be missing them.
-- **Parallel model** (RTL users load `v5-rtl.css` *instead of* `v5.css`) — two large bundles, lower edge-cache hit rate, no free graceful degradation. Rejected in favor of the overlay.
-
-## Consequences
-
-- A **CI overlay-integrity assertion** guards the partition every build: the base must contain zero `[dir="rtl"]` rules; the overlay must be non-empty and contain only `[dir="rtl"]` rules (zero unscoped / `[dir="ltr"]` / bare-`[dir]`). This catches a strip-rtl leak into the base, a silently no-op'd postcss-rtlcss (empty overlay), and a keep-rtl leak of originals into the overlay — each diagnostically. Stronger than a bare "byte counts differ" check.
-- **Graceful degradation is free — and better than worst-case.** The base is built on CSS **logical properties**, which respond to the server-set `<html dir="rtl">` natively (no `[dir=rtl]` rules needed). So if a deployment is missing `v5-rtl.css`, an RTL user still gets **mostly-correct RTL** — only the physical-property elements (the overlay's job) stay unflipped — never a blank page or a fully-LTR layout. No runtime fallback logic. (Validated live 2026-06-02: at `dir=rtl` the base alone mirrored the bulk of the Dashboard and Content Edit pages; the overlay then corrected 16 and 46 physical-property elements respectively, including reversing the RTE toolbar.)
-- **Measured impact (2026-06-02, same shared compile, decimal MB):** LTR base 2.63 MB — **−12.8%** vs the 3.02 MB doubled build (which cross-checks against the shipped container artifact ≈ 3.01 MB); RTL base+overlay 2.73 MB — **−9.7%**; overlay **95 KB** (beats the ~130–140 KB projection after empty-wrapper pruning). The overlay's size is effectively a **proxy for physical-property debt** in the legacy CSS: it shrinks toward zero as source migrates from physical (`padding-left`) to logical (`padding-inline-start`) properties, at which point native `dir` handling would leave the overlay nearly empty.
-- The direction-filter is the **deep module** of Lever #2, golden-tested in both directions independent of the build orchestration.
-- **`v4.css` is out of scope** and keeps `postcss-rtl` until v4 is separately retired (it also has hand-authored `[dir='rtl']` Less rules that need their own audit).
-- The change surface is entirely Host-CMS-consumer-side (`build-css.mjs` + a conditional second `<link>` in `DariHtmlToolPageUtils`); the **Preset** is unchanged, so other `@brightspot/ui` consumers are insulated.
-
-See also: [ADR 0001](./0001-monolith-css-delivery.md) (Monolith as single delivery vehicle — refined here), and the full Lever #2 design this records the decision for: [`../../plans/lever-2-rtl-overlay-prd.md`](../../plans/lever-2-rtl-overlay-prd.md).

package/docs/adr/0006-editor-has-runtime-perf.md

@@ -1,33 +0,0 @@
----
-status: accepted
----
-
-# Editor-scoped `:has()` is the v5 runtime-perf hazard; reduce it
-
-The v5 CMS UI feels frozen during editing while v4 is smooth, on the same page/DOM/machine. The cause is **`:has()` selector invalidation**: v5's stylesheet authors ~782 distinct `:has()` selectors (993 occurrences) vs v4's 41, and the browser re-tests `:has()` on every DOM mutation and every change to a class/attribute used as a `:has()` argument — which the editor JS does constantly. Each such interaction costs **~250 ms in v5 vs ~0–2 ms in v4**; expanding a Subscriptions item makes it ~16× worse by bringing the `:has()`-dense `ContentForm` subtree live. **Decision: treat the editor-subtree `:has()` as a runtime-perf hazard and reduce the ~160 rules scoped to `.CIG`/`.RCIG`/`.EIG`/`ContentForm`** (rewrite to `:focus-within`, JS/server-toggled classes, `:where()`/sibling selectors), preserving the structural `display:none` hides. Full evidence and rewrite recipe: [`plans/v5-css-has-runtime-perf-investigation.md`](../../plans/v5-css-has-runtime-perf-investigation.md).
-
-## Considered options
-
-All measured via live A/B (v5 `jpencola` vs v4 `joe`, same page), median forced-reflow cost per post-expand interaction:
-
-- **Do nothing.** Stock v5 ≈ 507 ms/interaction (v4 ≈ 1 ms). **Rejected** — this is the reported "frozen" UX.
-- **Rewrite only `:has(:focus)` / `:has(.is-*)` (the dynamic patterns, 149 rules).** 507 ms → ~375 ms (**1.4×**). **Rejected** — necessary mechanism but far short; cost is the aggregate `:has()` count in scope, not one category.
-- **Remove all `:has()` (802 rules).** ~21 ms (**~25×**). **Rejected as the fix** — strips structural `display:none` hides and component styling system-wide; proves the lever but breaks layout/behavior.
-- **Reduce the ~160 editor-scoped `:has()` (`.CIG`/`.RCIG`/`.EIG`/`ContentForm`).** ~22 ms (**~25×**, = full benefit) while leaving the other 768 untouched. **Chosen** — 16 % of the rules recover ~96 % of the speed, on a bounded surface (the editor CSS files).
-
-## Consequences
-
-- The work is a **design-system `:has()` diet** in `src/legacy/tool-ui/src/` editor CSS (`ContentEdit.css`, `ContentInputGroup.css`, `ContentForm.css`, `RepeatableContentInputGroup/Selector.css`, `Widget.css`, …), not a one-line change. Behavior-sensitive: `:has(:focus)`→`:focus-within` is equivalent, but structural `:has(> child)` and `:has(.is-*)` rewrites must keep the same visual result (especially `display:none` hides) or layout regresses.
-- Distinct from byte-bloat work (ADR 0002 and the bloat investigation): reducing `:has()` also trims ~185 KB, but the **runtime** win comes specifically from cutting the editor-subtree `:has()` count — size reduction alone (e.g. icon emission) would not fix the jank.
-- `:has()` becomes a reviewable cost in the editor surface: new `:has()` in CIG/RCIG/ContentForm CSS should be justified or replaced with a class, since the cost scales with how many `:has()` cover an interacted subtree.
-- The lever was first proven via live in-container CSS surgery (the proxy); the shipped fix is the source rewrite below, rebuilt through the real compilers and re-measured on the same page.
-
-## Outcome (implemented 2026-06-02, branch `fix/v5-css-bloat`)
-
-Behavior-preserving rewrite of the 42 editor-scoped `:has()` source rules: `:has(:focus…)` → `:focus-within`; `:has(+ .CIG-row)` / error-border → `:not(:last-child)`; one inert `transition-delay` rule dropped; everything structural (`:has(> child)`, `:has(~ sibling)`, `:has(.is-*)`) → a runtime class set by a new self-contained module `src/legacy/tool-ui/src/editorHasCompat.ts` — an idempotent, debounced sweep (`querySelectorAll` + `classList.toggle`) driven by ready + the editor's `brightspot-content-state-change` event + a 120 ms `MutationObserver`, **not** Blink's per-mutation `:has()` re-test. (FormFilter marks `.is-filterResultAncestor` on result ancestors in JS, replacing `:has(.is-filterResult)`.)
-
-- **Built-Monolith count (PostCSS walk):** total `:has(` **993 → 765**; editor-scoped (`.CIG/.RCIG/.EIG/ContentForm`) **223 → 3**. The 3 residuals are the self-contradictory `RCIG-list:empty:has(ol,ul)` ContentForm placeholders (`:empty` + `:has(children)` → never match), absent from normal content-edit surfaces.
-- **Runtime verdict — human A/B, per the [microbenchmark pitfall](../../plans/v5-css-has-runtime-perf-investigation.md):** editor went from janky to "a lot better / acceptable." Synthetic forced-reflow probes do **not** reproduce the jank on Chrome 148 and must not be used to confirm it.
-- **Confirmed by Chrome DevTools *Selector stats* under real editor churn (sorted by invalidation count):** **no rewritten editor `:has()` appears** — `has-formContent` et al. are plain classes now, so they don't invalidate. The only editor-scoped `:has()` in the trace are the 3 inert ContentForm `:empty:has` residuals, at ~748 invalidations but **~0.1 ms each** (`:empty` + `:has(children)` bails instantly — confirmed harmless). The top invalidators are all sub-1.1 ms: `:hover`/`:focus-within` recalc (the pattern this rewrite adopts) and tiny-scope out-of-scope page-chrome `:has()` (calendar / preview / page-header). The per-interaction `:has()` invalidation storm is gone; cost is now ordinary recalc.
-- **Correctness:** for each runtime class, `querySelectorAll('.has-X')` equals the original `:has()` selector element-for-element — 11 classes confirmed EQUAL across Users / Blog Post / Dashboard, the `has-cig` setter and the live `MutationObserver` path confirmed by injection, no console errors. Found and fixed one gap during verification: `DashboardWidget`'s `form:has(.CIG)` → `form.has-cig` rewrite had no setter (added).
-- **Follow-up (out of scope, file separately):** the single most expensive selector in the trace, `.is-imagePreview:not(:has(.ImageEditor-groups.is-focus-active))` (~46 ms, 0 invalidations), is a pre-existing ImageEditor `:has()` outside the `.CIG/.RCIG/.EIG/ContentForm` scope; 7 ImageEditor-related `:has()` remain as a candidate next pass.