import type { ComponentPropsWithRef, ReactNode } from "react";
/**
 * Everything a caller writes on a `FieldGroup` reaches the
 * `<fieldset>` — `id`, `hidden`, `data-*`, `aria-*`, `ref`, and the
 * three attributes that are the element's own: `disabled`, `form`
 * and `name`.
 *
 * This is the **opposite** destination from `Field`'s, and the
 * difference is not a preference. `Field` clones onto its child, so
 * its props are that control's props; `FieldGroup` renders its
 * children as-is, so the only element it owns is the `<fieldset>` and
 * a prop has nowhere else to go. One rule reads both:
 * ***a component's props land on the element it owns***
 * ([decision](../../../../docs/decisions/2026-08-21-a-slot-components-rest-props-are-the-controls-props.md)).
 *
 * `disabled` is worth knowing about before reaching for it. On a
 * `<fieldset>` it is not decoration — the platform disables every
 * form control inside the element, not just the box itself. That is
 * usually what a caller wants and occasionally a surprise, and it is
 * a thing a `<div>`-based group could not have offered at all.
 */
export type FieldGroupProps = ComponentPropsWithRef<"fieldset"> & {
    /**
     * The controls. **Rendered as-is, not cloned** — that is the whole
     * difference from `Field`, and it is why this is a separate
     * component rather than a boolean on that one.
     */
    children: ReactNode;
    /**
     * The `<fieldset>`, which is also the outermost element this
     * component renders — so `className` is not the exception here that
     * it is on `Field`.
     */
    className?: string;
    /** Standing help for the group as a whole. */
    description?: ReactNode;
    /** Present means the group is invalid. */
    error?: ReactNode;
    isRequired?: boolean;
    label: ReactNode;
};
/**
 * A label over **several** controls.
 *
 * `Field` mints one id and clones it onto one child, which is the
 * right shape for a text input and the wrong shape the moment there
 * are two of them: an `id` can only name one element, and a
 * `<label htmlFor>` can only point at one. Six of mux-magic's sixteen
 * field components are in that position — `RegexWithFlagsField`
 * (pattern, flags, sample, and a checkbox), `NumberWithLookupField`
 * (three inputs), `LanguageCodeField`, `LanguageCodesField`,
 * `SubtitleTypesField` (a tag input beside a dropdown) and
 * `RenameRegexField` (a row per rule) — and every one of them renders
 * a `FieldLabel` whose `htmlFor` names, at best, one of them.
 *
 * ### `<fieldset>` and `<legend>`, not a `<label>`
 *
 * This is the one place in the library where `<fieldset>` is right.
 * `AccordionSection` rejected it for its panel and said why — it is a
 * *form-control grouping*, and dragging `<legend>` semantics onto
 * prose is wrong. Here the content **is** a form-control grouping,
 * so the element means what it says, `<legend>` names the group
 * natively, and no `role="group"` and no `aria-labelledby` are
 * needed.
 *
 * A `<label>` here would be the mux-magic defect deliberately: a
 * label pointing at one control, or at none.
 *
 * ### What a group cannot carry
 *
 * `aria-invalid` has no group form — it belongs on the control that
 * is actually invalid, and this component does not know which one
 * that is. So `error` here is *described*, not *asserted*: it joins
 * `aria-describedby` on the `<fieldset>`, which screen readers read
 * as focus enters the group. A control inside that is itself invalid
 * should say so itself, in its own `Field`.
 *
 * That is a real limitation and it is stated rather than papered
 * over — the alternative was to clone `aria-invalid` onto every
 * child, which marks the valid ones invalid.
 */
export declare const FieldGroup: ({ children, className, description, error, isRequired, label, ...receivedFieldsetProps }: FieldGroupProps) => ReactNode;
//# sourceMappingURL=FieldGroup.d.ts.map