import { EventManager, RanElement } from '../../utils';
export declare class Progress extends RanElement {
    _progress: HTMLDivElement;
    _progressWrap: HTMLDivElement;
    _progressWrapValue: HTMLDivElement;
    _progressDot: HTMLDivElement;
    _shadowDom: ShadowRoot;
    _events: EventManager;
    _dragEvents: EventManager;
    moveProgress: {
        mouseDown: boolean;
    };
    private _tabIndexOwnedByComponent;
    static get observedAttributes(): string[];
    constructor();
    get percent(): string;
    set percent(value: string);
    get total(): string;
    set total(value: string);
    get type(): string;
    set type(value: string);
    get dot(): string;
    set dot(value: string);
    get sheet(): string;
    set sheet(value: string);
    handlerExternalCss: () => void;
    progressClick: (e: MouseEvent) => void;
    /**
     * `document` pointermove/pointerup(/pointercancel) are attached here (drag
     * start) and removed in `progressDotMouseUp`/`disconnectedCallback` (drag
     * end) — NOT bound for the component's whole connected lifetime. A page can
     * reasonably have many `<r-progress>`, most never dragged (e.g. a list of
     * upload rows); a document-level listener per instance would run its no-op
     * `moveProgress.mouseDown` check on every single pointermove for the entire
     * page for as long as any of them exist. Scoping it to "only while a drag on
     * *this* instance is actually happening" keeps that cost at the number of
     * drags in flight (normally 0 or 1), not the number of progress bars on the
     * page.
     *
     * Pointer Events (not mouse-only) so dragging the dot works with touch —
     * matches `touch-action: none` on `.ran-progress-dot` in index.less, and the
     * `r-player`/`r-colorpicker` pointer-drag idiom documented in CLAUDE.md.
     */
    progressDotMouseDown: (e: PointerEvent) => void;
    progressDotMouseMove: (e: PointerEvent) => void;
    progressDotMouseUp: () => void;
    /**
     * Arrow-key seeking for `type="drag"` — the mouse/touch drag path had no
     * keyboard equivalent, so a `role="slider"` with no way to actually operate
     * it from the keyboard. Left/Down and Right/Up step by 1% of `total`
     * (Shift for a 10%-of-total coarse step); Home/End jump to the ends,
     * matching native `<input type="range">`. Key mapping is shared with
     * r-colorpicker's hue/alpha sliders via `sliderStepFromKeydown`.
     */
    progressKeydown: (e: KeyboardEvent) => void;
    /**
     * role + aria-value* live on the host (the focusable element) rather than
     * the shadow-internal `.ran-progress` div — a screen reader needs both on
     * the same accessible node. `progressbar` is read-only semantics; `drag`
     * is operable, so it gets `slider` plus the tab stop that makes the
     * existing keyboard/mouse handlers reachable in the first place.
     */
    syncA11y: () => void;
    updateUI: (percentage: number) => void;
    _preSerialize(): void;
    change: () => void;
    appendProgressDot: () => void;
    updateCurrentProgress: () => void;
    /**
     * Bound once, unconditionally, from `connectedCallback` — NOT re-run when
     * `type` changes later. Gating the *binding* on `this.type === 'drag'` (as
     * this used to) meant a `<r-progress>` created as `primary` and switched to
     * `drag` afterwards got `syncA11y`'s role="slider"/tabIndex (which does
     * re-run on attribute change) without ever getting click/drag/keyboard
     * listeners — a slider that claims to be operable and silently isn't. Each
     * handler below already re-checks `this.type` itself, so binding
     * unconditionally here is safe and keeps behavior in sync with the type
     * actually in effect at interaction time, not at connect time.
     */
    dragEvent: () => void;
    private resize;
    connectedCallback(): void;
    disconnectedCallback(): void;
    attributeChangedCallback(name: string, oldValue: string, newValue: string): void;
}
export default Progress;