@juspay/svelte-ui-components 4.27.5 → 4.28.0

package/dist/_chart/temporal.js

@@ -0,0 +1,116 @@
+/**
+ * Documented, tested calendar-tick helpers for the temporal limitation in
+ * Line/AreaChart's x axis -- see docs/CHART_INPUT_POLICY.md#calendar--temporal-axes
+ * for the full policy this satisfies.
+ *
+ * Line/AreaChart's x axis is a plain numeric linear scale (`createLinearScale`
+ * in `./scales`). Epoch-millisecond x values preserve relative distance --
+ * `t2 - t1` still means the same thing in pixels as it does in time -- but
+ * `computeLinearTicks`'s "nice round number" ticks are not calendar-aware:
+ * they land on values like 1_700_000_000_000 or a rounded step in
+ * milliseconds, not on UTC midnight/week/month boundaries. `xTickFormat`
+ * only changes how a tick's existing numeric position is labelled; it cannot
+ * move that position onto a calendar boundary, and neither chart accepts an
+ * explicit tick-position override today (`Axis.svelte`, shared by every chart
+ * type in this package, always derives its own tick positions from the
+ * scale) -- wiring one in is deliberately out of scope here, since it would
+ * change a contract every other chart consumes, not just these two.
+ *
+ * `computeUtcTicks`/`formatUtcTick` are the disclosed alternative: pure,
+ * fully-tested functions a caller can use to compute correct UTC calendar
+ * tick positions and labels for their own presentation (a custom axis
+ * overlay, a legend of period boundaries, or pre-bucketing data into
+ * calendar-aligned x values before it ever reaches the chart). They do not
+ * replace the chart's linear scale with array indices, and they impose
+ * nothing on a caller who does not import this module -- both charts behave
+ * exactly as before.
+ */
+const MS_PER_DAY = 86_400_000;
+const MONTH_NAMES = [
+    'Jan',
+    'Feb',
+    'Mar',
+    'Apr',
+    'May',
+    'Jun',
+    'Jul',
+    'Aug',
+    'Sep',
+    'Oct',
+    'Nov',
+    'Dec'
+];
+function startOfUtcDay(ms) {
+    const d = new Date(ms);
+    return Date.UTC(d.getUTCFullYear(), d.getUTCMonth(), d.getUTCDate());
+}
+function startOfUtcMonth(ms) {
+    const d = new Date(ms);
+    return Date.UTC(d.getUTCFullYear(), d.getUTCMonth(), 1);
+}
+/**
+ * Computes UTC calendar-aligned tick positions (epoch ms) covering
+ * `[domain[0], domain[1]]`. `unit` picks the calendar grain; ticks are
+ * thinned so the count stays at or under `maxTicks` (mirrors Line/AreaChart's
+ * own tick-count capping).
+ *
+ * Returns `[]` for a non-finite or inverted domain -- callers pass this
+ * straight into `xTicks`, and an empty array there just falls back to no
+ * override (see LineChart/AreaChart docs).
+ */
+export function computeUtcTicks(domain, unit, maxTicks = 8) {
+    const [minMs, maxMs] = domain;
+    if (!Number.isFinite(minMs) || !Number.isFinite(maxMs) || maxMs < minMs) {
+        return [];
+    }
+    if (unit === 'month') {
+        const approxMonths = Math.max(1, Math.round((maxMs - minMs) / (MS_PER_DAY * 30)));
+        const stepMonths = Math.max(1, Math.ceil((approxMonths + 1) / maxTicks));
+        const ticks = [];
+        let cursor = startOfUtcMonth(minMs);
+        // Bounded by the month count rather than a time delta -- months vary in
+        // length, so stepping by calendar month (not a fixed ms step) is what
+        // makes these boundaries actually land on the 1st in UTC.
+        let guard = 0;
+        while (cursor <= maxMs && guard < 10_000) {
+            ticks.push(cursor);
+            const d = new Date(cursor);
+            cursor = Date.UTC(d.getUTCFullYear(), d.getUTCMonth() + stepMonths, 1);
+            guard++;
+        }
+        return ticks;
+    }
+    const stepDays = unit === 'week' ? 7 : 1;
+    const stepMs = stepDays * MS_PER_DAY;
+    const spanSteps = Math.max(1, (maxMs - minMs) / stepMs);
+    const thinning = Math.max(1, Math.ceil(spanSteps / maxTicks));
+    const ticks = [];
+    let cursor = startOfUtcDay(minMs);
+    let i = 0;
+    let guard = 0;
+    while (cursor <= maxMs && guard < 10_000) {
+        if (i % thinning === 0) {
+            ticks.push(cursor);
+        }
+        cursor += stepMs;
+        i++;
+        guard++;
+    }
+    return ticks;
+}
+/**
+ * Formats an epoch-ms tick value produced by `computeUtcTicks` as a UTC
+ * calendar label ("Mar 4" for day/week, "Mar 2026" for month). Pass as
+ * `xTickFormat` alongside `xTicks={computeUtcTicks(...)}`.
+ */
+export function formatUtcTick(value, unit = 'day') {
+    if (!Number.isFinite(value)) {
+        return '';
+    }
+    const d = new Date(value);
+    const month = MONTH_NAMES[d.getUTCMonth()];
+    if (unit === 'month') {
+        return `${month} ${d.getUTCFullYear()}`;
+    }
+    return `${month} ${d.getUTCDate()}`;
+}

package/dist/_field/description.d.ts

@@ -0,0 +1,50 @@
+/**
+ * The link between a form control and the text that explains it.
+ *
+ * `Input` got this right and was the only one: it derives an id per message,
+ * composes `aria-describedby` from the messages that are actually on screen, and
+ * sets `aria-invalid` only while an error is showing. Across Select, Combobox,
+ * ChipInput, SplitInput, Slider, Radio, Checkbox, Toggle, Choicebox, ColorPicker
+ * and FileInput there was not one `aria-describedby` and not one `aria-invalid`;
+ * DateRangePicker had eight `aria-invalid` and no `aria-describedby` at all, so
+ * it could announce that a date was wrong while linking nothing that said why.
+ *
+ * Two rules are easy to get wrong and are the reason this is shared rather than
+ * copied:
+ *
+ * - **Reference only ids that exist.** `aria-describedby="x-error"` pointing at
+ *   an element that is not rendered passes any attribute-presence assertion and
+ *   silently resolves to nothing in a real screen reader. So the id is included
+ *   only while its message is being rendered, and the caller must render each
+ *   message under the same condition.
+ * - **`aria-invalid` means invalid now**, not "this control can be invalid". A
+ *   control that carries it permanently tells a user every field is broken.
+ */
+export type FieldMessages = {
+    /** Text shown when the control is in error. Empty or null means no error. */
+    readonly error?: string | null;
+    /** Persistent helper text describing the control. */
+    readonly info?: string | null;
+    /**
+     * Forces the error state on for consumers driving validity from a server or
+     * their own rules, independently of any message.
+     */
+    readonly invalid?: boolean;
+};
+export type FieldDescription = {
+    /** Id for the error element. Render it only when `showsError` is true. */
+    readonly errorId: string;
+    /** Id for the helper element. Render it only when `showsInfo` is true. */
+    readonly infoId: string;
+    readonly showsError: boolean;
+    readonly showsInfo: boolean;
+    /** For `aria-describedby`; null when there is nothing to reference. */
+    readonly describedBy: string | null;
+    /** For `aria-invalid`; null rather than "false" so the attribute is absent. */
+    readonly ariaInvalid: 'true' | null;
+};
+/**
+ * @param id The control's own id. Message ids are derived from it so two
+ *   controls on one page cannot collide.
+ */
+export declare function describeField(id: string, messages: FieldMessages): FieldDescription;

package/dist/_field/description.js

@@ -0,0 +1,51 @@
+/**
+ * The link between a form control and the text that explains it.
+ *
+ * `Input` got this right and was the only one: it derives an id per message,
+ * composes `aria-describedby` from the messages that are actually on screen, and
+ * sets `aria-invalid` only while an error is showing. Across Select, Combobox,
+ * ChipInput, SplitInput, Slider, Radio, Checkbox, Toggle, Choicebox, ColorPicker
+ * and FileInput there was not one `aria-describedby` and not one `aria-invalid`;
+ * DateRangePicker had eight `aria-invalid` and no `aria-describedby` at all, so
+ * it could announce that a date was wrong while linking nothing that said why.
+ *
+ * Two rules are easy to get wrong and are the reason this is shared rather than
+ * copied:
+ *
+ * - **Reference only ids that exist.** `aria-describedby="x-error"` pointing at
+ *   an element that is not rendered passes any attribute-presence assertion and
+ *   silently resolves to nothing in a real screen reader. So the id is included
+ *   only while its message is being rendered, and the caller must render each
+ *   message under the same condition.
+ * - **`aria-invalid` means invalid now**, not "this control can be invalid". A
+ *   control that carries it permanently tells a user every field is broken.
+ */
+const hasText = (value) => typeof value === 'string' && value !== '';
+/**
+ * @param id The control's own id. Message ids are derived from it so two
+ *   controls on one page cannot collide.
+ */
+export function describeField(id, messages) {
+    const errorId = `${id}-error`;
+    const infoId = `${id}-info`;
+    // An explicit `invalid` with no message still marks the control invalid --
+    // that is what forceError means -- but it cannot be described by an element
+    // that will not be rendered.
+    const showsError = hasText(messages.error ?? null);
+    const showsInfo = hasText(messages.info ?? null);
+    const referenced = [];
+    if (showsError) {
+        referenced.push(errorId);
+    }
+    if (showsInfo) {
+        referenced.push(infoId);
+    }
+    return {
+        errorId,
+        infoId,
+        showsError,
+        showsInfo,
+        describedBy: referenced.length > 0 ? referenced.join(' ') : null,
+        ariaInvalid: showsError || messages.invalid === true ? 'true' : null
+    };
+}

package/dist/_interaction/dismissal.d.ts

@@ -0,0 +1,67 @@
+/**
+ * Who owns a dismissal, when several overlays are open at once.
+ *
+ * Before this module each overlay listened wherever suited it: Modal on the
+ * window, Sheet only on its own overlay element, Menu and ContextMenu on the
+ * document, CommandMenu on the window again. Nothing coordinated them, so one
+ * Escape reached every listener and a menu opened inside a modal closed both --
+ * the menu the user meant, and the modal behind it they did not.
+ *
+ * Ownership here is an explicit registration order, not something inferred from
+ * DOM nesting. Nesting is the wrong signal: a portaled dropdown is a sibling of
+ * the modal it visually sits inside, and a menu anchored in the light DOM is not
+ * a descendant of the shadow root that opened it. What actually decides which
+ * overlay a dismissal belongs to is which one opened last, and only the overlay
+ * itself knows when that happened -- so it says so, and says so again when it
+ * closes.
+ *
+ * Registration returns its own release function rather than exposing the stack,
+ * so a layer can only ever remove itself, and removal from the middle is safe:
+ * an overlay that closes underneath another leaves the one above it topmost.
+ */
+export type DismissibleLayer = {
+    /**
+     * What counts as "inside" this layer, read at event time rather than captured
+     * at registration -- the element frequently does not exist yet when a layer
+     * registers, and can be replaced while it stays open.
+     */
+    readonly element: () => Node | null;
+    /** Escape was pressed while this layer was topmost. */
+    readonly onEscape?: () => void;
+    /** A pointer went down outside this layer while it was topmost. */
+    readonly onOutside?: (event: Event) => void;
+};
+/**
+ * Registers `layer` as the topmost dismissible surface and returns the function
+ * that removes it again. Calling that function more than once is harmless.
+ */
+export declare function registerDismissible(layer: DismissibleLayer): () => void;
+/** How many layers are currently registered. Exists for tests and diagnostics. */
+export declare function dismissibleLayerCount(): number;
+/**
+ * Does this event's journey pass through `container`?
+ *
+ * `container.contains(event.target)` is the obvious test and it is wrong the
+ * moment a shadow boundary is involved. Once an event crosses one, `target` is
+ * retargeted to the HOST element -- an ANCESTOR of everything in the shadow
+ * root -- so `contains()` returns false for a click on the container itself.
+ * An outside-click handler written that way treats every click as outside and
+ * closes the panel on the same click that opened it.
+ *
+ * `composedPath()` is unaffected: it lists every node the event actually
+ * travelled through, inside shadow roots included. The `contains` fallback is
+ * for a synthetic event with no composed path, which is the only case where the
+ * retargeting problem cannot arise.
+ */
+export declare function eventHitsInside(container: Node | null, event: Event): boolean;
+/**
+ * The element the user actually acted on, not the one the DOM admits to.
+ *
+ * A listener on `document` sees `event.target` retargeted to the shadow HOST,
+ * so `target.closest(selector)` walks the light tree and never sees the node
+ * that was clicked. `composedPath()[0]` is the real innermost target, and
+ * walking the path is the shadow-safe form of `closest()` -- the path already
+ * spans every root the event crossed, so an ancestor search over it finds
+ * matches inside the shadow tree and outside it in one pass.
+ */
+export declare function closestInEventPath(event: Event, selector: string): Element | null;

package/dist/_interaction/dismissal.js

@@ -0,0 +1,137 @@
+/**
+ * Who owns a dismissal, when several overlays are open at once.
+ *
+ * Before this module each overlay listened wherever suited it: Modal on the
+ * window, Sheet only on its own overlay element, Menu and ContextMenu on the
+ * document, CommandMenu on the window again. Nothing coordinated them, so one
+ * Escape reached every listener and a menu opened inside a modal closed both --
+ * the menu the user meant, and the modal behind it they did not.
+ *
+ * Ownership here is an explicit registration order, not something inferred from
+ * DOM nesting. Nesting is the wrong signal: a portaled dropdown is a sibling of
+ * the modal it visually sits inside, and a menu anchored in the light DOM is not
+ * a descendant of the shadow root that opened it. What actually decides which
+ * overlay a dismissal belongs to is which one opened last, and only the overlay
+ * itself knows when that happened -- so it says so, and says so again when it
+ * closes.
+ *
+ * Registration returns its own release function rather than exposing the stack,
+ * so a layer can only ever remove itself, and removal from the middle is safe:
+ * an overlay that closes underneath another leaves the one above it topmost.
+ */
+const stack = [];
+function topmost() {
+    return stack.length === 0 ? null : stack[stack.length - 1];
+}
+/**
+ * Whether the event started inside `node`. Uses the composed path so a press
+ * inside a `sui-*` element's shadow root still counts as inside: `event.target`
+ * is retargeted to the shadow host by the time a document listener sees it,
+ * which would report every press inside a custom element as an outside click.
+ */
+function startedInside(event, node) {
+    return eventHitsInside(node, event);
+}
+function handleKeydown(event) {
+    if (event.key !== 'Escape') {
+        return;
+    }
+    topmost()?.onEscape?.();
+}
+function handlePointerdown(event) {
+    const layer = topmost();
+    if (layer === null || startedInside(event, layer.element())) {
+        return;
+    }
+    layer.onOutside?.(event);
+}
+// Capture phase, so the owning layer is decided before any component's own
+// handlers run and before a click can be swallowed by something in between.
+const LISTENER_OPTIONS = { capture: true };
+function setListeners(attach) {
+    if (typeof document === 'undefined') {
+        return;
+    }
+    const apply = attach
+        ? document.addEventListener.bind(document)
+        : document.removeEventListener.bind(document);
+    apply('keydown', handleKeydown, LISTENER_OPTIONS);
+    apply('pointerdown', handlePointerdown, LISTENER_OPTIONS);
+}
+/**
+ * Registers `layer` as the topmost dismissible surface and returns the function
+ * that removes it again. Calling that function more than once is harmless.
+ */
+export function registerDismissible(layer) {
+    stack.push(layer);
+    if (stack.length === 1) {
+        setListeners(true);
+    }
+    let released = false;
+    return () => {
+        if (released) {
+            return;
+        }
+        released = true;
+        const index = stack.lastIndexOf(layer);
+        if (index !== -1) {
+            stack.splice(index, 1);
+        }
+        if (stack.length === 0) {
+            setListeners(false);
+        }
+    };
+}
+/** How many layers are currently registered. Exists for tests and diagnostics. */
+export function dismissibleLayerCount() {
+    return stack.length;
+}
+/**
+ * Does this event's journey pass through `container`?
+ *
+ * `container.contains(event.target)` is the obvious test and it is wrong the
+ * moment a shadow boundary is involved. Once an event crosses one, `target` is
+ * retargeted to the HOST element -- an ANCESTOR of everything in the shadow
+ * root -- so `contains()` returns false for a click on the container itself.
+ * An outside-click handler written that way treats every click as outside and
+ * closes the panel on the same click that opened it.
+ *
+ * `composedPath()` is unaffected: it lists every node the event actually
+ * travelled through, inside shadow roots included. The `contains` fallback is
+ * for a synthetic event with no composed path, which is the only case where the
+ * retargeting problem cannot arise.
+ */
+export function eventHitsInside(container, event) {
+    if (container === null) {
+        return false;
+    }
+    const path = typeof event.composedPath === 'function' ? event.composedPath() : [];
+    if (path.length > 0) {
+        return path.includes(container);
+    }
+    const target = event.target;
+    return target instanceof Node && container.contains(target);
+}
+/**
+ * The element the user actually acted on, not the one the DOM admits to.
+ *
+ * A listener on `document` sees `event.target` retargeted to the shadow HOST,
+ * so `target.closest(selector)` walks the light tree and never sees the node
+ * that was clicked. `composedPath()[0]` is the real innermost target, and
+ * walking the path is the shadow-safe form of `closest()` -- the path already
+ * spans every root the event crossed, so an ancestor search over it finds
+ * matches inside the shadow tree and outside it in one pass.
+ */
+export function closestInEventPath(event, selector) {
+    const path = typeof event.composedPath === 'function' ? event.composedPath() : [];
+    if (path.length === 0) {
+        const target = event.target;
+        return target instanceof Element ? target.closest(selector) : null;
+    }
+    for (const node of path) {
+        if (node instanceof Element && node.matches(selector)) {
+            return node;
+        }
+    }
+    return null;
+}

package/dist/_interaction/focus.d.ts

@@ -0,0 +1,73 @@
+/**
+ * Shared focus-trap primitives for any `aria-modal="true"` panel -- Modal,
+ * Sheet and DateRangePicker each grew their own copy of the same selector
+ * plus the same first/last edge-wrap decision. Three copies of one decision
+ * is a maintenance hazard (a fix to one silently misses the other two), so
+ * this is the single home for it. Originally written for Modal alone
+ * (#529: "no Tab-cycling") as `Modal/focus-trap.ts`; moved here once Sheet
+ * and DateRangePicker had each reimplemented it independently.
+ *
+ * Pure DOM-reading functions, no Svelte runtime dependency, so they stay
+ * unit testable without mounting a component -- see focus.test.ts, which
+ * exercises all of this against plain object stubs.
+ *
+ * Modal.svelte, Sheet.svelte and DateRangePicker.svelte own the event wiring
+ * (which key was pressed, calling `.focus()`); this module owns the two
+ * decisions that wiring needs answered: "what are the edges of the tab order
+ * in here" and "given where focus is and which way Tab was pressed, should
+ * it wrap, and to where".
+ *
+ * Lives under an underscore-prefixed directory, mirroring `src/lib/_chart/`:
+ * this is an implementation detail three components happen to share, not a
+ * themed, documented component with a prop/event surface of its own. It has
+ * no visual output, no `classes`/`testId` escape hatch, nothing a consumer
+ * configures -- there is nothing here that belongs in `src/lib/index.ts` or
+ * the web-component build. Promoting it to the public API would freeze one
+ * internal decision (exactly which selector, exactly which edge-wrap
+ * algorithm) into a contract this library would then have to keep working
+ * forever, for consumers who were never meant to reach it directly.
+ */
+export type FocusTrapBoundary = {
+    readonly first: HTMLElement | null;
+    readonly last: HTMLElement | null;
+};
+/**
+ * The first and last focusable descendants of `container`, in DOM order,
+ * filtered to elements that can actually receive focus (see
+ * `canReceiveFocus`). Both are null when the container is null or holds
+ * nothing focusable.
+ */
+export declare function getFocusTrapBoundary(container: ParentNode | null): FocusTrapBoundary;
+/**
+ * Given a Tab/Shift+Tab keydown inside a focus-trapped container, returns the
+ * element focus should move to, or null when the default browser behavior
+ * (move to the next/previous focusable element) should be left alone.
+ *
+ * Wrapping only happens exactly at an edge: focus sits on the last focusable
+ * element and Tab (not Shift+Tab) was pressed, or focus sits on the first and
+ * Shift+Tab was pressed. Anywhere else in the middle of the tab order, the
+ * browser's own handling is correct and this returns null.
+ */
+export declare function focusTrapTabTarget(params: {
+    readonly container: ParentNode | null;
+    readonly activeElement: Element | null;
+    readonly shiftKey: boolean;
+}): HTMLElement | null;
+/**
+ * Moves focus into `container` -- its first focusable descendant, or the
+ * container itself as a fallback for a panel with no focusable content (it
+ * must carry tabindex="-1" for that fallback to actually take focus). A no-op
+ * when the container is null.
+ */
+export declare function focusEntryPoint(container: HTMLElement | null): void;
+/**
+ * The element that really has focus, whether `node` sits in the light DOM or
+ * inside a custom element's open shadow root.
+ *
+ * `document.activeElement` stops at a shadow boundary and reports the shadow HOST,
+ * never the element focused inside it, so a component that reads it directly gets
+ * the wrong answer through the `sui-*` builds while looking correct in the Svelte
+ * one. `getRootNode()` returns the shadow root when the node is shadow-hosted and
+ * the owner document otherwise, and both expose `activeElement`.
+ */
+export declare function getActiveElement(node: Node | null): Element | null;

package/dist/_interaction/focus.js

@@ -0,0 +1,143 @@
+/**
+ * Shared focus-trap primitives for any `aria-modal="true"` panel -- Modal,
+ * Sheet and DateRangePicker each grew their own copy of the same selector
+ * plus the same first/last edge-wrap decision. Three copies of one decision
+ * is a maintenance hazard (a fix to one silently misses the other two), so
+ * this is the single home for it. Originally written for Modal alone
+ * (#529: "no Tab-cycling") as `Modal/focus-trap.ts`; moved here once Sheet
+ * and DateRangePicker had each reimplemented it independently.
+ *
+ * Pure DOM-reading functions, no Svelte runtime dependency, so they stay
+ * unit testable without mounting a component -- see focus.test.ts, which
+ * exercises all of this against plain object stubs.
+ *
+ * Modal.svelte, Sheet.svelte and DateRangePicker.svelte own the event wiring
+ * (which key was pressed, calling `.focus()`); this module owns the two
+ * decisions that wiring needs answered: "what are the edges of the tab order
+ * in here" and "given where focus is and which way Tab was pressed, should
+ * it wrap, and to where".
+ *
+ * Lives under an underscore-prefixed directory, mirroring `src/lib/_chart/`:
+ * this is an implementation detail three components happen to share, not a
+ * themed, documented component with a prop/event surface of its own. It has
+ * no visual output, no `classes`/`testId` escape hatch, nothing a consumer
+ * configures -- there is nothing here that belongs in `src/lib/index.ts` or
+ * the web-component build. Promoting it to the public API would freeze one
+ * internal decision (exactly which selector, exactly which edge-wrap
+ * algorithm) into a contract this library would then have to keep working
+ * forever, for consumers who were never meant to reach it directly.
+ */
+const FOCUSABLE_SELECTOR = 'a[href], button:not([disabled]), textarea:not([disabled]), input:not([disabled]), select:not([disabled]), [tabindex]:not([tabindex="-1"])';
+/**
+ * True when `el` can actually take focus. `FOCUSABLE_SELECTOR` alone matches
+ * candidates that pass its tag/attribute shape but still cannot receive
+ * focus in a real browser: hidden via the `hidden` attribute, inside an
+ * `inert` subtree, or explicitly marked `aria-disabled="true"`. Without this,
+ * Tab wrapping can land focus on one of these -- worse than no trap at all,
+ * since focus then effectively vanishes instead of just not being managed.
+ *
+ * Duck-typed rather than an `instanceof HTMLElement` check: this module is
+ * also exercised against plain `{ focus() {} }` stubs that carry none of
+ * these methods (see focus.test.ts, and Modal's original test suite that
+ * predates this filter) -- a stub with nothing to check on has nothing to
+ * filter out, so it passes through unchanged rather than throwing.
+ *
+ * Deliberately does not consult layout (`offsetParent`, `getClientRects`):
+ * jsdom, which the test suite runs under, never computes layout, so a
+ * layout-based check would either be a permanent no-op there or -- worse --
+ * report every element as non-focusable and empty out every boundary under
+ * test. The three checks below are all attribute/tree-shape reads, which
+ * jsdom does support, so behavior under test matches behavior in a browser.
+ */
+function canReceiveFocus(el) {
+    if (typeof el.hasAttribute !== 'function' ||
+        typeof el.getAttribute !== 'function' ||
+        typeof el.closest !== 'function') {
+        return true;
+    }
+    if (el.hasAttribute('hidden')) {
+        return false;
+    }
+    if (el.getAttribute('aria-disabled') === 'true') {
+        return false;
+    }
+    return el.closest('[inert]') === null;
+}
+function collectFocusableCandidates(container) {
+    const matches = container.querySelectorAll(FOCUSABLE_SELECTOR);
+    const candidates = [];
+    for (let index = 0; index < matches.length; index += 1) {
+        const candidate = matches.item(index);
+        if (canReceiveFocus(candidate)) {
+            candidates.push(candidate);
+        }
+    }
+    return candidates;
+}
+/**
+ * The first and last focusable descendants of `container`, in DOM order,
+ * filtered to elements that can actually receive focus (see
+ * `canReceiveFocus`). Both are null when the container is null or holds
+ * nothing focusable.
+ */
+export function getFocusTrapBoundary(container) {
+    if (container === null) {
+        return { first: null, last: null };
+    }
+    const candidates = collectFocusableCandidates(container);
+    return {
+        first: candidates.length > 0 ? candidates[0] : null,
+        last: candidates.length > 0 ? candidates[candidates.length - 1] : null
+    };
+}
+/**
+ * Given a Tab/Shift+Tab keydown inside a focus-trapped container, returns the
+ * element focus should move to, or null when the default browser behavior
+ * (move to the next/previous focusable element) should be left alone.
+ *
+ * Wrapping only happens exactly at an edge: focus sits on the last focusable
+ * element and Tab (not Shift+Tab) was pressed, or focus sits on the first and
+ * Shift+Tab was pressed. Anywhere else in the middle of the tab order, the
+ * browser's own handling is correct and this returns null.
+ */
+export function focusTrapTabTarget(params) {
+    const { first, last } = getFocusTrapBoundary(params.container);
+    if (first === null || last === null) {
+        return null;
+    }
+    const edge = params.shiftKey ? first : last;
+    if (params.activeElement !== edge) {
+        return null;
+    }
+    return params.shiftKey ? last : first;
+}
+/**
+ * Moves focus into `container` -- its first focusable descendant, or the
+ * container itself as a fallback for a panel with no focusable content (it
+ * must carry tabindex="-1" for that fallback to actually take focus). A no-op
+ * when the container is null.
+ */
+export function focusEntryPoint(container) {
+    if (container === null) {
+        return;
+    }
+    const { first } = getFocusTrapBoundary(container);
+    (first ?? container).focus();
+}
+/**
+ * The element that really has focus, whether `node` sits in the light DOM or
+ * inside a custom element's open shadow root.
+ *
+ * `document.activeElement` stops at a shadow boundary and reports the shadow HOST,
+ * never the element focused inside it, so a component that reads it directly gets
+ * the wrong answer through the `sui-*` builds while looking correct in the Svelte
+ * one. `getRootNode()` returns the shadow root when the node is shadow-hosted and
+ * the owner document otherwise, and both expose `activeElement`.
+ */
+export function getActiveElement(node) {
+    if (node === null) {
+        return null;
+    }
+    const root = node.getRootNode();
+    return root instanceof Document || root instanceof ShadowRoot ? root.activeElement : null;
+}

package/dist/assets/star.svg

@@ -0,0 +1,5 @@
+<svg viewBox="0 0 24 24" fill="currentColor" xmlns="http://www.w3.org/2000/svg">
+  <path
+    d="M12 17.27L18.18 21l-1.64-7.03L22 9.24l-7.19-.61L12 2 9.19 8.63 2 9.24l5.46 4.73L5.82 21z"
+  ></path>
+</svg>