import{type TemplateResult,type PropertyValues}from'lit';import{LyraElement}from'../../../internal/lyra-element.js'; /** The `mode` property's literal value -- `'auto'` tracks the allocation * breakpoint live; `'inline'`/`'overlay'` force that presentation. */ export type LyraResponsivePanelMode='inline'|'overlay'|'auto'; /** What `mode` actually resolves to once the breakpoint is taken into * account -- `'auto'` never appears here. */ export type LyraResponsivePanelEffectiveMode='inline'|'overlay';export type LyraResponsivePanelShape='fullscreen'|'bottom-sheet'|'start'|'end'; /** Reason the panel was closed, forwarded as the `lr-close` event detail -- * mirrors lr-dialog's own `DialogCloseReason` shape. `'escape'` and * `'backdrop'` are emitted by the overlay presentation's own built-in * dismiss triggers (they can't occur while inline, since there's no * backdrop/document-keydown trap wired up then); any other string is * whatever a caller passes to `close()`. */ export type LyraResponsivePanelCloseReason='escape'|'backdrop'|'api'|(string&Record);export interface LyraResponsivePanelModeChangeDetail{mode:LyraResponsivePanelEffectiveMode;}export interface LyraResponsivePanelEventMap{'lr-close':CustomEvent;'lr-mode-change':CustomEvent;} /** * Pure resolution of the `mode` prop + current viewport into the actual * presentation. Kept separate from the allocation observer wiring below so * it's independently unit-testable, and so the live allocation-response logic * can be exercised in tests by calling it (or the instance method that wraps * it) directly instead of needing control over the real browser window, * which `@web/test-runner` doesn't give. */ export declare function resolveResponsivePanelEffectiveMode(mode:LyraResponsivePanelMode,belowBreakpoint:boolean):LyraResponsivePanelEffectiveMode; /** * `` — the same slotted content either docked inline * in the page's normal layout flow (desktop) or presented as a full-screen/ * bottom-sheet overlay, depending on its allocated inline size. Typical uses: * a settings panel or a conversation-history sidebar that's a permanent * docked pane on a wide screen but a modal on a phone. * * Breakpoint detection observes this component and compares its allocation with * `overlayBreakpoint`. Resizing a containing layout across the breakpoint while * `mode="auto"` (the default) updates the * effective presentation without unmounting or re-creating the slotted * content: inline and overlay presentation share the exact same shadow DOM * structure (only a css class, and the overlay-only `role`/`aria-modal` * attributes and backdrop element, differ), so lit-html's diffing keeps * `[part="body"]` and its `` as the same DOM node across the * transition -- scroll position and focus inside the slotted content survive * it for free. When an open inline panel becomes modal, focus already inside * is preserved and outside focus moves to the first available target. Closing * still returns to the opener captured by the original inline open. * * The overlay presentation uses the library's shared overlay coordinator for * focus trapping, Escape/backdrop dismissal, inerting, and stack ordering, * while retaining this component's own responsive rendering and close event. * * Accessible name (overlay presentation only -- the inline presentation has * no dialog semantics to name), in priority order: if the host element itself * has an `aria-label` attribute set, its value wins outright, overriding * every source below -- the standard ARIA convention for a consumer that * wants full control over the announced name, matching lr-dialog's * `accessibleLabel` pattern. Otherwise `label`, when set, is used verbatim. * When both are empty, this falls back to the `header` slot's content -- a * heading element (`h1`–`h6` or `[role="heading"]`) among the slotted header * content wins if present, otherwise the header slot's full text content is * used, mirroring lr-dialog's `detectHeading()`/`headingText` fallback (see * dialog.ts's module doc for why this uses `aria-label`, a copied string, * rather than `aria-labelledby`: the header content is light DOM while * `[part="panel"]` lives in this element's shadow tree, and an ID-reference * attribute can't resolve across that boundary). A panel opened without a * host `aria-label`, `label`, or header content receives the localized * `responsivePanel` fallback, so every overlay dialog remains named. * * @customElement lr-responsive-panel * @slot - The panel body. * @slot header - Optional header content, rendered above the body. * @slot footer - Optional footer content (e.g. action buttons), rendered below the body. * @event lr-close - `detail: LyraResponsivePanelCloseReason`. Cancelable pre-close veto, fired by * the overlay presentation's built-in dismiss triggers (Escape, backdrop click) and by any * `close()` call, in either presentation. Calling `preventDefault()` keeps the panel open and * leaves any active overlay chrome/focus trap intact. A plain `open = false` property write * does not fire it (matching lr-dialog's own precedent: only going through `close()` counts as * a dismissal), and this is deliberately the same event/semantics in both presentations, * rather than only being meaningful for the overlay case, so a consumer only has to wire up one * listener regardless of which presentation is currently active. * @event lr-mode-change - `detail: LyraResponsivePanelModeChangeDetail`. Fired whenever the * *effective* mode (not the `mode` prop's literal value, which may be `'auto'`) changes between * `'inline'` and `'overlay'` -- crossing the breakpoint while `mode="auto"`, or the host * reassigning `mode` to a value that changes the effective presentation. Never fired for the * initial render, only for a live change thereafter. * @csspart base - The root wrapper; `display: none` while closed, positioned `fixed` while open * and in the overlay presentation. * @csspart backdrop - The full-viewport scrim behind the panel -- only rendered in the overlay * presentation. * @csspart panel - The panel surface itself (`role="dialog"` while open and in the overlay * presentation). * @csspart header - The wrapper around the `header` slot. * @csspart body - The wrapper around the default slot. * @csspart footer - The wrapper around the `footer` slot. * Overlay state properties are resolved as inline fallbacks, so setting one on a panel or any * ancestor themes the overlay without changing docked panel chrome or shared tokens. * @cssprop [--lr-responsive-panel-overlay-color=var(--lr-color-overlay)] - The overlay * presentation's scrim color, applied to `[part="backdrop"]`. * @cssprop [--lr-responsive-panel-overlay-panel-bg=var(--lr-color-surface-overlay)] - Background * of `[part="panel"]` in the overlay presentation. * @cssprop [--lr-responsive-panel-overlay-panel-shadow=var(--lr-shadow-l)] - Shadow of * `[part="panel"]` in the overlay presentation. * @cssprop [--lr-responsive-panel-sheet-max-block-size=85dvh] - Maximum height of the * `shape="bottom-sheet"` overlay panel (falls back to `85vh` where `dvh` is unsupported). * @cssprop [--lr-responsive-panel-side-inline-size=var(--lr-size-20rem)] - Width of the * `shape="start"`/`shape="end"` overlay panel along the inline axis. * @status stable * @since 4.0.0 */ export declare class LyraResponsivePanel extends LyraElement{static styles:import("lit").CSSResultGroup[]; /** Whether the panel is open. In the inline presentation this just means visible/mounted; in * the overlay presentation this is the actual modal open/closed state. */ open:boolean; /** `'auto'` (default) tracks `overlay-breakpoint` against this element's allocation; * `'inline'`/`'overlay'` force that presentation. */ private _mode;get mode():LyraResponsivePanelMode;set mode(next:LyraResponsivePanelMode); /** Only affects the overlay presentation's visual treatment -- `'fullscreen'` (default) covers * the whole viewport; `'bottom-sheet'` anchors to the block-end edge and doesn't cover the full * height; `'start'`/`'end'` anchor to the matching *logical* inline edge instead, like a docked * sidebar's slide-in-from-the-edge overlay counterpart -- the anchored edge, the panel's rounded * free edge, and the geometry all flip automatically under `dir="rtl"` (logical * `inset-inline-*`/border-radius properties, no `:dir()` selector involved). No entrance motion * is implied by any shape value. This is a presentation-shape axis, not the library's shared * semantic-tone `variant` vocabulary (`lr-button`/`lr-badge`/etc.) -- it deliberately uses a * different property name to avoid colliding with that meaning. */ shape:LyraResponsivePanelShape; /** Accessible name for the overlay presentation's `role="dialog"`. Unused in the inline * presentation, which has no dialog semantics to name. When empty, falls back to the `header` * slot's content -- see the class doc for the full fallback order. */ label:string; /** CSS length compared with this element's allocated inline size in `mode="auto"`. * At or below the breakpoint, the effective presentation is `'overlay'`. */ overlayBreakpoint:string; /** Host-level `aria-label` override for the overlay presentation's accessible name -- wins over * every other source (`label`, the header-slot fallback), matching ``'s * `accessibleLabel` pattern. See the class doc for the full precedence order. Set as a plain * `aria-label` attribute on `` itself, not a public JS property. */ private accessibleLabel;private belowBreakpoint;private resolvedMode;private hasHeaderSlot;private hasFooterSlot; /** Fallback accessible name sourced from the `header` slot's content -- see `detectHeadingText()`. */ private headingText?;private resizeObserver?;private resizeView?;private lastTrigger?;private overlayHandle?;private headerObserver?;private headerObserverDocument?;private headerObserverGeneration;private ownerRealmGeneration; /** Whether the overlay-only mechanics (scroll-lock and shared overlay registration) are currently * engaged -- derived from `effectiveMode === 'overlay' && open`, tracked separately from those * two properties so willUpdate can diff "was engaged" vs "should be engaged now" regardless of * which of the two changed. */ private overlayChromeActive;private focusOverlayAfterUpdate;private isFirstUpdate; /** The currently resolved presentation. Composition/measurement is the sole write authority. */ get effectiveMode():LyraResponsivePanelEffectiveMode;protected willUpdate(changed:PropertyValues):void;protected updated(changed:PropertyValues):void;connectedCallback():void;disconnectedCallback():void;adoptedCallback():void;private resetOwnerRealmWork;private queueOwnerMicrotask;private activateOverlayChrome;private deactivateOverlayChrome;private observeAllocation;private readonly onWindowResize;private measureAllocation; /** Applies an authoritative allocation measurement. Kept separate from observer delivery for * deterministic tests and reconnect/adoption reconciliation. */ private applyMeasuredInlineSize;private onHeaderSlotChange;private syncHeaderSlot;private resetHeaderObserver;private onFooterSlotChange;private detectHeadingText; /** * Close the panel. `reason` is forwarded as the `lr-close` detail -- * built-in overlay triggers pass `'escape'`/`'backdrop'`; a consumer's own * close affordance (e.g. a footer button, or a docked panel's own toggle) * should call this directly with its own reason string. `lr-close` is a * cancelable, pre-mutation veto point: a listener calling * `preventDefault()` leaves the panel and any active overlay chrome open. * It fires in both presentations (see the class doc's `lr-close` note) but * only returns focus to the trigger that opened it when the overlay * presentation is active, since the inline presentation never took focus * away from anything to begin with. */ close(reason?:LyraResponsivePanelCloseReason):void;private onBackdropClick;render():TemplateResult;}declare global{interface HTMLElementTagNameMap{'lr-responsive-panel':LyraResponsivePanel;}}