ngwr 14.3.1 → 14.4.0

package/types/ngwr-squircle.d.ts

@@ -41,6 +41,20 @@ type WrSquircleCornerMask = 'all' | 'left' | 'right' | 'top' | 'bottom' | 'none'
  * Apply a Figma-style smooth-corner ("squircle") `clip-path` to the host
  * element. Re-computes the path whenever the element resizes.
  *
+ * @deprecated Use the native route instead — `@use 'ngwr/theme'` and the
+ * `smooth-br` mixin, which 31 entry points already ride by default. This
+ * directive exists because `corner-shape` was Chromium-only, and that reason
+ * has an expiry date: WebKit has it in Technology Preview. It will be removed
+ * in the major after Safari stable ships the property.
+ *
+ * It is deprecated rather than removed today because it is still the only
+ * DETERMINISTIC squircle — the native property reaches roughly two thirds of
+ * users and the rest see a rounded corner. If that difference matters to a
+ * design, this is still the way to get it, with the costs stated: a hand-ported
+ * superellipse, a `ResizeObserver` and a `getBoundingClientRect` per host on
+ * every resize, square corners until hydration under SSR, no test harness, and
+ * a clip that `box-shadow`, `border-image` and the focus ring do not follow.
+ *
  * Borders: pass `[borderWidth]` (px) + `[borderColor]` and the directive
  * paints a `::before` pseudo with an *inset* squircle path on top of the
  * host. The visible border is the host's own background colour, so set
@@ -92,9 +106,11 @@ declare class WrSquircle {
      * only the two corners on the named side and leave the other two at
      * 90°. `'none'` is equivalent to disabling the directive.
      *
-     * Modelled so parent components composing the directive can flip the
-     * value imperatively — used by `WrButtonGroup` to squircle only the
-     * outer corners of the first / last child.
+     * A `model()` rather than an `input()` so a parent composing the directive
+     * can flip it imperatively. Nothing in the library does today: this line
+     * used to name `WrButtonGroup` as the consumer, and that component has
+     * carried no squircle reference for several releases — `wr-btn--squircle`
+     * is plain CSS now.
      *
      * @default 'all'
      */
@@ -122,6 +138,9 @@ declare class WrSquircle {
  * ```
  *
  * @see https://ngwr.dev/reference/components/squircle
+ *
+ * @deprecated Follows `[wrSquircle]`, which it wraps — see that directive
+ * for why, and for the native route to use instead.
  */
 declare class WrSquircleHost {
     static ɵfac: _angular_core.ɵɵFactoryDeclaration<WrSquircleHost, never>;

package/types/ngwr-statistic.d.ts

@@ -128,7 +128,6 @@ declare class WrStatisticCountdown {
     readonly tickMs: _angular_core.InputSignalWithTransform<number, unknown>;
     /** Fires once when the countdown crosses zero. */
     readonly countdownEnd: _angular_core.OutputEmitterRef<void>;
-    private readonly destroyRef;
     private readonly isBrowser;
     private readonly targetMs;
     /**

package/types/ngwr-storage.d.ts

@@ -94,7 +94,7 @@ declare class WrStorage {
     private rawKeys;
     private installCrossTabListener;
     static ɵfac: i0.ɵɵFactoryDeclaration<WrStorage, never>;
-    static ɵprov: i0.ɵɵInjectableDeclaration<WrStorage>;
+    static ɵprov: i0.ɵɵInjectableDeclaration<any>;
 }
 
 /**

package/types/ngwr-theme.d.ts

@@ -219,7 +219,7 @@ declare class WrTheme {
     private readPersisted;
     private persist;
     static ɵfac: i0.ɵɵFactoryDeclaration<WrTheme, never>;
-    static ɵprov: i0.ɵɵInjectableDeclaration<WrTheme>;
+    static ɵprov: i0.ɵɵInjectableDeclaration<any>;
 }
 
 /**

package/types/ngwr-toast.d.ts

@@ -238,7 +238,7 @@ declare class WrToast {
     private pushToHost;
     private disposeHost;
     static ɵfac: i0.ɵɵFactoryDeclaration<WrToast, never>;
-    static ɵprov: i0.ɵɵInjectableDeclaration<WrToast>;
+    static ɵprov: i0.ɵɵInjectableDeclaration<any>;
 }
 
 /**

package/types/ngwr-tour.d.ts

@@ -126,7 +126,7 @@ declare class WrTour {
      */
     private isRtl;
     static ɵfac: _angular_core.ɵɵFactoryDeclaration<WrTour, never>;
-    static ɵprov: _angular_core.ɵɵInjectableDeclaration<WrTour>;
+    static ɵprov: _angular_core.ɵɵInjectableDeclaration<any>;
 }
 
 /** What the popup needs from the running tour, without importing the service (cycle). */

package/types/ngwr-transfer.d.ts

@@ -114,6 +114,17 @@ declare class WrTransfer implements FormValueControl<readonly unknown[]> {
     protected readonly resolvedSearch: _angular_core.Signal<string>;
     protected readonly resolvedEmpty: _angular_core.Signal<string>;
     protected readonly resolvedSelectAll: _angular_core.Signal<string>;
+    /**
+     * The select-all checkbox's accessible name, composed IN THE CATALOG.
+     *
+     * It used to be a template literal — `` `${title} — ${selectAll}` `` — which
+     * froze both the separator and the operand order into English. A translator
+     * could change each half and not the sentence they make, which is the exact
+     * defect the calendar and event-calendar catalogs were rewritten to remove.
+     * The key ships as `{{pane}} — {{action}}` in every locale, so nothing reads
+     * differently today and every locale can now reorder it without a code change.
+     */
+    protected readonly selectAllAria: (params?: ngwr_i18n.WrI18nParams) => string;
     protected readonly resolvedToTarget: _angular_core.Signal<string>;
     protected readonly resolvedToSource: _angular_core.Signal<string>;
     /** `{{checked}} / {{total}}` under each heading. @internal */
@@ -129,6 +140,23 @@ declare class WrTransfer implements FormValueControl<readonly unknown[]> {
     private readonly valueSet;
     protected readonly source: _angular_core.Signal<PaneState>;
     protected readonly target: _angular_core.Signal<PaneState>;
+    /**
+     * Say something when `value` holds a value no `items` entry matches.
+     *
+     * Such a value is in NEITHER pane — the left one filters out anything already
+     * selected and the right one can only render rows it found — and the header
+     * counts the rows it shows, so nothing on screen contradicts anything. The
+     * result is a value the user can neither see nor remove, and no sign that it
+     * is there.
+     *
+     * A warning rather than an invented row, which matches how the library treats
+     * the same question elsewhere: `wr-select` renders a value outside its option
+     * list only under an explicit `freeText`, so an unmatched value is a mode a
+     * consumer opts into, not a shape a component guesses at. It also stays quiet
+     * about the common transient case — `items` arriving after `value` — because
+     * the message names the values and a developer can see them settle.
+     */
+    private warnAboutOrphans;
     protected readonly canMoveRight: _angular_core.Signal<boolean>;
     protected readonly canMoveLeft: _angular_core.Signal<boolean>;
     protected readonly classes: _angular_core.Signal<string>;
@@ -137,6 +165,30 @@ declare class WrTransfer implements FormValueControl<readonly unknown[]> {
     /** Header checkbox — stages or clears every enabled row the filter shows. */
     protected toggleAll(pane: 'source' | 'target', checked: boolean): void;
     protected onSearch(pane: 'source' | 'target', event: Event): void;
+    private readonly host;
+    private readonly injector;
+    /**
+     * Keep focus in the widget after a move.
+     *
+     * A move empties the pane's staging set, which is exactly what disables the
+     * button that was just pressed — so the element holding DOM focus went
+     * `disabled` as a RESULT of its own activation and the browser dropped focus
+     * to `<body>`. From there the next Tab restarts at the top of the document,
+     * which for a keyboard user is being thrown out of a control they were in the
+     * middle of using.
+     *
+     * The landing is the FIRST ROW OF THE PANE THE ROWS ARRIVED IN, and the
+     * obvious alternative does not work: after a move BOTH buttons are disabled,
+     * because each needs something ticked and the move cleared the tick on one
+     * side and arrived unticked on the other. The rows that just moved are where
+     * the user's attention is and where the next action lives, so that is where
+     * focus goes.
+     *
+     * `afterNextRender`, not `queueMicrotask`: under zoneless CD the microtask
+     * runs before the moved rows are in the DOM, so the focus call would land on
+     * the pane as it was before the move.
+     */
+    private restoreFocusAfterMove;
     protected moveRight(): void;
     protected moveLeft(): void;
     /** Filter, then derive the header state from what survived. */

package/types/ngwr-tree-testing.d.ts

@@ -358,6 +358,26 @@ declare class WrTreeHarness extends ContentContainerComponentHarness {
     removeChip(label: string): Promise<void>;
     /** Click the clear (×) control on the trigger. */
     clear(): Promise<void>;
+    /**
+     * Backspace on the closed overlay trigger — the keyboard route to the ×.
+     *
+     * In single mode it clears (only while `clearable` is on); in multi mode it
+     * drops the LAST chip, one per call, whatever `clearable` says. Both ×
+     * controls are `tabindex="-1"` spans inside the trigger, so a key can never
+     * reach them directly. In single mode this is the ONLY keyboard route back to
+     * no selection; in multi mode a keyboard user can also toggle a row off in the
+     * panel ({@link selectNode} with `additive`). {@link clear} / {@link removeChip}
+     * prove the pointer path and nothing more.
+     *
+     * The key is honoured only on the CLOSED trigger, so an open panel is closed
+     * first with Escape — the step a keyboard user takes too, since focus sits in
+     * the panel while it is up.
+     *
+     * Does nothing, rather than throwing, where the component does nothing —
+     * nothing selected, disabled or read-only — so a spec asserts the outcome on
+     * the value.
+     */
+    clearByKeyboard(): Promise<void>;
     /**
      * The nodes currently rendered, in the order they are shown.
      *

package/types/ngwr-tree.d.ts

@@ -291,7 +291,48 @@ declare class WrTree<TId = string> implements FormValueControl<unknown> {
     protected onKeydown(event: KeyboardEvent): void;
     protected onTriggerClick(): void;
     /** Trigger blur — mark the bound field touched. */
+    /**
+     * Leaving an INLINE tree marks it touched.
+     *
+     * `onBlur` below belongs to the overlay trigger, which only renders under
+     * `openOn="overlay"` — so an inline tree emitted `touch` on SELECTION and
+     * nowhere else. Focusing it and walking away without choosing anything left
+     * the control neither touched nor dirty, which is exactly the state a
+     * `<wr-form-field>` waits for before it will show a message: a `required`
+     * tree the user considered and skipped stayed silent, and the form looked
+     * fine while being invalid.
+     *
+     * `relatedTarget` inside the host means focus only moved BETWEEN rows, which
+     * is not leaving. A `null` one — clicking the page background, or a browser
+     * that withholds it — counts as leaving, which is the safe direction: marking
+     * touched too eagerly shows a message the field already had grounds for.
+     */
+    protected onFocusOut(event: FocusEvent): void;
     protected onBlur(): void;
+    /**
+     * Backspace on the CLOSED overlay trigger — the keyboard twin of the two ×
+     * controls inside it.
+     *
+     * Both the clear × and every chip's remove × are `tabindex="-1"` spans inside
+     * this `<button>`, and they carried `(keydown.enter)` / `(keydown.space)`
+     * bindings that could never fire: a keydown goes to the focused element, and
+     * those spans cannot be focused. The spans stay unfocusable, since a focusable
+     * child of a button is `nested-interactive`.
+     *
+     * What that cost differs by mode, and the difference is worth keeping straight.
+     * In SINGLE mode it was a real WCAG 2.1.1 failure: Enter on the selected row
+     * re-selects it, so the × was the only way back to nothing. In MULTI mode it
+     * was not — Ctrl/Cmd+Enter on a row in the panel toggles it off, which is the
+     * route {@link WrTreeHarness.selectNode} drives with `additive`. The multi
+     * branch below is parity with `wr-select` and a shorter path, not a repair.
+     *
+     * The same key and the same split `wr-select` uses, so the two read alike:
+     * in MULTI mode Backspace drops the last chip — chip removal is its own
+     * control, not gated on `clearable()` — and in SINGLE mode it clears, gated on
+     * `clearable()`, because that input IS the clear control. Only while closed:
+     * an open panel owns the keyboard.
+     */
+    protected onTriggerKey(event: KeyboardEvent): void;
     protected removeChip(id: TId, event: Event): void;
     protected clearSelection(event: Event): void;
     private toggleExpanded;

package/types/ngwr-version.d.ts

@@ -16,7 +16,7 @@ import { InjectionToken } from '@angular/core';
  * Distinct from `Version` exported by `@angular/core`, which reports the
  * loaded Angular runtime version (e.g. `'22.0.0'`), not ngwr's.
  */
-declare const NGWR_VERSION = "14.3.1";
+declare const NGWR_VERSION = "14.4.0";
 
 /**
  * @license

package/types/ngwr-window.d.ts

@@ -467,7 +467,7 @@ declare class WrWindowManager {
     /** Drop a saved workspace. */
     clearLayout(name: string): void;
     static ɵfac: _angular_core.ɵɵFactoryDeclaration<WrWindowManager, never>;
-    static ɵprov: _angular_core.ɵɵInjectableDeclaration<WrWindowManager>;
+    static ɵprov: _angular_core.ɵɵInjectableDeclaration<any>;
 }
 
 /**

package/typography/styles/_index.scss

@@ -149,17 +149,39 @@
     }
   }
 
-  // Links — flowbite default: medium weight, brand color, underline on
-  // hover. Add your own `underline` class for the always-underlined look.
+  // Links are underlined ALWAYS, and the underline is the whole point rather
+  // than a style preference.
+  //
+  // WCAG technique G183 lets a link be marked by colour alone only when it
+  // clears 3:1 against the prose around it. `--wr-color-primary-ink` on
+  // `--wr-color-on-surface` measures 2.72:1 in LIGHT, so it never did — the
+  // underline was the missing half, and putting it on `:hover` gave it to a
+  // mouse and to nobody else. `ngwr/markdown` had this right all along, which
+  // made the library disagree with itself about its own links.
+  //
+  // The dark figure is deliberately not quoted here: `-ink` is a `color-mix`
+  // there, so it cannot be read off the source, and a hand-composited guess is
+  // the mistake `_colors.scss` already warns about. `check:contrast` measures
+  // it in a browser; the underline does not depend on the answer either way.
+  //
+  // Hover thickens rather than adds, so the interaction still answers. And the
+  // focus ring is here because it was nowhere: this variant is the one piece of
+  // typography that is reliably INTERACTIVE, and it had no `:focus-visible`
+  // rule at all, so a keyboard reached it and nothing on screen said so.
   &--link {
     font-weight: var(--wr-font-weight-medium);
     color: var(--wr-color-primary-ink);
-    text-decoration: none;
+    text-decoration: underline;
+    text-decoration-thickness: 1px;
     text-underline-offset: 2px;
     cursor: pointer;
 
     &:hover {
-      text-decoration: underline;
+      text-decoration-thickness: 2px;
+    }
+
+    &:focus-visible {
+      @include theme.focus-ring;
     }
   }