import type { BuiltInRendererDefinition, ColorRendererOptions } from '../../types/built-in-renderer.types';
/**
 * A colour value, drawn as the colour it is.
 *
 * Accepts every notation CSS does — `#f00`, `#ff0000`, `#ff0000cc`,
 * `rgb(255 0 0)`, `rgba(255, 0, 0, .5)`, `hsl(0deg 100% 50%)`, and the colour
 * keywords such as `red` and `rebeccapurple` — and resolves all of them through
 * the shared colour parser, so a column whose API mixes forms still renders one
 * consistent set of swatches. Parsing is memoised per distinct value, so a
 * column of a million rows drawn from twenty colours performs twenty parses.
 *
 * ### Editing
 * The colour itself is never a control: making the swatch clickable would put a
 * hit target in every row of a column the user is trying to scroll, and it would
 * fight the grid's own selection model. Instead an editable colour column
 * behaves exactly like every other editable column — focus the cell, press
 * `Enter`, and the colour editor opens with a native swatch that raises the
 * platform's colour picker when clicked. A `type: 'color'` column gets that
 * editor with no configuration; see `DEFAULT_EDITOR_BY_TYPE`.
 *
 * ### Themeability
 * The colour reaches the DOM as the `--pg-cell-color` custom property rather
 * than as an inline `background`, which keeps the whole cell restyleable from a
 * theme and makes {@link colorRenderer.patch} a two-property write — cheap
 * enough for a column fed by a live feed.
 */
export declare const colorRenderer: BuiltInRendererDefinition<ColorRendererOptions>;
//# sourceMappingURL=color.d.ts.map