import { type VariantProps } from 'class-variance-authority';
import * as React from 'react';
/**
 * Compose or build? The wrapper is built, the field's type treatment and the send
 * button are composed.
 *
 * `Input` already renders an addon container with a focus-within boundary
 * (`has-[input:focus]:outline-border-accent`) and a has-value boundary
 * (`has-[input:enabled]:has-[input:not(:placeholder-shown)]`), which is very nearly the
 * source's `active = focused || hasValue`. It is not close enough to use, for three
 * reasons, each of which would have been a real defect:
 *
 * 1. **`:placeholder-shown` is not `value.trim()`.** The source — and the submit gate
 *    below — treat `"   "` as empty. CSS cannot trim, so an `Input`-driven wrapper would
 *    light up its accent border for whitespace while the send button stayed inert and
 *    Enter did nothing. The border state has to be driven by the same trimmed boolean
 *    that gates submission, which only React knows.
 * 2. **Wrong radius, and no seam to fix it at the right layer.** `addonContainer` is
 *    `rounded-sm` (8px) because a text field is a control. This is a composite bar, the
 *    middle step of cr-web-demo's three-step hierarchy (16px shell / 12px nested panel /
 *    8px control): `rounded-xl` = 12px = `rounded-med-sm`.
 * 3. **`addonContainer` draws with `outline` plus `mx-0.5`, and carries the `state`
 *    (error/success/warning) axis.** A chat composer has no validation states, and
 *    inheriting an outline-based boundary means the disabled treatment has to be
 *    expressed as `outline-surface-disabled!` — an `!important` override reaching into
 *    another component's internals.
 *
 * What *is* composed:
 *
 * - `inputStyles({ variant: 'unstyled' })` for the field, so the type ramp, placeholder
 *   ink and disabled ink are literally `Input`'s and cannot drift from it.
 * - `Button` for send, so focus-visible ring, `:disabled` handling and the `render` seam
 *   come for free rather than being re-implemented on a bare `<button>` as the source does.
 * - `SendIcon` rather than the source's inline `<svg>`.
 *
 * ### Two shapes; `pill` is the default because Figma draws it
 *
 * `pill` is Figma's `Input` (1147:19104); `panel` is cr-web-demo's bar and has no Figma
 * counterpart, kept as an opt-in for the desktop surfaces already on it. Only radius, inset and
 * the send treatment differ — behaviour is identical. GTM-990 Track E, E3;
 * `docs/FIGMA-EXCEPTIONS.md` records the one WCAG conflict.
 */
declare const chatInputStyles: (props?: ({
    shape?: "pill" | "panel" | null | undefined;
    state?: "active" | "disabled" | "resting" | null | undefined;
} & import("class-variance-authority/types").ClassProp) | undefined) => string;
/** Field: `Input`'s unstyled type treatment, with the bar owning the padding. */
/**
 * The field borrows `Input`'s type ramp, placeholder ink and disabled ink, then
 * overrides the weight.
 *
 * `Input` is `font-body-small-semibold`, which is a faithful port — maker-ds's input
 * really is semibold. But maker-ds is only the fallback authority, and for a composer
 * cr-web-demo is explicit: `text-sm` with no weight class, so 400. Semibold is also
 * wrong on its own terms here, because this text is the user's own draft rather than a
 * value being presented back to them, and `Textarea` — the nearest sibling, and the
 * control this one behaves most like — is already `font-body-small-regular`.
 */
declare const chatInputFieldStyles: (props?: import("class-variance-authority/types").ClassProp | undefined) => string;
/**
 * Fill and tint depend on both axes, so every pairing lives in `compoundVariants`.
 *
 * Each state restates its `hover:`/`active:` fills: a variant-prefixed utility does not collide
 * with an unprefixed one in tailwind-merge, so `panel` has to beat the variant's own fills and
 * `pill` — which Figma draws with no chip at all — has to cancel them.
 *
 * `pill`'s glyph is Figma's 16px, which is **below WCAG 2.5.8's 24px** on a fine pointer. Figma
 * wins and the conflict is recorded in `docs/FIGMA-EXCEPTIONS.md` rather than corrected away; it is
 * what makes the bar 32px, Figma's exact height. Touch is a gap, not a conflict — Figma's mocks are
 * a desktop render — so `Button`'s `pointer-coarse` 44px floor still applies there.
 */
declare const chatInputSendStyles: (props?: ({
    shape?: "pill" | "panel" | null | undefined;
    ready?: boolean | null | undefined;
} & import("class-variance-authority/types").ClassProp) | undefined) => string;
type ChatInputVariants = VariantProps<typeof chatInputStyles>;
export interface ChatInputProps extends Omit<React.ComponentPropsWithoutRef<'input'>, 'value' | 'type'> {
    /** Called with the trimmed message on submit. Never called with an empty string. */
    onSend: (message: string) => void;
    /**
     * Accessible name for the field. A chat composer rarely has a visible label, and
     * an unlabelled text input is the single most common failure in this pattern.
     * @default 'Message'
     */
    label?: string;
    /**
     * Accessible name for the send button, whose only content is a glyph.
     * @default 'Send message'
     */
    sendLabel?: string;
    /** @default 'Type here' */
    placeholder?: string;
    /**
     * `pill` is Figma's phone composer (`Input`, 1147:19104) — fully round, chipless tint-only
     * send glyph. `panel` is cr-web-demo's 12px bar with a filled send chip, and has no Figma
     * counterpart. Behaviour is identical.
     * @default 'pill'
     */
    shape?: NonNullable<ChatInputVariants['shape']>;
    /** Blocks typing and submission, and fades the whole bar. */
    disabled?: boolean;
    /** Applied to the form root rather than to the field. */
    containerClassName?: string;
}
/**
 * A single-line chat composer: text field plus send button, with a border that
 * brightens while it is focused or holds a message.
 *
 * Deviations from cr-web-demo's `ChatInput`, all deliberate:
 *
 * 1. **The root is a `<form>` and send is `type="submit"`.** The source listens for
 *    `Enter` on the input and calls a handler directly, which means a virtual keyboard's
 *    "go" key, a submit triggered by any other control, and `requestSubmit()` all do
 *    nothing, and there is no `onSubmit` for a caller to hook. Native implicit
 *    submission gives Enter for free and behaves the same. The one cost: this must not
 *    be nested inside another `<form>` — HTML forbids it. Render the surrounding form
 *    around the *page*, not around this.
 * 2. **The `Enter` handler is gone entirely**, for the same reason. The source also
 *    never checked `shiftKey`; nothing here is multi-line, so there is nothing to check.
 * 3. **Every string is a prop with an English default**, including the two accessible
 *    names the source has neither of.
 *
 * Kept from the source, on purpose: the send button is `disabled` only when the bar is
 * disabled, not when the field is empty. A control that appears and disappears from the
 * tab order as you type is worse than one that is inert for a moment, and pressing it
 * empty is a no-op.
 *
 * @example <ChatInput onSend={send} />
 * @example <ChatInput onSend={send} disabled={busy} placeholder="Ask a question" label="Ask the agent" />
 * @example <ChatInput onSend={send} shape="panel" />
 */
export declare const ChatInput: React.ForwardRefExoticComponent<ChatInputProps & React.RefAttributes<HTMLInputElement>>;
export { chatInputStyles, chatInputFieldStyles, chatInputSendStyles };
//# sourceMappingURL=chat-input.d.ts.map