import type { SchedulerEventRenderer } from '../scheduler.config';
/**
 * The built-in event-bar renderers.
 *
 * ## Why a registry rather than a `switch`
 *
 * A bar's appearance is chosen per *event type*, and the set of types is
 * open - a host registers `maintenanceWindow` or `chargingCycle` and expects it
 * to behave exactly like the built-ins. A `switch` would make the built-ins
 * privileged, force every addition through this file, and keep all eight in the
 * bundle even for a scheduler that only ever draws one. A `Map` seeded from a
 * plain object gives host renderers the same standing as the shipped ones and
 * makes "which renderers exist" an inspectable value.
 *
 * ## The contract
 *
 * Each renderer returns an element for the caller to append into
 * {@link SchedulerEventRenderParams.el}. It **fills** the bar; it never
 * positions it - `left`, `top`, `width` and `height` are written by the bar
 * renderer from a pure layout pass, and a renderer that touched them would be
 * overwritten on the next frame and would force a layout in the meantime.
 *
 * ## Why `textContent`, never `innerHTML`
 *
 * Every string reaching these renderers is host data: an event title, a resource
 * name, a badge from a datasource. Assigning it to `innerHTML` would make any
 * record containing markup an injection vector, and sanitising on the render
 * path would cost more than building the two or three nodes a bar actually
 * needs. `textContent` is both safer and faster - it skips the HTML parser
 * entirely.
 *
 * ## Degradation is a first-class case, not a fallback
 *
 * A month view of a year of data produces bars a few pixels wide. Text in a
 * 20px bar is not small, it is *absent* - clipped to two or three glyphs that
 * read as noise. So every renderer checks {@link SchedulerEventRenderParams.width}
 * and drops to a single mark below {@link NARROW_BAR_PX}, which stays meaningful
 * because colour and shape survive at any width where the bar is visible at all.
 *
 * ## Styling
 *
 * No renderer writes a style property. Appearance comes from the classes below,
 * which resolve `--pg-*` tokens in the scheduler stylesheet, so a mode or
 * variant change repaints every bar with no re-render. The one exception is
 * genuinely continuous data - a progress ratio - which is published as the CSS
 * custom property `--pg-scheduler-progress` for the sheet to consume. That is
 * the same seam the grid itself uses for `--pg-scroll-x`: a variable is a datum
 * the theme interprets, not a hardcoded rule that overrides it.
 */
/**
 * Width below which a bar shows only its mark.
 *
 * 40px is roughly four glyphs plus the bar's own 12px of horizontal padding -
 * the point where a label stops being short and starts being wrong.
 */
export declare const NARROW_BAR_PX = 40;
/**
 * The renderers shipped with the scheduler, by name.
 *
 * Exported as data rather than hidden behind {@link getEventRenderer} so a host
 * can compose one - wrapping `progress` to add a tooltip, say - without
 * reimplementing it, and so a documentation page can enumerate them.
 */
export declare const BUILT_IN_EVENT_RENDERERS: Readonly<Record<string, SchedulerEventRenderer>>;
/**
 * Registers a renderer under `name`, replacing any previous one.
 *
 * Replacement is allowed on purpose: overriding `status` with a house style is
 * the common case, and a registry that refused would force every host into a
 * parallel naming scheme. Passing a built-in name and later wanting the original
 * back is served by {@link BUILT_IN_EVENT_RENDERERS}, which is never mutated.
 */
export declare function registerEventRenderer(name: string, renderer: SchedulerEventRenderer): void;
/**
 * Looks up a renderer by name.
 *
 * Returns `undefined` rather than throwing or substituting a default, because
 * the caller - the bar renderer - already has a default and a throw on the
 * render path would take down a frame over a typo in config.
 */
export declare function getEventRenderer(name: string): SchedulerEventRenderer | undefined;
//# sourceMappingURL=event-renderers.d.ts.map