@aceshooting/lyra-ui 17.0.0 → 18.1.0

package/CHANGELOG.md

@@ -1,5 +1,488 @@
 # Changelog
 
+## 18.1.0
+
+### Minor Changes
+
+- 6137062: `<lr-filter-bar>`: under `activeFiltersDisplay="changed"`, the reset button now keys its enablement
+  on `hasChangedFilters` instead of `hasActiveFilters`.
+  
+  `'changed'` exists to say that a filter sitting at its own declared `defaultValue` is not something
+  the user applied, and it already suppressed that filter's chip. The reset button next to the empty
+  chip row stayed enabled anyway, so a defaults-only bar rendered "nothing is applied" and "press here
+  to clear what's applied" side by side, and pressing it was a no-op that still emitted `lr-input` and
+  `lr-reset`.
+  
+  Nothing else changes: enablement under `activeFiltersDisplay="all"` (the default) and `"hidden"` is
+  byte for byte what it was, `disabled`/`loading` still win in every mode, `hasActiveFilters` keeps its
+  meaning, and `reset()` itself is untouched — it still restores every declared `defaultValue`.
+- 6137062: `<lr-filter-bar>`: add a public read-only `hasChangedFilters`.
+  
+  `hasActiveFilters` answers "does any filter hold a value", which is deliberately `true` for a bar
+  whose filters were declared with their own non-empty `defaultValue` and have never been touched —
+  so a host that wanted to show "3 filters applied", enable an "Apply"/"Save search" action, or badge
+  a collapsed filter panel had to re-derive the default comparison itself from `filters` and `value`.
+  `hasChangedFilters` exposes it directly, using the exact equality `activeFiltersDisplay: 'changed'`
+  already filters its chip row on: a `readonly string[]` default compares positionally, everything
+  else compares with `Object.is`, and a filter with no declared `defaultValue` counts as changed the
+  moment it holds any value at all. Clearing a filter that *does* declare one also counts as changed,
+  since `reset()` would restore it — which is the one case where it differs from the `'changed'` chip
+  row, whose entries are non-empty values by construction.
+  
+  `hasActiveFilters` is unchanged, and so is every existing behaviour keyed on it.
+- 6137062: `<lr-filter-bar>`: a filter definition's `labelVisibility` accepts a third value, `'auto'`.
+  
+  `'visible'` and `'hidden'` were an all-or-nothing choice made once, at definition time, for a
+  component that is as likely to sit in a 320px side panel as across a full page — so a bar authored
+  for a dashboard lost a whole row of vertical space in a drawer, and one authored for the drawer
+  shipped unlabelled fields to the dashboard. `'auto'` renders exactly what `'visible'` does (same
+  stacked label element, same accessible name computed from it, no `aria-label` and no placeholder
+  fallback) and visually clips that label once the bar's **own** allocation — a container query on the
+  host, not the viewport — drops below `30rem`. The label element stays in the DOM at every width, so
+  the field's accessible name is identical in both states; the previous workaround, visually hiding
+  `::part(filter-control-label)` from a consumer stylesheet, removed the name along with the text.
+  
+  `'checkbox-menu'` participates through its own trigger label run, the same one `'hidden'` already
+  clips there.
+  
+  `'visible'`, `'hidden'` and an unset `labelVisibility` are unchanged at every allocation. The host
+  does become an inline-size query container (with the library's standard
+  `contain-intrinsic-inline-size` fallback), which is a no-op for a bar in an ordinary block or flex
+  allocation.
+- 3f4be41: `<lr-map>`: add `legendCollapsible`/`legendOpen` and the cancelable `lr-map-legend-panel-toggle`.
+  
+  The legend panel could not be collapsed at all, so a large key permanently covered part of the map.
+  `legend-collapsible` renders a native disclosure button inside the panel whose visible localized
+  text is its accessible name, whose `aria-expanded` renders the literal `"true"`/`"false"`, and whose
+  `aria-controls` names the row list in the same shadow root. `legendOpen` defaults **open**, so adding
+  only `legendCollapsible` never hides an existing key; it is a `true`-defaulting boolean, so
+  `legend-open="false"` parses and the open default reflects as an absent attribute.
+  
+  Activation emits the cancelable `lr-map-legend-panel-toggle` (`detail: { open }`). `preventDefault()`
+  is a real veto — nothing is written and nothing re-renders — so a host can own the open state, and a
+  programmatic `legendOpen` assignment reconciles without emitting, so a controlled host cannot loop.
+  Collapsing hides the gradient, the rows, the `legend-limit` summary and the trailing `legend` slot;
+  the `legend-start` slot and the disclosure stay visible. New `legend-disclosure` and
+  `legend-disclosure-icon` parts. With `legendCollapsible` unset the rendered legend is unchanged.
+- 3f4be41: `<lr-map>`: add an optional `group` to `LyraMapLegendEntry`, splitting the legend into sections.
+  
+  `legend` was one flat array rendered as a single list, so a key covering two layers could not say
+  which rows belonged to which. Consecutive entries sharing an identical `group` now render as one
+  section — a visible `legend-group-heading` plus a `role="group"` that heading names through
+  `aria-labelledby`. The grouping rule is pinned rather than inferred: an entry with no `group` keeps
+  its **declared** position (never hoisted or sunk), and a `group` that reappears after an interruption
+  opens a second section rather than reordering rows to merge them.
+  
+  `group` is caller-supplied data, so it renders verbatim and is never passed through the locale
+  catalog; it is trimmed, bounded to 256 characters, and a non-string, empty or whitespace-only value
+  means "ungrouped" rather than an empty heading. Sections are not rows: the 100-row cap and the
+  `legend-limit` summary still count rows. A grouped legend gives each run its own `role="list"`
+  (a `list` may only own `listitem`s), while a legend with no groups renders exactly as before. New
+  `legend-group` and `legend-group-heading` parts.
+- 3f4be41: `<lr-map>`: add a `legend-start` slot that renders at the top of the legend panel.
+  
+  The panel's only host extension point was `slot="legend"`, which renders after the gradient bar and
+  every projected row — so a host-authored panel header (a title, a source note, a control) could only
+  ever be a footer. `legend-start` renders ahead of both. Content in it alone opens the panel, exactly
+  as `legend` content alone already did, and it is never made interactive by `legendInteractive`. The
+  existing `legend` slot keeps its position, so an unset map's legend markup is unchanged.
+- 42af229: `<lr-select>`: `loading` now covers the whole pending state, not only its committed-value half.
+  It already rewrote an unresolved committed value's label to the localized `loading` text and
+  suppressed the "not in catalog" badge; with nothing selected at all -- a create form whose option
+  catalogue is still being fetched, or an edit form whose saved selection is legitimately empty --
+  `labelFor()` was never reached and the trigger fell through to the consumer's own `placeholder`.
+  Covering that half meant hand-writing a conditional placeholder bound to the same flag and
+  re-localizing, in the consuming app's own catalogue, the exact string this control already owns.
+  
+  The trigger now renders the same localized text in place of `placeholder` while `loading` is
+  `true` and the selection is empty -- the existing `loading` message key, so both halves always read
+  the same words and a `registerLyraLocale()` translation reaches them both. With `loading` false an
+  empty selection renders the consumer's `placeholder` exactly as before, `value` is never touched,
+  and the trigger's accessible name is unchanged: a host `aria-label` still wins, then `label`, then
+  `placeholder`, then the localized `select` fallback.
+- 42af229: `<lr-select>`: new `sync` property, closing the shared anchored-surface sizing vocabulary
+  `<lr-popup>`, `<lr-popover>`, `<lr-dropdown>` and `<lr-combobox>` already spell. It takes the same
+  `'width' | 'height' | 'both'` type (`PlaceSync`), the same unset default, and is wired through the
+  same `place()` option, so `sync="width"` copies the rendered trigger width onto the listbox: a
+  full-width select with short option labels no longer opens a listbox visibly narrower than, and
+  floating centred under, its own trigger. Changes reposition an already-open listbox without closing
+  it, and unsetting it releases the inline width the positioner wrote.
+  
+  With `sync` unset the listbox renders exactly as before -- `inline-size: max-content` between
+  `--lr-size-12rem` and `min(--lr-popover-viewport-clamp, --lr-size-28rem)`. A synced listbox is
+  capped on `--lr-positioner-available-inline-size` alone, adopting the corrected clamp rather than
+  the viewport-clamp shortfall it would otherwise have inherited, so it matches its trigger at any
+  width while the measured available space still keeps it on screen.
+- b22fdbb: Design tokens: add `--lr-icon-button-size-scope`, an ancestor-scoped input for the icon-only
+  control size.
+  
+  `--lr-icon-button-size` is element-scoped and has to stay that way: the shared token layer
+  re-declares it on every `lr-*` host so the coarse-pointer touch-target floor can apply per element.
+  The side effect is that a wrapper setting `--lr-icon-button-size` is replaced at the first
+  component in between, so it never reaches an icon button composed inside another component — a
+  `<lr-icon-button>` slotted through `<lr-popover>`, or the copy affordance inside `<lr-code-block>`.
+  The only ancestor lever was `--lr-theme-icon-button-size`, which is application-wide by design, so
+  "make just this toolbar denser" meant reaching for the global theme input and scoping it by hand.
+  
+  `--lr-icon-button-size-scope` is declared nowhere, so it inherits the whole way down and reaches
+  every icon-only control below the wrapper that sets it:
+  
+  ```css
+  .message-toolbar {
+    --lr-icon-button-size-scope: 1.75rem;
+  }
+  ```
+  
+  Precedence is `--lr-theme-icon-button-size` → `--lr-icon-button-size-scope` → the `2.5rem` default,
+  and the coarse-pointer floor still raises a resolved value below `2.75rem` back to it, so the new
+  knob is not a route around WCAG 2.2 SC 2.5.8. Purely additive: `--lr-icon-button-size` keeps its
+  current element-scoped behaviour exactly, and the resolved default is unchanged.
+
+### Patch Changes
+
+- 6137062: Docs: `<lr-filter-bar>`'s consumer reference now covers `hasChangedFilters` (and how it differs from
+  `hasActiveFilters` on a defaults-only bar), the `activeFiltersDisplay="changed"` reset-enablement
+  coupling, and `labelVisibility: 'auto'` with its `30rem` container-query threshold.
+- 3f4be41: Document `<lr-map>`'s collapsible legend, `legend-start` slot and legend sections in the authored
+  `llms/media.md` reference: `legendCollapsible`/`legendOpen` (including the `true` default and the
+  `legend-open="false"` parse), the cancelable `lr-map-legend-panel-toggle`, the `group` field and its
+  pinned ordering rule, and the four new parts.
+- 42af229: `<lr-combobox>`: a `sync="width"`/`sync="both"` listbox is no longer shortened by
+  `--lr-popover-viewport-clamp`. The synced rule capped the listbox at
+  `min(var(--lr-popover-viewport-clamp), var(--lr-positioner-available-inline-size, 100vw))`, and the
+  clamp's 92vw default resolves below the width of exactly the full-width trigger `sync` exists to
+  serve -- a 738px trigger in an 800px viewport got a 736px listbox, and the shortfall grows with the
+  trigger. The synced rule now caps on `var(--lr-positioner-available-inline-size, 100vw)` alone,
+  matching `<lr-popup>`: a width-synced listbox is anchored to an element already on screen and
+  measured against the space actually available beside it, so the extra viewport ceiling had nothing
+  left to protect against, while the available-space term still keeps an over-wide anchor from
+  pushing the listbox off-screen. An unsynced listbox is unchanged and keeps
+  `min(--lr-popover-viewport-clamp, --lr-size-28rem)`.
+- 42af229: Docs: `llms/forms.md` now documents `<lr-select>`'s new `sync` property (same vocabulary note as
+  `<lr-combobox>`'s, stating its unset default), records that a width-synced listbox on **both**
+  controls is capped on `--lr-positioner-available-inline-size` alone rather than also by
+  `--lr-popover-viewport-clamp`, and describes `loading`'s coverage of an empty selection alongside
+  the `placeholder` entry it now takes precedence over.
+- b22fdbb: Design tokens: derive the dark-mode overlay surface from the page surface instead of pinning it.
+  
+  `--lr-color-surface-overlay` is the panel colour behind every floating surface — dropdowns,
+  listboxes, menus, toasts, popovers, dialogs, and the `lr-app-rail` mobile drawer. In light mode it
+  already resolves straight to `--lr-color-surface`, so one `--lr-theme-color-surface-default`
+  override carries all of them with it. Dark mode pinned a literal instead, because panel and page
+  resolving to the same near-black makes an open dialog read as a scrim with text floating on it and
+  no panel at all. The cost was that re-skinning the dark base surface left every floating surface at
+  the stock colour — a mismatched panel rather than a themed one.
+  
+  It is now derived, keeping the elevation delta the literal existed to provide:
+  
+  ```css
+  --lr-color-surface-overlay: var(
+    --lr-theme-color-surface-overlay,
+    color-mix(in srgb, var(--lr-color-surface) 85%, #8bade2)
+  );
+  ```
+  
+  At the built-in dark base the pair resolves to the same panel colour it always has, so no existing
+  dark theme moves. Light mode is untouched, and an explicit `--lr-theme-color-surface-overlay` still
+  wins outright.
+- b22fdbb: Docs: state the icon-button size scopes and the derived dark overlay surface in `llms/shared.md`.
+  
+  Three properties now resize icon-only controls and they differ only in how far they reach, which is
+  not something a consumer can infer from the names: `--lr-theme-icon-button-size` is
+  application-wide, `--lr-icon-button-size-scope` covers one subtree, and `--lr-icon-button-size` is
+  element-scoped because the shared token layer re-declares it on every host. The reference now says
+  so in one table, with the precedence order and the coarse-pointer floor spelled out, instead of
+  leaving "my wrapper rule does nothing" to be rediscovered per project.
+  
+  The overlay-surface entry records that `--lr-color-surface-overlay` follows
+  `--lr-theme-color-surface-default` in dark mode as well as light, so a single base-surface override
+  re-skins every dropdown, listbox, menu, toast and drawer, and explains why dark derives the value
+  rather than resolving straight to the page surface the way light does.
+- 90449c6: `<lr-virtual-list>`: `row-height="auto"` driven by an external `scrollElement` no longer raises the
+  uncaught window error "ResizeObserver loop completed with undelivered notifications." when the
+  scroller jumps to its end and the newly revealed window measures. Nothing was ever dropped -- the
+  browser re-delivers on the following frame -- but the notice arrives as an uncaught `ErrorEvent` on
+  `window`, so it landed on whatever was running at the time and failed consumers' clean-console e2e
+  gates with a message that named no component.
+  
+  The offending write is `[part="spacer"]`'s height, the list's whole virtual extent. `onRowsResized()`
+  folded each newly measured row height into the offsets and asked for a render; Lit flushes that
+  render on the microtask checkpoint that follows the observer callback, which is still inside the
+  browser's resize-observation delivery. Under an external `scrollElement` that write resizes an
+  *observed* box, because `[part="base"][data-external-scroll]` takes its own block size from the
+  spacer and is watched by the container `ResizeObserver` -- and `[part="base"]` sits shallower in the
+  tree than the rows just broadcast, so the browser records the resize as a skipped observation and
+  ends the loop with the error. Reproduced deterministically in WebKit and, with a large enough first
+  measurement delta, in Chromium too.
+  
+  Reading inside the delivery is fine; folding the result into the offsets is what resizes the box.
+  So the measurement callbacks now only stash what they observed, and the offsets rebuild -- with the
+  scroll-anchor correction that belongs to it, so neither is ever painted without the other -- runs on
+  the animation frame this component already used to defer `observe()` calls out of the same delivery.
+  A render that still lands mid-delivery then re-reads offsets nothing has changed and writes the
+  extent already in the DOM, which resizes nothing. Renders themselves are never held: this element's
+  `updateComplete` keeps settling in the same microtask run as before, which is what every component
+  composing it relies on when it reads rendered rows back after its own update. Only the
+  external-`scrollElement` case defers at all -- with the list's own viewport scrolling,
+  `[part="base"]` takes its block size from `--lr-virtual-list-height` rather than from the spacer, so
+  the extent write reaches no observed box and every measurement there stays as immediate as it was,
+  fixed numeric `row-height` included. The error message itself is neither suppressed nor filtered
+  anywhere.
+
+## 18.0.0
+
+### Major Changes
+
+- 555b974: **Major only because several exported TypeScript unions and maps gained members. No runtime
+  behaviour changes, no attribute or event was removed or renamed, and no default moved.** If you do
+  not perform exhaustive type-level matching over the members listed below, this release is a
+  drop-in upgrade and you can stop reading here.
+  
+  The public-API gate classifies widening an exported union as breaking, and it is right to: a
+  consumer with an exhaustive `switch` over one of these, or a mapped type keyed by one, stops
+  compiling until the new member is handled. Nothing else about them changed.
+  
+  **`lr-filter-bar`**
+  - `LyraFilterBarControlType` gains `'chip'`.
+  - `LyraFilterBarFilterDefinition` gains `LyraFilterBarChipDefinition`.
+  - `LyraFilterBarDefinitionValue<D>` gains an arm resolving a chip filter to the full
+    `LyraFilterBarFieldValue`, exactly as `'custom'` already does. Every other `D` resolves as before.
+  
+  An exhaustive `switch (definition.type)` over a filter schema now needs a `'chip'` case, and a
+  `Record<LyraFilterBarControlType, T>` needs a `chip` key.
+  
+  **`lr-map`**
+  - `LyraMapLegendEntry` gains an optional `value` category key.
+  - `LyraMapEventMap` gains `'lr-map-legend-toggle'`.
+  - New exported `LyraMapLegendToggleDetail`.
+  
+  A `Record<keyof LyraMapEventMap, T>` needs the new key. `LyraMapLegendEntry` is only widened by an
+  optional property, so constructing one is unaffected; only code that enumerates its keys is.
+  
+  **`lr-virtual-list`**
+  - New `rowProjection` property and `row-projection` attribute, new `projectedRows` getter, new
+    exported `LyraVirtualListRowProjection`, and two exported constants,
+    `VIRTUAL_LIST_ROW_ATTRIBUTE` and `VIRTUAL_LIST_STICKY_ATTRIBUTE`.
+  
+  **Generated framework declarations.** `./custom-elements-jsx`, `./vue` and `./svelte` are
+  regenerated from the manifest, so the prop types for the components above widen accordingly. This
+  is the bulk of the gate's reported diff and needs no action.
+  
+  **Migration:** add the new members to any exhaustive union handling; otherwise upgrade directly.
+
+### Minor Changes
+
+- 49eb3ef: `<lr-combobox>` gains `sync` (unset by default), spelled and shaped identically to
+  `<lr-dropdown>`/`<lr-popup>`/`<lr-popover>`'s property of the same name. Setting `sync="width"`
+  copies the trigger's rendered width onto the listbox and drops the previously fixed 12rem-28rem
+  content-based clamp (keeping only the outer viewport/available-space ceiling), so a full-width
+  trigger with short option labels gets a listbox that aligns to its own edges instead of floating
+  narrower in the middle. Left unset, the listbox continues to size to its own content exactly as
+  before.
+- 204aeb4: **`<lr-filter-bar>`: a control-less `type: 'chip'` filter, for a value owned by a widget elsewhere
+  on the page.**
+  
+  A calendar heatmap cell, a map selection, a chart brush — the filter is real, but the control that
+  sets it is not in the toolbar. Until now the only way to surface such a filter in the bar was a
+  `type: 'custom'` definition whose renderer drew something inert just to occupy the cell it was
+  forced to claim.
+  
+  `type: 'chip'` renders **no control and no toolbar cell**: no `field` wrapper is emitted for it, so
+  `lr-filter-bar::part(field)` and `::part(field-<filterId>)` never match one, and a bar whose filters
+  are *all* chip-only paints no empty column — its `controls` row still renders the reset button (the
+  "clear all" action such a bar needs), the `end` slot and the loading spinner, exactly like a bar
+  declaring no filters at all.
+  
+  Everything else is unchanged from any other filter type. The value lives in `value` under its own
+  filter ID, rides every `lr-input`/`lr-reset` detail, counts toward `hasActiveFilters` (so it enables
+  the reset button) and toward `invalidFilterIds` when `required`, renders a removable active-filter
+  chip subject to `activeFiltersDisplay`, and is cleared both by removing that chip and by `reset()`.
+  A `required` chip-only filter is honoured in bookkeeping only — it joins `invalidFilterIds`, fails
+  `checkValidity()` and moves `lr-validity-change` — but renders no inline error, because the bar
+  renders no element of its own for it; the owning widget keeps its own error affordance. The
+  inherited `placeholder` is inert here for the same reason it already is for `type: 'custom'`.
+  
+  **Chip text.** An optional `formatValue(value, locale)` produces it, and `locale` is the bar's
+  `effectiveLocale` — the same locale every built-in type's own chip formatting and a custom adapter's
+  `formatValue` already receive, so the caller localizes its own data. Omitted, the fallback ladder is
+  the one a custom adapter's omitted `formatValue` uses: a string array renders as a localized
+  conjunction list, anything else renders verbatim through `String(value)`, and an unset value renders
+  empty. Verbatim is exact — a chip-only value never passes through the date branch that localizes a
+  `'date'`/`'date-range'` chip, so an ISO day is not silently reformatted and a value containing a
+  slash is not mangled.
+  
+  **Clearing.** An optional `clearValue` (default `''`, what every non-multi built-in type writes) is
+  what a chip removal writes; declare `[]` for an array-valued chip-only filter. An optional `isEmpty`
+  overrides the built-in emptiness rule. A domain sentinel must pair the two: a sentinel clear value
+  with no matching `isEmpty` leaves the bar reading the "cleared" value as still set and still
+  rendering a chip for it — the identical pairing a custom adapter's own `clearValue`/`isEmpty`
+  already documents. With the pair declared, the sentinel is never stored in `value` and an absent key
+  reads back as the sentinel for the owning widget.
+  
+  **Additive only.** A schema declaring no `'chip'` filter renders byte-identical shadow DOM: the
+  render path keys on `type === 'chip'` exactly, never on "not a known control type", so an
+  unrecognized `type` still falls back to `<lr-select>` as before. At the type level, a `'chip'` filter
+  keeps the full unconstrained field value in `LyraFilterBarValueFor<Defs>`, like `'custom'`. New
+  exported type: `LyraFilterBarChipDefinition`.
+- af5a12e: `<lr-map>` gains an opt-in interactive legend, so a categorical point layer's key can double as its
+  layer switch instead of needing a hand-built checkbox group positioned over the canvas.
+  
+  `legendInteractive` (attribute `legend-interactive`, default `false`) turns every legend row that
+  carries the new `LyraMapLegendEntry.value` category key into a keyboard-operable toggle button.
+  `value` is the same string a `point.colors` / `point.icons` record matches against
+  `point.field` / `point.iconField`, so one set of category records can feed both the paint and the
+  key and the two cannot drift. It is distinct from — and does not derive from — the `value` on a
+  row's `icon` record, which is still dropped from the canonical readback as before. Rows without a
+  `value` stay inert even when `legendInteractive` is set.
+  
+  `hiddenCategories: readonly string[]` is the controlled state, mirroring `<lr-chart>`'s
+  `hiddenDatasets`, and is honoured on first render rather than only after a user toggle. Activating a
+  toggle emits a cancelable `lr-map-legend-toggle` carrying the activated key, its proposed
+  visibility, and the complete proposed hidden set; `preventDefault()` is a real veto — nothing is
+  written, the row's `aria-pressed` does not change, the map is not repainted, and no announcement is
+  made — so a host can own the state itself. A programmatic `hiddenCategories` assignment reconciles
+  silently and emits nothing.
+  
+  A hidden category's points, point icons and stroke are muted in the rendered MapLibre layers
+  through the new `--lr-map-hidden-category-opacity` (default `0.15`), resolved live from the cascade
+  because MapLibre paints to a WebGL canvas that never sees `var()`. The legend row itself dims only
+  its decorative swatch (`--lr-map-legend-hidden-swatch-opacity`, default `0.5`) and re-colors its
+  label through the quiet-text token, so the label keeps WCAG AA contrast rather than fading with the
+  swatch. New parts: `legend-toggle` and `legend-toggle-hidden`.
+  
+  Each toggle is an ordinary tabbable `<button>` with `aria-pressed` rendering both `"true"` and
+  `"false"`, matching `<lr-chart>` and `<lr-graph-legend>` rather than introducing a third legend
+  vocabulary; a long interactive legend therefore contributes one tab stop per keyed row. Show/hide
+  state changes are announced through the shared light-DOM live region.
+  
+  With `legendInteractive` left unset, the legend DOM and every MapLibre paint property are
+  byte-identical to before: no button is rendered and `circle-opacity` is never written at all.
+- 3024e74: Added a complete Romanian (`ro`) translation catalog, the twelfth full locale to ship with the
+  package. Like every other locale, it is split into twelve side-effect-only per-family slices
+  (`@aceshooting/lyra-ui/translations/ro/<family>.js`) plus the back-compat aggregate
+  `@aceshooting/lyra-ui/translations/ro.js`, covering all 1,291 keys in `LYRA_DEFAULT_STRINGS`
+  (including the 14 pluralized entries). Romanian's CLDR plural category set is `one`/`few`/`other`
+  rather than English's `one`/`other` — `few` covers `0` and `2`-`19` (and the `101`-`119`-per-hundred
+  band), while `other` is the `de`-requiring form from `20` upward (`"20 de rezultate"` vs.
+  `"2 rezultate"`) — so every pluralized message was authored with all three categories rather than
+  widening `few` to `other`.
+- 9db9165: `<lr-select>` gains `loading` (default `false`, reflected). A committed value whose catalog hasn't
+  arrived yet -- `<lr-option>`s still being fetched/mounted asynchronously -- previously had no way to
+  distinguish itself from a genuinely stale value: both rendered the raw value string badged
+  dashed/italic `notInCatalog`. Setting `loading` while the matching option is still pending instead
+  renders the localized `loading` placeholder, with no `unknown-value` badge and no synthetic
+  `showUnknownOption` listbox row, in the trigger label or the relevant `multiple`-mode tag. Once the
+  matching `<lr-option>` mounts, the real label renders automatically on the next render, with or
+  without also flipping `loading` back to `false`. A value that already matches a live option, and
+  every existing `loading`-unset unknown-value/`getUnknownLabel` behavior, is unchanged.
+- 1942512: `<lr-streaming-text>`/`<lr-streaming-text-core>` now forward their composed
+  `<lr-markdown>`/`<lr-markdown-core>`'s documented CSS parts (`content`, `heading`, `paragraph`,
+  `list`, `code-block`, `inline-code`, `link`, `table`, `blockquote`, `img`, `math`) through
+  `exportparts`, reusing each name verbatim since none collides with either wrapper's own `base`/
+  `cursor` parts. A host-level `lr-streaming-text::part(link)`/`::part(img)` (or the `-core` variant's
+  equivalent) rule now reaches the rendered `<a>`/`<img>` the same way it already does applied
+  directly to `<lr-markdown>`/`<lr-markdown-core>` -- previously that styling surface was unreachable
+  from outside either wrapper's own shadow boundary.
+- c78f78c: `<lr-virtual-list>` gains `row-projection`, an opt-in light-DOM row projection mode, so an
+  application whose list rows are already styled by its own global stylesheet can adopt virtualization
+  without rehoming every row rule.
+  
+  Until now `renderItem`'s output was stamped inside the component's shadow root, so document CSS
+  could not reach row content: adopting virtualization meant moving a dozen descendant rules per row
+  into a new custom element or a growing set of custom properties — a stylesheet refactor, paid
+  exactly by the lists long enough to need virtualizing. With `row-projection="light"` the windowed
+  rows are rendered into the host's own light DOM and assigned into the shadow viewport through
+  internal named slots. The component keeps owning windowing, measurement, spacer sizing,
+  `scrollToIndex()`, the external-scroller mode and the ARIA contract; the consumer keeps owning the
+  row markup and its cascade, and ordinary document CSS styles a virtualized row exactly as it styles
+  the same row unvirtualized.
+  
+  Positioning stays on the shadow-side `[part="row"]` wrapper, which the document cannot select, so
+  windowing is not overridable by consumer CSS and the whole existing part vocabulary — `base`,
+  `spacer`, `row`, `group`, `sticky-group` — keeps matching in both modes.
+  
+  Costs, stated plainly rather than hidden:
+  
+  - Each projected row sits inside one component-owned wrapper element carrying the reserved
+    `data-lr-virtual-list-row` attribute (exported as `VIRTUAL_LIST_ROW_ATTRIBUTE`; the sticky band's
+    counterpart is `VIRTUAL_LIST_STICKY_ATTRIBUTE`). Descendant selectors port unchanged; child
+    combinators, `:nth-child`, `:first-child` and sibling combinators written against unvirtualized
+    markup do not, and `:nth-child` reflects the current window rather than the item index.
+  - A delegated listener on the host now sees an un-retargeted `event.target`, so
+    `closest('[part="row"]')` no longer resolves — use `closest('[data-lr-virtual-list-row]')`.
+  - The document cascade now reaches row content, including resets that previously could not.
+  - Per-row light-DOM state does not survive a disconnect/reconnect, because disconnect removes the
+    projected rows completely.
+  - On a hydrated page the first window is shadow-rendered for one task before it swaps into the
+    light DOM, so server markup and the first client render agree.
+  
+  `rowProjection` is `'shadow'` by default. Left unset, every existing list renders byte-identically
+  and the host's light DOM stays empty.
+
+### Patch Changes
+
+- ce460db: **Documentation: `aria-pressed` stopped reaching a link button (`href` set) in 16.0.0 — recorded
+  here because 16.0.0 filed it where nobody would find it.**
+  
+  No behaviour changes in this release. This entry exists because the change itself shipped without a
+  discoverable release note, and a consumer pinning the old contract met it as an unexplained test
+  failure after a dependency bump.
+  
+  **What changed, and when.** Through 15.0.0, `<lr-button>`, `<lr-icon-button>` and `<lr-card>`
+  forwarded a host `aria-pressed` onto the `<a>` they render when `href` is set. Since **16.0.0** they
+  do not: `aria-pressed` reaches the `<button>` rendering only. `role="link"` has no pressed state, so
+  forwarding it there asserted an ARIA state that does not exist on that role — an ARIA conformance
+  failure, not a feature. The behaviour is correct and is not being reverted.
+  
+  This narrowed a documented forwarding contract, so it was a **breaking change** for anyone relying
+  on the old behaviour, and it should have been filed as one. 16.0.0 did describe it, but as the third
+  sub-heading of a long `<lr-card>` disabled-state entry whose opening sentence never mentions
+  `<lr-button>` — so neither scanning the release notes for button changes nor reading a per-component
+  digest surfaced it.
+  
+  **Migration.** If the control is a real toggle, drop `href` — the same host `aria-pressed` then
+  reaches the `<button>` that replaces the anchor, and the pressed state is exposed again. If it is a
+  navigation target, use the global `aria-current` (`page`, `step`, `location`, `date`, `time`,
+  `true`, `false`) instead: that one is valid on `role="link"` and does still reach the anchor.
+  
+  The `lr-button`, `lr-icon-button` and `lr-card` reference sections now name 16.0.0 as the version
+  the carve-out landed in, so the rule can be dated from the reference alone.
+- 87d02cb: Fixed `<lr-reorder-list>`'s documented Ctrl/Cmd+ArrowUp/ArrowDown shortcut so it fires from real
+  keyboard focus on a row's own move button, not only when a `keydown` happens to be dispatched
+  synthetically on the button's host element. The move buttons are composed `<lr-icon-button>`s, so
+  real DOM focus during ordinary keyboard use lands on that button's own native `<button>` — one
+  shadow boundary deeper than `<lr-reorder-item>`'s own shadow root. The exclusion predicate that
+  tells the row's own chrome apart from a consumer's nested control only recognized an element whose
+  root node was exactly the item's shadow root, so the nested native button fell through to the
+  generic `name === 'button'` exclusion and every Ctrl/Cmd+Arrow press starting from real focus on a
+  move button was discarded as though it had come from a consumer's own control.
+- 87d02cb: Fixed `<lr-reorder-list>` in `controlled` mode so it no longer steals focus back to the moved row
+  when the consumer has deliberately moved focus elsewhere while an async `finalizePendingMove()` /
+  host reconciliation is still in flight. Previously the post-move focus restore unconditionally
+  focused the moved row's move button once the host's re-render settled, even when the consumer had
+  already moved focus to an unrelated control on the page in the meantime — overriding that
+  deliberate choice. The restore now only runs when the pre-restore focus was still somewhere inside
+  this list, or there was nothing meaningful to preserve (nothing focused, or the previously-focused
+  node was disconnected by the host's own reconciliation); a still-connected external focus target
+  is left alone.
+- cada7da: `<lr-table>`'s `editType: 'select'` cell editor now shows a themed disclosure chevron instead of
+  looking like a plain text field. `appearance: none` on `select[part='cell-editor']` removed the
+  native arrow with no replacement; the glyph is repainted on the enclosing `[part='cell']` (a bare
+  `<select>` cannot host a decorative child, and a `mask` can't apply to the select itself without
+  clipping its own text), using the same mask + `background: currentColor` technique already shipped
+  for the map attribution-toggle glyph, positioned at the logical inline-end edge so it mirrors
+  correctly under `dir="rtl"` and survives `forced-colors: active`. The `text`/`number` cell editors
+  are unaffected.
+- e4402ef: Fixed `<lr-thread-list>` data-mode rows so choosing a `renderActions`-rendered menu action (for
+  example a consumer's `<lr-dropdown>` containing an `<lr-menu>`) no longer also fires the row's own
+  `lr-select` and selects/opens the conversation. The row's `lr-select` listener previously reacted to
+  any `lr-select`-named event that bubbled through the `<lr-conversation-item>`, including one
+  coincidentally emitted by a `renderActions`-rendered descendant (`<lr-menu>` fires its own
+  `lr-select` on item choice). It now only treats the event as row activation when it was dispatched
+  directly on the `<lr-conversation-item>` itself (`e.target === e.currentTarget`), which is how a
+  real row click/keyboard activation always dispatches it; a descendant's bubbled event is still
+  absorbed at the row boundary (as before) but no longer re-emitted as the row's own selection.
+
 ## 17.0.0
 
 ### Major Changes

package/README.md

@@ -476,11 +476,11 @@ registerLyraLocale("en", {
 });
 ```
 
-Eleven translation catalogs now ship as side-effect-only modules, so a common locale no longer needs a
+Twelve translation catalogs now ship as side-effect-only modules, so a common locale no longer needs a
 hand-written catalog at all:
 
 ```js
-import "@aceshooting/lyra-ui/translations/fr.js"; // also ar, de, es, fa, he, it, ja, pt-BR, ru, zh-CN
+import "@aceshooting/lyra-ui/translations/fr.js"; // also ar, de, es, fa, he, it, ja, pt-BR, ro, ru, zh-CN
 ```
 
 Each locale also ships as twelve smaller per-family slices, so an app using only a handful of