export type ChipColorScheme = {
    color: string;
    text: string;
    /** Background color override for dark mode */
    darkColor?: string;
    /** Text color override for dark mode */
    darkText?: string;
    /**
     * Ink for the `outlined` variant, which has no fill of its own.
     *
     * `text`/`darkText` are the ink ON the chip's own background. An outlined
     * chip drops that background and sits on the PAGE, so the same value is
     * being asked to be legible against two different surfaces at once — and
     * for most hues it cannot be. Splitting the roles is what lets the filled
     * ink follow its fill (often dark ink on a bright chip) without dragging
     * the outlined variant down with it.
     */
    outlineText?: string;
    /** Outlined-variant ink in dark mode. */
    darkOutlineText?: string;
    /**
     * The `tinted` variant: the hue's solid stop at low alpha, as an `rgba()`
     * string so it composes over a card, the sheet or a dialog alike, and an
     * ink MEASURED on what that tint reads as over the page. A tint is the
     * reference's rule for hue in the chrome — a 12–16% wash behind hue-coloured
     * text — and it is what a status or enum chip paints by default now; the
     * saturated `color` stop is the `filled` variant, kept for swatches.
     */
    tintColor?: string;
    tintText?: string;
    darkTintColor?: string;
    darkTintText?: string;
};
/**
 * What a translucent colour reads as over an opaque one: a per-channel sRGB
 * mix, which is how the browser composites it. The tint ink is pushed against
 * this, never against the page alone — a 16% wash of the hue moves the
 * background a long way toward the ink, and an ink that only cleared AA on
 * the bare page lands near 3.5:1 on its own tint.
 */
export declare function compositeOver(fgHex: string, alpha: number, bgHex: string): string;
/** Read an `rgba(r, g, b, a)` string back as what it composites to over `bgHex`. */
export declare function tintOnPage(rgba: string, bgHex: string): string;
export declare function contrastRatio(a: string, b: string): number;
export declare const CHIP_HUES: readonly ["blue", "cyan", "teal", "green", "yellow", "orange", "red", "pink", "purple", "gray", "indigo", "violet", "fuchsia", "rose", "emerald"];
export type ChipHue = typeof CHIP_HUES[number];
/**
 * How light or saturated a chip of a given hue is.
 *
 * A hue on its own (`"blue"`) means `Lighter` — the tone the picker offers and
 * the one seeded chips used to be limited to.
 */
export type ChipTone = "Lighter" | "Light" | "Dark" | "Darker";
export type ChipColorKey = ChipHue | `${ChipHue}${ChipTone}`;
/**
 * Every chip scheme, keyed by hue and tone.
 *
 * This table used to hold four tones per hue and was flattened to one, which
 * left `blueDark`, `redDarker` and friends resolving to `undefined` — a chip
 * with a colour in its config rendering with no colour at all — and left seeded
 * chips picking from ten schemes, so a five-value enum routinely drew the same
 * background three times. The tones are generated from {@link HUE_STOPS} now,
 * so a new hue brings its whole family with it.
 */
export declare const CHIP_COLORS: Record<ChipColorKey, ChipColorScheme>;
/**
 * The keys a seeded chip may be assigned, in a stable order.
 *
 * The bare-hue aliases are excluded: they are the same scheme as `<hue>Lighter`
 * and would make the palest tone twice as likely as any other.
 */
export declare const CHIP_SEED_KEYS: ChipColorKey[];
export declare function getColorSchemeForKey(key: ChipColorKey | (string & {})): ChipColorScheme;
export declare function getColorSchemeForSeed(seed: string): ChipColorScheme;