@eifi1/ui-kit 0.22.0 → 0.24.0

package/dist/feedback-attachment-NhUm7Zga.d.ts

@@ -1,367 +0,0 @@
-import * as react from 'react';
-import { ReactNode, RefObject } from 'react';
-
-interface FeedbackCategoryOption {
-    value: string;
-    label: string;
-}
-interface FeedbackAttachmentLabels {
-    /** The heading over the field. Optional: a note editor puts the buttons
-     *  straight under its textarea, where a second heading is noise. */
-    attachment?: string;
-    attachmentAdd: string;
-    /** Label for the "capture screenshot" button. Optional — falls back to the provider's
-     *  `feedbackAttachment.attachmentCapture`, then English. */
-    attachmentCapture?: string;
-    /** The line under the attachment buttons saying a screenshot can be pasted
-     *  straight in. Optional — falls back to the provider's `feedbackAttachment`, then English. */
-    attachmentPaste?: string;
-    attachmentRemove: string;
-    /** `multiple` mode (0.15.5): the chip list's accessible name — and, in
-     *  `<FeedbackDialog attachments="multiple">`, the heading over it (0.16.0). Optional,
-     *  as are the keys below — they fall back to the provider's `feedbackAttachment`,
-     *  then English. */
-    attachmentList?: string;
-    /** `multiple` mode (0.16.0): the screenshot slot's chip title, in place of its file name. */
-    attachmentScreenshot?: string;
-    /** `multiple` mode: one chip's remove button, given the file's name. */
-    attachmentRemoveFile?: (name: string) => string;
-    /** `multiple` mode: the line shown once `max` files are attached. */
-    attachmentLimit?: (max: number) => string;
-    /** `refs` mode (0.22.0): the second line of a chip whose upload is still running. */
-    attachmentUploading?: string;
-}
-interface FeedbackDialogLabels extends FeedbackAttachmentLabels {
-    title: string;
-    category: string;
-    subject: string;
-    body: string;
-    attachment: string;
-    submitHint: string;
-    cancel: string;
-    save: string;
-    /** @deprecated since 0.16.0 — use `attachmentList`, the one key for the heading and
-     *  the chip list it names. Still honoured: set, it wins over the provider's
-     *  `attachmentList` (but not over an `attachmentList` passed beside it). */
-    attachments?: string;
-}
-/**
- * The dialog's own strings — the `feedbackDialog` namespace of `<UiKitProvider
- * labels>` (0.12.0). The attachment keys are not repeated here: they are the
- * `feedbackAttachment` namespace's, which the field inside already reads.
- *
- * Before, every key was required at the call site, so each app restated ten strings
- * wherever it mounted the dialog (kastlan feedback-button.tsx built the object inline).
- */
-interface FeedbackDialogTextLabels {
-    title: string;
-    category: string;
-    subject: string;
-    body: string;
-    /** The body's label when `requireBody={false}`: "What happened? (optional)".
-     *  Optional, so a complete `UiKitLabels` typed before 0.14.2 still compiles. */
-    bodyOptional?: string;
-    /** The heading over the attachment buttons. */
-    attachment: string;
-    /** The line beside the buttons naming the shortcut. */
-    submitHint: string;
-    cancel: string;
-    save: string;
-    /** @deprecated since 0.16.0 — use `feedbackAttachment.attachmentList`. It and this
-     *  key were two names for one heading ("Attachments" over the chips that list names
-     *  "Attachments"), and a catalogue that translated one left the other English. Still
-     *  honoured when set: it wins over `feedbackAttachment.attachmentList`. */
-    attachments?: string;
-}
-declare const DEFAULT_FEEDBACK_DIALOG_LABELS: FeedbackDialogTextLabels;
-interface FeedbackSubmission {
-    title: string;
-    body: string;
-    category: string;
-    attachment: File | null;
-}
-/**
- * What `onSubmit` gets under `attachments="multiple"` (0.15.5): the screenshot and
- * the picked/pasted files apart, because an app files them differently — keksdose
- * attaches the screenshot to the report and the photos as its evidence list. No
- * `attachment`: there is no one file it could name.
- */
-interface FeedbackMultipleSubmission {
-    title: string;
-    body: string;
-    category: string;
-    /** What `onCaptureScreenshot` returned, or `null` — at most one. */
-    screenshot: File | null;
-    /** Picked and pasted files, in the order they were added; at most `maxAttachments`. */
-    attachments: File[];
-}
-interface FeedbackDialogBaseProps {
-    open: boolean;
-    onClose: () => void;
-    categories: FeedbackCategoryOption[];
-    category: string;
-    onCategoryChange: (value: string) => void;
-    /** Prop > `<UiKitProvider labels={{ feedbackDialog, feedbackAttachment }}>` >
-     *  English. Optional since 0.12.0; a whole `FeedbackDialogLabels` still fits. */
-    labels?: Partial<FeedbackDialogLabels>;
-    submitting?: boolean;
-    contextSlot?: ReactNode;
-    attachmentAccept?: string[];
-    maxAttachmentBytes?: number;
-    /**
-     * Optional: capture a screenshot of the underlying app view and return it as a
-     * File. When provided, a "Capture screenshot" button is shown next to "Add
-     * attachment"; the returned file is fed through the same validation + preview.
-     */
-    onCaptureScreenshot?: () => Promise<File | null>;
-    /**
-     * `false`: a report with only a subject can be sent, and the body's label says it is
-     * optional (`bodyOptional`, unless `labels.body` is passed). Default `true`, the
-     * dialog's behaviour until 0.14.2 (keksdose K1: its backend takes title-only reports).
-     */
-    requireBody?: boolean;
-}
-/** One attachment — a screenshot, a picked or a pasted image; a second replaces
- *  nothing, it has to wait for the first to be removed. The default. */
-interface FeedbackDialogSingleProps extends FeedbackDialogBaseProps {
-    attachments?: "single";
-    onSubmit: (data: FeedbackSubmission) => void | Promise<void>;
-    onAttachmentError?: (kind: "type" | "size") => void;
-    /** Multiple mode only — refused here rather than silently ignored. */
-    maxAttachments?: never;
-}
-/**
- * One screenshot plus up to `maxAttachments` picked or pasted files (0.15.5, keksdose
- * dev#578: "pasted two photos, the second overwrote the first"). The capture button is
- * offered while there is no screenshot yet; the add button while there is room.
- */
-interface FeedbackDialogMultipleProps extends FeedbackDialogBaseProps {
-    attachments: "multiple";
-    /** Default `DEFAULT_MAX_ATTACHMENTS` (5). The screenshot does not count. */
-    maxAttachments?: number;
-    onSubmit: (data: FeedbackMultipleSubmission) => void | Promise<void>;
-    /** `"count"`: more files arrived at once than there was room for; the surplus was dropped. */
-    onAttachmentError?: (kind: FeedbackAttachmentError) => void;
-}
-type FeedbackDialogProps = FeedbackDialogSingleProps | FeedbackDialogMultipleProps;
-/**
- * The generic feedback form dialog: category + subject + body + an optional image
- * attachment, with Ctrl/Cmd+Enter to submit. Domain-free — the app supplies the
- * category options, labels and an `onSubmit` that talks to its own backend, plus
- * an optional `contextSlot` for app-specific context (user, current URL, …).
- *
- * **A screenshot can be pasted straight in.** Ctrl/Cmd+V anywhere in the dialog
- * takes an image off the clipboard and makes it the attachment, through the same
- * validation and the same preview as the file picker. It is the gesture the two
- * ways in did not cover: `onCaptureScreenshot` snapshots the *whole* app view,
- * and the file picker needs a file — so somebody who wanted to show one panel,
- * or one region of one, had to save a crop to disk first and then find it again
- * (Steering Design feedback #39). The clipboard is where a region snip already
- * is on every platform.
- *
- * **`attachments="multiple"`** (0.15.5) takes several: every paste and pick adds a
- * chip, and `onSubmit` gets `{ screenshot, attachments }` ({@link
- * FeedbackMultipleSubmission}) instead of `attachment`. Opt-in, so a caller typed
- * against the one-file submission keeps compiling and behaving as before.
- */
-declare function FeedbackDialog(props: FeedbackDialogProps): react.JSX.Element | null;
-
-declare const DEFAULT_ATTACHMENT_ACCEPT: string[];
-declare const DEFAULT_MAX_ATTACHMENT_BYTES: number;
-/** How many files `<FeedbackAttachmentField multiple>` takes when `max` is not given
- *  (0.15.5). Five photos of one problem is already a lot to look through; a report
- *  that needs more is a conversation, which the thread is for. */
-declare const DEFAULT_MAX_ATTACHMENTS = 5;
-/**
- * The field's own strings — the `feedbackAttachment` namespace of `<UiKitProvider
- * labels>`. The keys are {@link FeedbackAttachmentLabels}' own, so the `labels` prop
- * (and a whole `FeedbackDialogLabels` handed down by the dialog) merges over them
- * one to one. The optional heading, `attachment`, stays a prop: a note editor puts
- * the buttons straight under its textarea and wants none.
- *
- * Before 0.7.0 the two optional keys fell back to hard-coded English, so a German app
- * that relied on its provider got "Capture screenshot" under a German form.
- *
- * The three keys added in 0.15.5 for `multiple` mode are optional, so a complete
- * `UiKitLabels` typed before it still compiles; they fall back to English. So is
- * `attachmentScreenshot` (0.16.0).
- */
-interface FeedbackAttachmentFieldLabels {
-    attachmentAdd: string;
-    attachmentCapture: string;
-    attachmentPaste: string;
-    attachmentRemove: string;
-    /** `multiple` mode: the accessible name of the list of chosen files — and, since
-     *  0.16.0, the heading `<FeedbackDialog attachments="multiple">` puts over it. */
-    attachmentList?: string;
-    /** `multiple` mode (0.16.0): what the screenshot slot's chip is called — "Screenshot"
-     *  rather than the capture's file name ("screenshot.webp"), which says nothing a
-     *  reporter chose. The file name stays as the chip's second line. */
-    attachmentScreenshot?: string;
-    /** `multiple` mode: one chip's remove button — "Remove photo.jpg". Named per file,
-     *  because five buttons all called "Remove attachment" say nothing about which. */
-    attachmentRemoveFile?: (name: string) => string;
-    /** `multiple` mode: the line shown in place of the add buttons once `max` is reached. */
-    attachmentLimit?: (max: number) => string;
-    /** `refs` mode (0.22.0, keksdose K16): the second line of a chip whose upload is still
-     *  running, where an uploaded one shows its size — "Uploading…". Optional, like the
-     *  keys above, so a `UiKitLabels` typed before it still compiles. */
-    attachmentUploading?: string;
-}
-declare const DEFAULT_FEEDBACK_ATTACHMENT_LABELS: FeedbackAttachmentFieldLabels;
-/** Why a file was turned away. `"count"` only ever comes from `multiple` (and `refs`)
- *  mode: more files arrived at once than `max` left room for, and the surplus was
- *  dropped. */
-type FeedbackAttachmentError = "type" | "size" | "count";
-/** `refs` mode's reasons: {@link FeedbackAttachmentError}, or `"upload"` — `onUpload`
- *  rejected, and what it rejected with is `onError`'s second argument. A type of its
- *  own so a host's exhaustive switch over the File modes' reasons stays exhaustive. */
-type FeedbackAttachmentRefsError = FeedbackAttachmentError | "upload";
-/**
- * One uploaded attachment in `refs` mode: what the host's upload answered with. `key`
- * identifies it (a storage key, an upload id) and is what a remove goes by; `name` is
- * what the chip says. `size` (bytes) and `type` (mime) are optional — given, the chip
- * shows the size and an image icon or a file icon accordingly.
- */
-interface FeedbackAttachmentRef {
-    key: string;
-    name: string;
-    size?: number;
-    type?: string;
-}
-interface FeedbackAttachmentFieldBaseProps {
-    /** Prop > `<UiKitProvider labels={{ feedbackAttachment }}>` > English. Optional
-     *  since 0.7.0; `attachment` (the heading) is only ever read from here. */
-    labels?: Partial<FeedbackAttachmentLabels> & Pick<Partial<FeedbackAttachmentFieldLabels>, "attachmentUploading">;
-    accept?: string[];
-    maxBytes?: number;
-    /** Snapshot the app view behind this and return it as a File. A "Capture
-     *  screenshot" button appears only when it is given. */
-    onCaptureScreenshot?: () => Promise<File | null>;
-    /** Listen for the paste on `document` rather than on this field's own
-     *  subtree. For a modal, which owns the whole page while it is up. */
-    documentPaste?: boolean;
-    /** Listen for the paste within this element's subtree rather than this
-     *  field's own — for a field standing *beside* the text box a paste is made
-     *  in, whose common parent is where the event bubbles to. Ignored when
-     *  `documentPaste` is set. */
-    pasteFrom?: RefObject<HTMLElement | null>;
-    className?: string;
-}
-/** One file: choosing a second means removing the first. The field's only mode until 0.15.5. */
-interface FeedbackAttachmentFieldSingleProps extends FeedbackAttachmentFieldBaseProps {
-    multiple?: false;
-    refs?: false;
-    value: File | null;
-    onChange: (file: File | null) => void;
-    onError?: (kind: "type" | "size") => void;
-    max?: never;
-    screenshot?: never;
-    onScreenshotChange?: never;
-}
-/**
- * Several files (0.15.5, keksdose dev#578: "pasted two photos, the second overwrote
- * the first"). Every way in ADDS — a pick of several files, a paste, a capture — up to
- * `max`, and each file is a removable chip.
- */
-interface FeedbackAttachmentFieldMultipleProps extends FeedbackAttachmentFieldBaseProps {
-    multiple: true;
-    refs?: false;
-    value: File[];
-    onChange: (files: File[]) => void;
-    /** How many files `value` may hold. Default {@link DEFAULT_MAX_ATTACHMENTS} (5). The
-     *  add buttons and the paste hint are offered only while there is room. */
-    max?: number;
-    /** Per file: a rejected one is reported and the others are still added. */
-    onError?: (kind: FeedbackAttachmentError) => void;
-    /**
-     * A separate slot for THE screenshot, outside `value` and `max`. Given
-     * `onScreenshotChange`, what `onCaptureScreenshot` returns lands here instead of in
-     * `value`, shown as the first chip, and the capture button is offered only while the
-     * slot is empty — a second snapshot of the same view is not more evidence. This is
-     * how `<FeedbackDialog attachments="multiple">` keeps the screenshot apart from the
-     * photos; a form built from the parts can do the same.
-     */
-    screenshot?: File | null;
-    onScreenshotChange?: (file: File | null) => void;
-}
-/**
- * Uploaded on pick (0.22.0, keksdose K16). keksdose's support chat uploads each file
- * the moment it is chosen and sends the message with the REFS the uploads answered —
- * a 10 MB screenshot is refused while the reporter is still typing, not when they
- * press Send — so its `AttachmentPicker` could not use this field, whose value is
- * `File`s held until the form is submitted. Here the value is
- * {@link FeedbackAttachmentRef}s: every way in (pick, paste, capture) validates the
- * file as the other modes do, then hands it to `onUpload` and shows a chip with a
- * spinner until it answers; the ref it resolves to joins `value` through `onChange`.
- * A rejection drops the chip and reports `onError("upload", error)`. A chip is removed
- * BY KEY: `onChange` gets the list without it, and `onRemove` the key, for a host that
- * deletes the upload on the server too.
- *
- * Uploads still running count against `max`, so five picks in quick succession cannot
- * overshoot it; they are not in `value` until they land, so a send that reads `value`
- * sends only what has arrived — hold Send back while {@link onUploadingChange} says
- * an upload is running. Several files upload side by side and join in the order they
- * finish. The File modes are unchanged.
- */
-interface FeedbackAttachmentFieldRefsProps extends FeedbackAttachmentFieldBaseProps {
-    refs: true;
-    multiple?: never;
-    value: FeedbackAttachmentRef[];
-    onChange: (refs: FeedbackAttachmentRef[]) => void;
-    /** Upload one file; resolve to its ref, or reject to refuse it. Called once per
-     *  accepted file, the moment it is chosen. */
-    onUpload: (file: File) => Promise<FeedbackAttachmentRef>;
-    /** A chip was removed — after `onChange` — with its ref's key. */
-    onRemove?: (key: string) => void;
-    /** Whether any upload is running: `true` when the first starts, `false` when the
-     *  last settles — for the host's Send, which should wait. */
-    onUploadingChange?: (uploading: boolean) => void;
-    /** How many refs `value` may hold, uploads in flight included. Default
-     *  {@link DEFAULT_MAX_ATTACHMENTS} (5). */
-    max?: number;
-    /** Per file. `"upload"` carries what `onUpload` rejected with. */
-    onError?: (kind: FeedbackAttachmentRefsError, error?: unknown) => void;
-    screenshot?: never;
-    onScreenshotChange?: never;
-}
-type FeedbackAttachmentFieldProps = FeedbackAttachmentFieldSingleProps | FeedbackAttachmentFieldMultipleProps | FeedbackAttachmentFieldRefsProps;
-/**
- * Picking one picture: the file dialog, a capture of the app view, or a paste.
- * With `multiple`, picking several (see {@link FeedbackAttachmentFieldMultipleProps}).
- *
- * Lifted out of {@link FeedbackDialog} so the *reply* half of the feature can
- * have it too (Steering Design feedback #128). A report is a conversation — it
- * is filed, it is answered, and the reporter sends it back saying that is not
- * what they meant — and the screenshot showing what they mean is taken at
- * whichever of those points they looked. Only the first of them had a way to
- * attach one, so everything after it had to be described in words.
- *
- * **Three ways in, and they are three because no one of them covers the others.**
- * The file dialog needs a file on disk; `onCaptureScreenshot` snapshots the
- * *whole* app view; and the clipboard is where a region snip already is on every
- * platform (Steering Design feedback #39). Somebody who wanted to show one panel
- * had to save a crop and then find it again.
- *
- * `documentPaste` and `pasteFrom` decide where the paste is listened for, and
- * it is a real choice rather than a flag with a default. A modal traps focus,
- * so while it is up every paste in the page is meant for it — including one
- * made with nothing in particular focused, which never reaches a React
- * `onPaste` on a child: that is `documentPaste`. An editor **inline on a
- * page** is not that: the page around it has its own fields, so it listens
- * within its own subtree and a paste elsewhere stays where it was aimed. But
- * "its own subtree" has to include the text box the paste is actually made in,
- * and that box is this field's *sibling*, not its child — a paste in it bubbles
- * to their common parent and never through here. `pasteFrom` is that parent
- * (Steering Design feedback #140): the element whose subtree is listened to,
- * handed in by whoever renders both the box and this field side by side.
- */
-declare function FeedbackAttachmentField(props: FeedbackAttachmentFieldProps): react.JSX.Element;
-/** What a pasted image is called once it is an attachment.
- *
- *  The extension is read off the mime type rather than assumed to be `.png`:
- *  Safari puts TIFF on the clipboard and a file called `pasted.png` that is not
- *  a PNG is one the receiving end opens wrong. */
-declare function pastedName(type: string): string;
-
-export { DEFAULT_ATTACHMENT_ACCEPT as D, type FeedbackAttachmentError as F, DEFAULT_FEEDBACK_ATTACHMENT_LABELS as a, DEFAULT_FEEDBACK_DIALOG_LABELS as b, DEFAULT_MAX_ATTACHMENTS as c, DEFAULT_MAX_ATTACHMENT_BYTES as d, FeedbackAttachmentField as e, type FeedbackAttachmentFieldLabels as f, type FeedbackAttachmentFieldMultipleProps as g, type FeedbackAttachmentFieldProps as h, type FeedbackAttachmentFieldRefsProps as i, type FeedbackAttachmentFieldSingleProps as j, type FeedbackAttachmentLabels as k, type FeedbackAttachmentRef as l, type FeedbackAttachmentRefsError as m, type FeedbackCategoryOption as n, FeedbackDialog as o, type FeedbackDialogLabels as p, type FeedbackDialogMultipleProps as q, type FeedbackDialogProps as r, type FeedbackDialogSingleProps as s, type FeedbackDialogTextLabels as t, type FeedbackMultipleSubmission as u, type FeedbackSubmission as v, pastedName as w };

package/src/components/field-anatomy.tsx

@@ -1,190 +0,0 @@
-// Internal — not re-exported from the barrel. The pieces of a field's anatomy (its
-// label line, the caption and the error under it, the label STRIP over a bare group)
-// for the controls that are not built on `FloatingField`: the date and month pickers,
-// whose trigger is a button in a wrapper of their own, and the groups (ToggleGroup,
-// SwatchPicker, IconPicker), which have no field box at all.
-//
-// `Input` and `Select` keep their own copies in ui.tsx; these follow them class for
-// class, so a DatePicker's caption and a Select's caption are the same 11px line in
-// the same place (keksdose K4: "uniform field anatomy … today it is a patchwork").
-
-import { useId } from "react";
-import type { ReactNode } from "react";
-import { cn } from "../lib/cn";
-import { FieldLabel } from "./ui";
-
-/** `undefined`, `null`, `false` and `""` are what a caller's `cond && "…"` evaluates to
- *  when there is nothing to say; none of them is content. A numeric `0` is. */
-export function hasContent(node: ReactNode): boolean {
-  return node !== undefined && node !== null && node !== false && node !== "";
-}
-
-/**
- * A `hint` that is plain TEXT is a caption under the field; anything else (a
- * `FieldHint` "?") rides the label line — the rule `Select` set in 0.15: the label
- * line is 11px of strip shared with the label, and a sentence placed there was set on
- * top of both the label and the value.
- */
-export function isTextHint(hint: ReactNode): boolean {
-  return (typeof hint === "string" && hint !== "") || typeof hint === "number";
-}
-
-const FIELD_CAPTION_CLASS = "mt-1 text-[11px] leading-tight text-[var(--text-muted)]";
-const FIELD_ERROR_CLASS = "mt-1 text-[11px] leading-tight text-[var(--danger)]";
-
-export interface FieldMessages {
-  /** `invalid`, a message, or an `aria-invalid` from outside (a form library). */
-  isInvalid: boolean;
-  /** The caller's description, then the caption, then the error — the standing
-   *  advice before the news, as `useFieldError` in ui.tsx orders them. */
-  describedBy: string | undefined;
-  /** The caption and the error, for under the field; `null` when there is neither. */
-  below: ReactNode;
-  /** The hint for the LABEL line (a `FieldHint`), or `undefined` when the hint is a
-   *  caption or there is none. */
-  labelHint: ReactNode;
-}
-
-/** `hint` / `error` / `invalid` resolved the way `Select` resolves them. */
-export function useFieldMessages({
-  hint,
-  error,
-  invalid,
-  describedBy,
-  ariaInvalid,
-}: {
-  hint?: ReactNode;
-  error?: ReactNode;
-  invalid?: boolean;
-  describedBy?: string;
-  ariaInvalid?: unknown;
-}): FieldMessages {
-  const hintId = useId();
-  const errorId = useId();
-  const textHint = isTextHint(hint);
-  const hasError = hasContent(error);
-  return {
-    isInvalid: Boolean(invalid) || hasError || ariaInvalid === true || ariaInvalid === "true",
-    describedBy:
-      [describedBy, textHint && hintId, hasError && errorId].filter(Boolean).join(" ") || undefined,
-    below:
-      textHint || hasError ? (
-        <>
-          {textHint && (
-            <p id={hintId} className={FIELD_CAPTION_CLASS}>
-              {hint}
-            </p>
-          )}
-          {hasError && (
-            <p id={errorId} className={FIELD_ERROR_CLASS}>
-              {error}
-            </p>
-          )}
-        </>
-      ) : null,
-    labelHint: !textHint && hasContent(hint) ? hint : undefined,
-  };
-}
-
-/**
- * The field and what is under it, as one box — `FieldGroup` in ui.tsx, for the same
- * reasons written there. Nothing of its own while there is nothing under the field and
- * the caller passed no `error` key (the DOM is exactly what it was before these props);
- * once `error` is passed the box is kept even with no message, so the trigger is never
- * reparented — and remounted, losing focus — as the message comes and goes.
- */
-export function FieldBox({
-  below,
-  reserve,
-  children,
-}: {
-  below: ReactNode;
-  reserve: boolean;
-  children: ReactNode;
-}) {
-  if (below === null && !reserve) return <>{children}</>;
-  return (
-    <div>
-      {children}
-      {below}
-    </div>
-  );
-}
-
-/**
- * The static label in a trigger field's top strip — a {@link FieldLabel}, or, with a
- * `FieldHint`, the label and its "?" laid out on ONE flex row (dev#468: two absolute
- * offsets guessing at the same baseline put the "?" three pixels above its word).
- * `FloatingField`'s static-label row, except that it stops at `end-9`: the date and
- * month triggers keep that column (`pe-9`) for the calendar glyph or the clear ×, and a
- * long label truncates before it rather than putting the "?" on top of it.
- */
-export function FieldLabelLine({ label, hint }: { label: ReactNode; hint?: ReactNode }) {
-  if (!hasContent(hint)) return <FieldLabel>{label}</FieldLabel>;
-  return (
-    // `z-10` as FieldLabel has it: the trigger after it is `relative` and would paint
-    // over the row (and take the "?"'s hover) otherwise.
-    <div className="pointer-events-none absolute start-3 end-9 top-1 z-10 flex items-center gap-1">
-      <FieldLabel className="static min-w-0 max-w-full">{label}</FieldLabel>
-      <span className="pointer-events-auto flex shrink-0 items-center">{hint}</span>
-    </div>
-  );
-}
-
-/**
- * How tall the strip over a bare group is.
- *
- *  - `"toggle"` — 16px. keksdose's `ClearedStatusPicker` (live #288 rework, #431,
- *    measured): *"16px of label strip plus a 26px group is exactly a labelled Input"*,
- *    so a status group in a row of 42px fields ends where they end. The label's line
- *    box runs into the group's top hairline, but the ACTIVE fill — the thing feedback
- *    #117 was about — starts at 19px, below the label's 17.75px.
- *  - `"tiles"` — 20px, keksdose's `FlagPicker` and location field (`pt-5`). A tile has
- *    no inset fill: its selection IS its frame, a 2px dark border-and-ring from the
- *    tile's top edge, so the tile has to start below the whole label line.
- */
-export const LABEL_STRIP_PAD = { toggle: "pt-4", tiles: "pt-5" } as const;
-
-/**
- * The 11px label (and its `FieldHint`) over a group that is NOT a field — keksdose K2:
- * a segmented control or a row of swatches standing in a form row beside labelled
- * inputs, whose label must sit on the same line as theirs (`top-1`, `inset-x-3`, the
- * type of a field's static label) without the group growing a field's border round
- * it. `id` goes on the label so the group can be `aria-labelledby` it.
- *
- * `relative` is load-bearing twice over: the row is positioned against it, and a
- * caller's `sr-only` label cannot escape it (sr-only-containment).
- */
-export function LabelStrip({
-  labelId,
-  label,
-  hint,
-  disabled,
-  pad,
-  className,
-  children,
-}: {
-  labelId: string;
-  label: ReactNode;
-  hint?: ReactNode;
-  /** Dim the label with its group, as `peer-disabled:` dims a field's own. */
-  disabled?: boolean;
-  pad: keyof typeof LABEL_STRIP_PAD;
-  className?: string;
-  children: ReactNode;
-}) {
-  return (
-    <div className={cn("relative min-w-0", LABEL_STRIP_PAD[pad], className)}>
-      <div className="pointer-events-none absolute inset-x-3 top-1 flex items-center gap-1">
-        {/* `static`: FieldLabel positions itself absolutely; here the ROW is
-            positioned, so the label and its "?" are centred on one line by the flex
-            layout (dev#468). */}
-        <FieldLabel id={labelId} className={cn("static min-w-0 max-w-full", disabled && "opacity-50")}>
-          {label}
-        </FieldLabel>
-        {hasContent(hint) && <span className="pointer-events-auto flex shrink-0 items-center">{hint}</span>}
-      </div>
-      {children}
-    </div>
-  );
-}