import * as React from "react";
import type { MasonryProp } from "../../props/components/layout.prop.js";
export type { MasonryColumnsProp, MasonryGapProp, MasonryItemProp, MasonryLayoutEntryProp, MasonryProp, MasonryProp as MasonryProps, } from "../../props/components/layout.prop.js";
/**
 * Masonry — Ant Design `Masonry` (6.0.0): tiles of unequal height packed into columns, each tile
 * dropped into whichever column is shortest when its turn comes.
 *
 * ## Reading order is the real accessibility question, and this layout answers it by construction
 *
 * A masonry has two orders and they do not agree. **DOM order is `items` order, always** — the
 * tiles are absolutely positioned, so nothing in this component ever reorders the DOM. A screen
 * reader therefore reads, and the Tab key therefore visits, exactly the sequence the caller
 * passed, at every width and in every column count. **Visual order is the packing** — with three
 * columns, items 1·2·3 open the three columns and item 4 lands under whichever of them is
 * shortest, so a later item can sit visually ABOVE an earlier one.
 *
 * That divergence is inherent to the form, not a defect to paper over, and it has one consequence
 * the caller owns: **order `items` by importance, never by height.** `MasonryItem.column` makes
 * the gap wider on purpose — a tile pinned to a column can end up far down the page while staying
 * second in the reading order — so pin sparingly, and never to fake a visual sequence.
 *
 * The alternative implementation is worse on exactly this axis. CSS `column-count` fills the
 * first column to the bottom before starting the second, so in a 30-tile feed the second tile in
 * the DOM paints at the bottom-left of the screen; here the second tile paints at the top of the
 * second column. Absolute placement is what keeps the two orders as close as a masonry can get
 * them.
 *
 * ## It carries no ARIA, and that is the decision, not an omission
 *
 * The container is a plain `<div>` with no role, and so is each tile. WAI-ARIA 1.2 has no role
 * for this, and every near-miss is worse than nothing:
 *
 * - `list` / `listitem` would announce "list, N items" over content that is usually already
 *   headed, linked and structured — and would strip the tiles' own semantics on some AT.
 * - `group` must have an accessible name to be conveyed at all; an unnamed one is discarded, and
 *   naming a layout forces a string the caller has no reason to have.
 * - `region` is a landmark: three masonries on a page would ship three landmarks that axe's
 *   `landmark-unique` rejects — the exact collision gh#817 recorded for the table scroll region.
 * - `grid` / `table` promise a row/column keyboard model that this has none of.
 * - `presentation` / `none` on a `<div>` is a no-op.
 *
 * So the first rule of ARIA applies: no role is the correct role. The tiles' own content carries
 * the semantics, and the caller wraps the masonry in `<section aria-labelledby>` (or a `Flex`
 * with a label, which does this for you) when the COLLECTION needs a name.
 *
 * There are no strings here either — no label, no `aria-label`, no announcement — so the
 * component has nothing to route through `t()`. That is a property of a pure layout, and it is
 * stated rather than papered over with an invented "masonry" label nobody asked for.
 *
 * ## The four deliberate differences from antd, each with its reason at the point of deviation
 *
 * 1. **`gap`, not `gutter`** (and a `GapProp` token step, not a raw pixel number). This package
 *    already owns that axis under that name on `Flex`, `ResponsiveGrid` and `AuthStack`, and
 *    `check:prop-vocabulary` maps a field called `gap` to `GapProp`. `gutter` is typed `never` so
 *    arriving from antd's docs is a compile error that names the replacement.
 * 2. **Breakpoint steps are `base sm md lg xl`, not `xs sm md lg xl xxl`.** antd's `xs` IS this
 *    library's `base`; `xxl` has no step here. Both are rejected by TypeScript and named in a
 *    development warning rather than silently dropped.
 * 3. **`classNames` / `styles` are not ported** — the standing decision for every antd port here
 *    (docs/DESIGN-AUTHORITY.md, "a knob that only a fork could reach is not parity either").
 *    `src/tokens/components/masonry.css` is the answer.
 * 4. **`MasonryItem.height` is honoured.** antd declares and documents the field and then never
 *    reads it — its layout is measured from `getBoundingClientRect()` alone, and all six of its
 *    demos carry their heights in `data`. Shipping an inert prop is worse than shipping none, so
 *    here a finite `height` sizes the tile and skips its measurement, which is also what lets a
 *    first paint and an SSR render land in the right place.
 *
 * And one thing that is NOT ported: antd animates tile REMOVAL through rc-motion's `CSSMotionList`
 * (`motionLeave`). A removed tile here disappears at once. The arrival fade and the re-flow slide
 * are ported, in CSS, and both snap under `prefers-reduced-motion: reduce`.
 */
export declare const Masonry: (<TData = unknown>(props: MasonryProp<TData> & React.RefAttributes<HTMLDivElement>) => React.ReactElement) & {
    displayName?: string;
};