@pitchfork-ui/elements 0.0.0-stage → 0.1.0

package/dist/types/components/pf-pie-chart/pf-pie-chart.d.ts

@@ -0,0 +1,52 @@
+/**
+ * A pie or donut over `pf-pie-slice` children.
+ *
+ * The chart owns the two things a slice cannot know: its share of the total
+ * and its colour. Both go to the slice, which draws its own legend row —
+ * a slot renders its assigned content once and in one place, so a legend
+ * built in the shadow root could never reach labels that live in the light
+ * DOM.
+ *
+ * All of the arithmetic is core's, so this and the React `PieChart` show the
+ * same breakdown, down to the legend's percentages summing to 100.
+ *
+ * @slot - the `pf-pie-slice` children.
+ * @slot center - what goes in the hole.
+ * @slot empty - what to show when nothing is drawable.
+ * @part visual - the circle.
+ * @part gradient - the layer the wedges are painted on.
+ * @part center - the hole in the middle.
+ * @part legend - the list the slices are slotted into.
+ */
+export declare class PfPieChart {
+    el: HTMLElement;
+    /** Diameter, in pixels. Never below 120, where the ring stops reading. */
+    size: number;
+    /** The hole in the middle, as a fraction of the diameter. */
+    cutout: number;
+    /** Show the legend the slices make up. Reflected. */
+    showLegend: boolean;
+    /** The chart's accessible name. */
+    label: string;
+    /** The gradient painting the wedges, which only the chart can work out. */
+    gradient: string;
+    /** Whether anything is drawable, which decides between chart and empty state. */
+    hasData: boolean;
+    /** The light DOM is readable here, so first paint is already right. */
+    componentWillLoad(): void;
+    componentDidLoad(): void;
+    /**
+     * Re-reads the slices, for a consumer who changed a value through its
+     * *property* — which leaves no attribute and fires no `slotchange`.
+     */
+    refresh(): Promise<void>;
+    /** Direct children only: a nested chart owns its own slices. */
+    private get slices();
+    /**
+     * The property if the slice has upgraded, the attribute if it has not:
+     * `componentWillLoad` can run before a child parsed from HTML upgrades.
+     */
+    private read;
+    sync(): void;
+    render(): any;
+}

package/dist/types/components/pf-pie-slice/pf-pie-slice.d.ts

@@ -0,0 +1,36 @@
+/**
+ * One slice of a `pf-pie-chart`, and its own row in the legend.
+ *
+ * The React `PieChart` takes a `data` array of `{ label, value, color }`; a
+ * slot renders its assigned content once and in one place, so there is no way
+ * for the chart's shadow root to build a legend out of labels that live in the
+ * light DOM. The slice renders its own row instead, which is the §2.1 idiom
+ * and lets a consumer put anything in a label.
+ *
+ * `swatch`, `share` and `drawn` are the chart's to set: only it can see the
+ * total.
+ *
+ * @slot - the slice's label.
+ * @part dot - the colour swatch.
+ * @part label - the label's box.
+ * @part value - the share, as a whole percentage.
+ */
+export declare class PfPieSlice {
+    /** How big the slice is, in whatever unit the chart's slices share. */
+    value: number;
+    /** Overrides the palette colour the chart would give it. */
+    color?: string;
+    /** Set by the chart: the colour actually used, palette or override. */
+    swatch: string;
+    /** Set by the chart: this slice's share, as a whole percentage. */
+    share: number;
+    /**
+     * Set by the chart: whether this slice is in the drawing at all.
+     *
+     * A slice of zero is not a wedge, so it is not a legend row either —
+     * otherwise the legend lists colours that appear nowhere in the chart.
+     * Reflected, because that is what the stylesheet hides it with.
+     */
+    drawn: boolean;
+    render(): any;
+}

package/dist/types/components/pf-popover/pf-popover.d.ts

@@ -0,0 +1,82 @@
+import { EventEmitter } from '../../stencil-public-runtime';
+/**
+ * An interactive panel anchored to its trigger.
+ *
+ * `popover="auto"` rather than `manual`, because the browser then does
+ * light-dismiss and Escape itself — measured from inside a shadow root with
+ * trusted input: a real outside click and a real Escape both close an `auto`
+ * popover while a `manual` one stays open. That is less code than
+ * `onOutsideInteraction` and it composes with the top-layer stack, so a
+ * popover inside a popover closes in the right order.
+ *
+ * @slot - the trigger.
+ * @slot content - the panel's content.
+ * @part panel - the floating panel.
+ */
+export declare class PfPopover {
+    el: HTMLElement;
+    /** Whether the panel is showing. Reflected so the stylesheet can select on it. */
+    open: boolean;
+    /** Which edge of the trigger the panel lines up with. */
+    align: 'start' | 'end';
+    /** Accessible name for the panel, which is a dialog. */
+    label?: string;
+    /**
+     * Close on an outside click or Escape. Defaults to true.
+     *
+     * This is the `auto`/`manual` popover switch: turning it off hands the
+     * consumer responsibility for closing, which is what a popover holding an
+     * unfinished form wants.
+     */
+    dismissable: boolean;
+    /** Fires whenever the panel opens or closes, whoever caused it. */
+    pfOpenChange: EventEmitter<{
+        open: boolean;
+    }>;
+    private stopObserving?;
+    componentDidLoad(): void;
+    disconnectedCallback(): void;
+    /** Opens the panel. */
+    show(): Promise<void>;
+    /** Closes the panel. */
+    hide(): Promise<void>;
+    /**
+     * The one place a state change is announced, whatever caused it: a trigger
+     * click, `show()`/`hide()`, a consumer writing the prop, or the browser's own
+     * light-dismiss mirrored in below.
+     *
+     * Emitting from the `toggle` handler instead looked right and fired for none
+     * of the user-driven paths — by the time `toggle` arrives the click handler
+     * has already moved `open`, so the guard there saw no change. A consumer
+     * mirroring this value back sets `open` to what it already is, which Stencil
+     * does not treat as a change, so there is no loop.
+     */
+    syncOpen(next: boolean, previous: boolean): void;
+    private get panel();
+    private get trigger();
+    /**
+     * The trigger's disclosure state.
+     *
+     * `aria-controls` is deliberately absent: it is an IDREF, and an IDREF does
+     * not cross a shadow boundary, so pointing it at the panel's id would leave
+     * a dangling reference — worse than none. `aria-expanded` and
+     * `aria-haspopup` carry what a screen reader announces here.
+     */
+    private syncTrigger;
+    private showPanel;
+    private hidePanel;
+    handleClick(event: MouseEvent): void;
+    /**
+     * Escape for the `manual` case only. An `auto` popover is dismissed by the
+     * browser, and handling it here as well would fight that.
+     */
+    handleKeyDown(event: KeyboardEvent): void;
+    /**
+     * Mirrors a change the browser made — light-dismiss, or being closed because
+     * another popover took the top layer — back into `open`, which then announces
+     * it through the watch above. Without this a consumer's `open` goes stale
+     * after a dismiss they did not initiate.
+     */
+    private onToggle;
+    render(): any;
+}

package/dist/types/components/pf-progress-bar/pf-progress-bar.d.ts

@@ -0,0 +1,18 @@
+/**
+ * A horizontal determinate progress track.
+ *
+ * @part track - the unfilled groove.
+ * @part fill - the filled portion.
+ * @part value - the percentage readout.
+ */
+export declare class PfProgressBar {
+    /** How far along, on the 0..max scale. */
+    value: number;
+    /** The top of the scale. */
+    max: number;
+    /** Show the percentage beside the track. Reflected for the stylesheet. */
+    showValue: boolean;
+    /** Accessible name. */
+    label?: string;
+    render(): any;
+}

package/dist/types/components/pf-progress-circle/pf-progress-circle.d.ts

@@ -0,0 +1,23 @@
+/**
+ * A circular determinate progress track.
+ *
+ * @part svg - the drawing surface.
+ * @part track - the unfilled ring.
+ * @part fill - the drawn arc.
+ * @part value - the percentage readout.
+ */
+export declare class PfProgressCircle {
+    /** How far along, on the 0..max scale. */
+    value: number;
+    /** The top of the scale. */
+    max: number;
+    /** Diameter in pixels. */
+    size: number;
+    /** Ring thickness in pixels. */
+    strokeWidth: number;
+    /** Show the percentage in the middle. Reflected for the stylesheet. */
+    showValue: boolean;
+    /** Accessible name. */
+    label?: string;
+    render(): any;
+}

package/dist/types/components/pf-progress-step/pf-progress-step.d.ts

@@ -0,0 +1,38 @@
+import type { StepStatus } from '@pitchfork-ui/core';
+import type { PfProgressStepsOrientation } from '../pf-progress-steps/pf-progress-steps';
+/**
+ * One step inside a `pf-progress-steps`.
+ *
+ * @slot title - the step's title.
+ * @slot description - secondary text below the title.
+ * @part marker-wrap - the box holding the marker and the connector.
+ * @part marker - the numbered circle.
+ * @part connector - the line to the next step. Absent on the last.
+ * @part content - the box holding the title and description.
+ * @part title - the title's box.
+ */
+export declare class PfProgressStep {
+    /**
+     * Set it to say where the trail has got to — usually `current` on one step,
+     * and the group infers the rest.
+     *
+     * This is the *asking* half, which the group never writes; `state` below is
+     * the answer. Keeping them apart is what lets the trail change: if the
+     * answer were written back here, the first step of a trail that said nothing
+     * would look explicitly `current`, and prepending a step would leave the
+     * mark behind on it.
+     */
+    status?: StepStatus;
+    /**
+     * Set by the group: the resolved status, which is what the stylesheet reads
+     * and what carries `aria-current="step"` for the one current step.
+     */
+    state: StepStatus;
+    /** Set by the group: the step's number, counting from 1. */
+    position: number;
+    /** Set by the group: the last step draws no connector. */
+    last: boolean;
+    /** Set by the group from its own `orientation`. Reflected for the stylesheet. */
+    orientation: PfProgressStepsOrientation;
+    render(): any;
+}

package/dist/types/components/pf-progress-steps/pf-progress-steps.d.ts

@@ -0,0 +1,42 @@
+export type PfProgressStepsOrientation = 'horizontal' | 'vertical';
+/**
+ * A step indicator over `pf-progress-step` children.
+ *
+ * The group owns everything a step cannot see on its own: its number, whether
+ * it is last — so only the others draw a connector — the orientation, and the
+ * status inference, which depends on where the current step is.
+ *
+ * @slot - the `pf-progress-step` children.
+ */
+export declare class PfProgressSteps {
+    el: HTMLElement;
+    /** Layout. Reflected, and pushed down onto every step. */
+    orientation: PfProgressStepsOrientation;
+    /** The light DOM is readable here, so first paint is already right. */
+    componentWillLoad(): void;
+    componentDidLoad(): void;
+    handleOrientationChange(): void;
+    /**
+     * Re-reads the children, for a consumer who set a step's status through its
+     * *property* — which leaves no attribute and fires no `slotchange`.
+     */
+    refresh(): Promise<void>;
+    /** Direct children only: a nested indicator owns its own steps. */
+    private get steps();
+    /**
+     * The property if the step has upgraded, the attribute if it has not:
+     * `componentWillLoad` can run before a child parsed from HTML upgrades.
+     */
+    private askedStatus;
+    /**
+     * Core's inference, so the React `ProgressSteps` reads the same trail the
+     * same way.
+     *
+     * The answer goes to `state`, never to the `status` a consumer asked with —
+     * the lesson `pf-breadcrumbs` learned the hard way. Writing it back would
+     * make the first step of an unmarked trail look explicitly `current`, and
+     * prepending a step would then leave the mark behind on it.
+     */
+    private sync;
+    render(): any;
+}

package/dist/types/components/pf-radar-axis/pf-radar-axis.d.ts

@@ -0,0 +1,28 @@
+/**
+ * One axis of a `pf-radar-chart`, and its own row in the legend.
+ *
+ * The name is a `label` **attribute** rather than slotted content, which is
+ * the one place this differs from the React `RadarChart`'s `ReactNode`: the
+ * chart draws each name inside its own SVG as a `<text>`, and an SVG `<text>`
+ * cannot hold arbitrary markup in either layer. The legend row the axis draws
+ * for itself uses the same string, so the two always agree.
+ *
+ * @part label - the legend row's name.
+ * @part value - the legend row's number.
+ */
+export declare class PfRadarAxis {
+    /** The axis's name, drawn in the chart and in the legend. */
+    label: string;
+    /** How far along this axis the shape reaches. */
+    value: number;
+    /**
+     * Set by the chart: whether this axis is in the drawing.
+     *
+     * An axis with an unusable value is not drawn, so it is not a legend row
+     * either — a legend naming an axis that appears nowhere is worse than a
+     * shorter legend. Reflected, because that is what the stylesheet hides it
+     * with.
+     */
+    drawn: boolean;
+    render(): any;
+}

package/dist/types/components/pf-radar-chart/pf-radar-chart.d.ts

@@ -0,0 +1,62 @@
+/**
+ * A radar chart over `pf-radar-axis` children.
+ *
+ * The chart owns the drawing; each axis owns its own legend row, as a pie's
+ * slices do. The axis names are attributes rather than slotted content,
+ * because the chart has to draw them inside its own SVG and an SVG `<text>`
+ * cannot hold arbitrary markup.
+ *
+ * All of the trigonometry is core's, so this and the React `RadarChart` put
+ * the same numbers in the same places — the grid rings and the value polygon
+ * only line up if both were built from the same centre, radius and angles.
+ *
+ * @slot - the `pf-radar-axis` children.
+ * @slot empty - what to show when there are too few axes to enclose anything.
+ * @part svg - the drawing.
+ * @part grid - one grid ring.
+ * @part axis - one spoke.
+ * @part area - the value polygon.
+ * @part point - one vertex of it.
+ * @part axis-label - one name drawn around the edge.
+ * @part legend - the list the axes are slotted into.
+ * @part empty - the empty state's box.
+ */
+export declare class PfRadarChart {
+    el: HTMLElement;
+    /** Width of the drawing's viewBox, in pixels. Never below 180. */
+    size: number;
+    /** The scale's top. Defaults to the largest value, never below 1. */
+    max?: number;
+    /** Grid rings, the outermost of which is the chart's edge. */
+    levels: number;
+    showAxes: boolean;
+    showLegend: boolean;
+    /** The chart's accessible name. */
+    label: string;
+    /** What the axes add up to, which only the chart can see. */
+    axes: {
+        label: string;
+        value: number;
+    }[];
+    /** The light DOM is readable here, so first paint is already right. */
+    componentWillLoad(): void;
+    componentDidLoad(): void;
+    /**
+     * Re-reads the axes, for a consumer who changed a value through its
+     * *property* — which leaves no attribute and fires no `slotchange`.
+     */
+    refresh(): Promise<void>;
+    /**
+     * Direct children only: a nested chart owns its own axes.
+     *
+     * **Not** called `children`. A component class's members land on the custom
+     * element itself, so a private getter named after a DOM property shadows
+     * it: `get children()` made `this.el.children` call itself, and the mock
+     * DOM's own `getElementsByTagName` — which walks `.children` — recursed
+     * until the stack ran out. Stencil warns about a `@Prop` that shadows a
+     * prototype member (`animate` is one) but says nothing about a getter.
+     */
+    private get axisElements();
+    sync(): void;
+    render(): any;
+}

package/dist/types/components/pf-radio-button/pf-radio-button.d.ts

@@ -0,0 +1,55 @@
+import { EventEmitter } from '../../stencil-public-runtime';
+/**
+ * One choice inside a `pf-radio-group`.
+ *
+ * Not form-associated, and deliberately so: a form-associated custom element
+ * gets no radio grouping from the browser. Measured — checking a second one
+ * leaves the first checked and the form submits *both* values, where native
+ * radios submit one. So `pf-radio-group` owns the single-selection invariant
+ * and the form value, and this element only asks to be chosen.
+ *
+ * The control is a native `<input type="radio">` so the dot is the browser's,
+ * drawn from `accent-color` exactly as the React component's is. It carries
+ * `tabindex="-1"` and the host delegates focus, which means the group governs
+ * the tab order through the host while `:focus-visible` still lands on the
+ * input the user can see.
+ *
+ * @slot - the choice's label.
+ * @slot description - secondary text below the label.
+ * @part input - the native radio.
+ * @part label - the label element.
+ * @part description - the wrapper around the description slot.
+ */
+export declare class PfRadioButton {
+    el: HTMLElement;
+    /** Submitted by the group when this choice is the selected one. */
+    /**
+     * Reflected because the generated bindings set props as properties, so
+     * without it a consumer selecting `pf-radio-button[value="..."]` in a React
+     * or Angular app finds nothing. The group reads the property, so this was
+     * never a live defect here -- it is the same trap that was one in
+     * `pf-command-item`.
+     */
+    value: string;
+    /**
+     * Whether this is the chosen one. The group sets this — a consumer who sets
+     * it directly will have it overwritten the next time the group syncs.
+     */
+    checked: boolean;
+    /** Disable this choice alone. Reflected so the stylesheet can select on it. */
+    disabled: boolean;
+    /** Asks the group to select this choice. The group decides. */
+    pfRadioSelect: EventEmitter<{
+        value: string;
+    }>;
+    /**
+     * The native input checks itself the instant it is clicked, before the group
+     * has had any say. Writing the property back on every render is what undoes
+     * that when the group declines — a disabled group, or a value the consumer
+     * is holding. Guarded on inequality so an unrelated re-render does not
+     * disturb it.
+     */
+    componentDidRender(): void;
+    private onChange;
+    render(): any;
+}

package/dist/types/components/pf-radio-group/pf-radio-group.d.ts

@@ -0,0 +1,80 @@
+import { EventEmitter } from '../../stencil-public-runtime';
+export type PfRadioGroupOrientation = 'vertical' | 'horizontal';
+/**
+ * A form-associated group of `pf-radio-button` children.
+ *
+ * The group is the control, not the radios: it holds the one `name` and the
+ * one `value`, because a form-associated custom element gets no radio grouping
+ * from the browser. Measured — three independent form-associated elements with
+ * the same name all stay checked and all submit. So single selection is this
+ * element's job, and it is the only one of the pair that touches the form.
+ *
+ * Keyboard follows the ARIA radiogroup pattern rather than the toolbar one:
+ * the group is a single tab stop, and the arrows both move and select.
+ *
+ * @slot - the `pf-radio-button` children.
+ * @part field - the wrapper around legend, choices and error.
+ * @part legend - the group's heading.
+ * @part choices - the container the children are slotted into.
+ * @part error - the error message below the group.
+ */
+export declare class PfRadioGroup {
+    el: HTMLElement;
+    internals: ElementInternals;
+    /**
+     * Submitted under this name. Reflected, because a form-associated element
+     * takes its submission name from the attribute, not this property.
+     */
+    name?: string;
+    /** The selected choice's value. Empty means nothing is selected. */
+    value: string;
+    /** The group's heading. */
+    legend?: string;
+    /** Error message. Its presence is what marks the group invalid. */
+    error?: string;
+    /** Layout and arrow-key axis. Reflected for the stylesheet. */
+    orientation: PfRadioGroupOrientation;
+    required: boolean;
+    /** Disable every choice. Reflected for the stylesheet. */
+    disabled: boolean;
+    /** Fires when the selection changes. */
+    pfChange: EventEmitter<{
+        value: string;
+    }>;
+    /** The value a form reset restores, which is the initial attribute. */
+    private initialValue;
+    componentWillLoad(): void;
+    componentDidLoad(): void;
+    syncFormState(): void;
+    /** A form-associated custom element does not inherit this. */
+    checkValidity(): Promise<boolean>;
+    /** As `checkValidity`, but also shows the browser's validation message. */
+    reportValidity(): Promise<boolean>;
+    /** The message explaining why the group is invalid, or an empty string. */
+    getValidationMessage(): Promise<string>;
+    /** A reset restores the choice the group started with. */
+    formResetCallback(): void;
+    /** The choices, in source order. */
+    private get radios();
+    private isDisabled;
+    /**
+     * Pushes the group's state onto its children: one checked, the rest not, and
+     * exactly one tab stop.
+     *
+     * The ARIA pattern puts the tab stop on the *selected* choice rather than on
+     * whichever was focused last, so that tabbing into the group lands on the
+     * current answer. With nothing selected it falls to the first enabled one,
+     * which is how a user reaches an unanswered group at all.
+     */
+    syncChildren(): void;
+    handleSelect(event: CustomEvent<{
+        value: string;
+    }>): void;
+    /**
+     * In a radiogroup the arrows move *and* select — unlike a toolbar, where
+     * they only move. Disabled choices are skipped entirely, which is why the
+     * index maths runs over the enabled subset rather than over all children.
+     */
+    handleKeyDown(event: KeyboardEvent): void;
+    render(): any;
+}

package/dist/types/components/pf-rating-badge/pf-rating-badge.d.ts

@@ -0,0 +1,23 @@
+export type PfRatingBadgeSize = 'sm' | 'md';
+/**
+ * A rating as a compact pill: one star, the number out of the maximum, and
+ * optionally how many reviews it came from.
+ *
+ * @part icon - the star.
+ * @part value - the rating and the maximum.
+ * @part reviews - the review count, when `reviews` is set.
+ */
+export declare class PfRatingBadge {
+    /** The rating. Clamped into 0..max. */
+    value: number;
+    /** The top of the scale. */
+    max: number;
+    /**
+     * How many reviews the rating came from. Omit it to show no count at all —
+     * which is different from `0`, a product nobody has reviewed yet.
+     */
+    reviews?: number;
+    /** Padding and height. Reflected so the stylesheet can select on it. */
+    size: PfRatingBadgeSize;
+    render(): any;
+}

package/dist/types/components/pf-rating-stars/pf-rating-stars.d.ts

@@ -0,0 +1,31 @@
+/**
+ * A row of stars showing a rating, filled to the fraction.
+ *
+ * One `role="img"` with a name rather than a star-by-star reading: the stars
+ * are an image of the rating, and the number is the thing worth announcing.
+ * Every star inside is therefore `aria-hidden`.
+ *
+ * @part track - the row of stars.
+ * @part star - one star, filled to its own share of the rating.
+ * @part value - the rating written out, when `showValue` is set.
+ */
+export declare class PfRatingStars {
+    /** The rating. Clamped into 0..max, so it cannot overfill the row. */
+    value: number;
+    /** How many stars there are. */
+    max: number;
+    /** Star size in pixels. */
+    size: number;
+    /** Write the rating out beside the stars. */
+    showValue: boolean;
+    /** Overrides the generated name, for a rating that means something else. */
+    label?: string;
+    /**
+     * Coerced, because the stars are built from it: `Number(max)` of an
+     * attribute string works by luck in a loop count and not at all in
+     * arithmetic, and a nonsense value would render an empty row rather than
+     * throwing.
+     */
+    private get count();
+    render(): any;
+}

package/dist/types/components/pf-resizable/pf-resizable.d.ts

@@ -0,0 +1,68 @@
+import { EventEmitter } from '../../stencil-public-runtime';
+/**
+ * Two panels with a draggable separator between them.
+ *
+ * The panels are slotted — `start` and `end` rather than a default slot taking
+ * exactly two children, because a slot cannot be told to take only the first
+ * assigned node and a consumer looping in their own template would otherwise
+ * find the third child silently ignored, which is what the React `Resizable`
+ * does with `Children.toArray(children)`.
+ *
+ * All of the arithmetic is core's, so this and the React `Resizable` agree on
+ * which arrow grows the first panel, on where a pointer sits, and on what a
+ * size outside the bounds becomes.
+ *
+ * @slot start - the first panel: the one whose size this controls.
+ * @slot end - the second panel, which takes the rest.
+ * @part start - the first panel's box.
+ * @part end - the second panel's box.
+ * @part handle - the separator.
+ * @part grip - the mark in the middle of the separator.
+ */
+export declare class PfResizable {
+    el: HTMLElement;
+    /**
+     * `horizontal` puts the panels side by side and drags left and right;
+     * `vertical` stacks them. Reflected, because the stylesheet selects on it.
+     */
+    orientation: 'horizontal' | 'vertical';
+    /** The first panel's share, in percent. */
+    size: number;
+    /** The first panel's smallest share, in percent. */
+    min: number;
+    /** Its largest. */
+    max: number;
+    /** How far one key press moves it, in percent. */
+    step: number;
+    /** The separator's accessible name. */
+    handleLabel: string;
+    /** Fires when the split changes, by pointer or by key. */
+    pfChange: EventEmitter<{
+        size: number;
+    }>;
+    private dragging;
+    handleBoundsChange(): void;
+    /**
+     * The size actually in force. The consumer's `size` is left as they set it,
+     * so narrowing the bounds and widening them again restores what they asked
+     * for rather than what it was clamped to.
+     */
+    private get resolved();
+    private get bounds();
+    /**
+     * A pointer release anywhere ends the drag.
+     *
+     * On the host rather than the handle, and `pointercancel` as well as
+     * `pointerup`: a drag interrupted by the browser — a touch turning into a
+     * scroll gesture, a window losing focus mid-drag — fires only `pointercancel`,
+     * and without it the splitter stays in a dragging state and follows the
+     * pointer around with no button held.
+     */
+    handlePointerEnd(event: PointerEvent): void;
+    private get handle();
+    private onPointerDown;
+    private onPointerMove;
+    private onKeyDown;
+    private commit;
+    render(): any;
+}