import type{LyraEventDetailSnapshot}from'../../../internal/lyra-element.js';import{type PropertyValues,type TemplateResult}from'lit';import{LyraElement}from'../../../internal/lyra-element.js';import type{LyraAppearance,LyraSize}from'../../../internal/variants.js';export type LyraAttachmentCapability='files'|'image'|'camera'|'audio'; /** The capabilities that resolve to a real file selection (as opposed to `camera`/`audio`, which * never touch the hidden file input -- see the class doc). */ export type LyraFileBackedCapability=Exclude;export interface LyraAttachmentFilesDetail{capability:LyraFileBackedCapability;files:readonly File[];}export interface LyraAttachmentTriggerEventMap{'lr-camera-request':CustomEvent;'lr-audio-request':CustomEvent;'lr-files':CustomEvent>;blur:FocusEvent;focus:FocusEvent;} /** * `` — a compact attach affordance designed for a * chat composer's start slot (see ``'s own `start` * slot, which this drops straight into, though this component has no code * dependency on it). Its shape adapts to how many attachment `capabilities` * are configured: * - Exactly one capability: a single plain icon button ([part='trigger']). * Activating it performs that capability's action directly. * - More than one: a small anchored menu ([part='menu'], composed from * ``/``/``) listing each capability as a row. * * Two of the four capabilities (`files`, `image`) are file-picker-backed: * activating them opens a hidden native `` via a * synthetic `.click()`, and the resulting selection is re-emitted as * `lr-files`. `accept` is shared across both — `image` defaults it to * `'image/*'` unless the `accept` prop overrides it, `files` always uses * `accept` as-is (empty means "any file type", matching a bare native * `` with no `accept` attribute). * * **`camera`/`audio` are scope-limited by design.** This component does not * implement any camera or microphone capture UI itself — no `getUserMedia`, * no `` — because that's entirely a host/browser concern with * no single right answer (a desktop web app, a mobile PWA, and a native * wrapper all want different things here). Activating `camera` fires * `lr-camera-request`; activating `audio` fires `lr-audio-request`. The * host owns everything from that point on — typically opening * `` in a ``/popover for `audio`, then * handing the resulting blob to something like ``. * * @customElement lr-attachment-trigger * @event lr-files - A file-backed capability's hidden file input produced a real selection. * `detail: { capability: 'files' | 'image', files }`; `files` is a fresh readonly owner-realm * `File[]` snapshot rather than the native input's live `FileList`. * @event lr-camera-request - The `camera` capability was activated. No * detail payload — see the class doc's scope note; the host implements the * actual capture flow. * @event lr-audio-request - The `audio` capability was activated. No * detail payload — same request-only scope as `lr-camera-request`; the * host implements the actual recording flow (typically ``). * @event {FocusEvent} focus - Relayed once from the active trigger button as a bubbling, composed * native event. * @event {FocusEvent} blur - Relayed once from the active trigger button as a bubbling, composed * native event. * @csspart trigger - The single-capability action, a composed `` as of 16.0.0. Only * rendered when `capabilities.length === 1`. It still owns the accessible name, the activation * and the `title`; its background, radius, hover/press mixes, focus ring and hit-area floor now * come from `--lr-icon-button-*`, retuned by `appearance`/`size`. * @csspart trigger__control - The single-capability action's own native `