import { default as React } from 'react';
import { FieldWidgetComponentProps } from './types.js';
/**
 * Rich text field with markdown/HTML support
 * For now, this is a simple textarea. A full implementation would use
 * a rich text editor like TipTap, Lexical, or Slate.
 *
 * Reached by forms as `field:markdown` and `field:html`; both resolve here.
 *
 * ## Fullscreen editing (objectui#3301)
 *
 * `ObjectForm` stamps `mobile_fullscreen` onto the metadata of every long-text
 * field — textarea AND rich-text — when `ObjectFormSchema.mobile
 * .fullscreenLongText` is set, and `ObjectFormSchema.mobile`'s own JSDoc has
 * always promised "textarea/rich-text get an expand button". This widget never
 * read the flag, so for `field:markdown` / `field:html` that promise did
 * nothing at all: the producer stamped, and no consumer existed.
 *
 * The flag is read off `field` and nowhere else — the single metadata carrier
 * since objectui#3233 — matching `TextAreaField` read for read, so a
 * misspelled flag stays inert in both widgets rather than being caught by a
 * tolerant fallback in one of them. The affordance and dialog themselves come
 * from the shared `FullscreenFieldEditor`, so one form-level setting keeps
 * producing one behaviour across both widgets.
 *
 * ## Readonly display (objectui#5498)
 *
 * The readonly early return used to render `{value}` as a React TEXT CHILD,
 * so a readonly field of any of the three types showed the user the markup
 * SOURCE of their own content — a `markdown` field's asterisks and hashes, a
 * `richtext` field's tags. The `prose` classes on that wrapper were the tell:
 * they exist to style RENDERED rich content and there was none to style. Every
 * other read surface — grid, kanban card, gallery, related list, dashboard
 * record panel, record detail read mode — dispatches through `getCellRenderer`
 * and renders the same stored bytes FORMATTED, so one field disagreed with
 * itself depending on which surface it was read on, and this branch was the
 * one disagreeing with the platform.
 *
 * It now renders through {@link richTextCellRenderer} — literally the same
 * components `getCellRenderer` resolves, one table shared by both (see
 * `./richTextDisplay.tsx`), so the html/richtext path carries that renderer's
 * `sanitizeHtml` trust boundary rather than a second hand-rolled escape, and a
 * future change to either pipeline moves both surfaces at once.
 *
 * ## Host plumbing (objectui#4810)
 *
 * The editable branch had no `toDomProps` at all, so everything
 * `<FormControl>`'s Radix `Slot` hands down — the field's `id`, the
 * `aria-describedby` naming its `<FormDescription>` and `<FormMessage>` —
 * arrived as props and landed on no element. Measured on a real form: the
 * visible label's `for` pointed at an id nothing carried (`for=DANGLING`) and
 * the rendered description had zero consumers, for all three registry keys
 * (`markdown` / `html` / `richtext`) since they are this one widget.
 *
 * The fix is objectui#3318's standing recipe — `toDomProps(props)` spread onto
 * the REAL focusable control, which here is the `<Textarea>` inside
 * `RichTextEditorSurface`, never the wrapper `<div>`s (a non-focusable wrapper
 * carrying the id would satisfy `document.getElementById` and still leave the
 * label inert). Only the inline surface receives it; see `domProps` there for
 * why the dialog's copy must not.
 */
export declare function RichTextField({ value, onChange, field, readonly, error, ...props }: FieldWidgetComponentProps<string>): React.JSX.Element;