/**
 * Node-side resolver for relative `data-start` timing references, shared by
 * every parser that reads media timing out of compiled HTML — video frames
 * (`parseVideoElements`), images (`parseImageElements`), and audio
 * (`parseAudioElements`). Keeping the resolution in ONE place is load-bearing:
 * if audio and video disagree on what `data-start="intro"` means, a relative
 * reference that renders a video at the right time silently drops the audio
 * track (they used to — audio parsed `parseFloat("intro") = NaN`).
 *
 * Mirrors the browser runtime's startResolver so `snapshot`/`render` agree.
 * DOM access is via a minimal structural shape so it works against linkedom
 * (Node) without pulling in lib.dom types.
 */
/** Minimal structural DOM shape the reference resolver needs. */
export interface RefResolverEl {
    getAttribute(name: string): string | null;
}
interface RefResolverDoc {
    getElementById(id: string): RefResolverEl | null;
    querySelector(selector: string): RefResolverEl | null;
}
/**
 * Resolve an element's absolute start time (seconds) the same way the browser
 * runtime's startResolver does, so `<video data-start="intro">` (a relative
 * reference to another clip's end) renders at the right time instead of
 * producing NaN and compositing blank / dropping audio. Durations come from
 * `data-duration` or `data-end` here; the natural-media-duration fallback isn't
 * known at parse time, so — exactly like the runtime — an unknown-duration
 * reference falls back to the target's start and an unknown target falls back
 * to 0 (never NaN).
 */
export declare function resolveReferencedStart(doc: RefResolverDoc, el: RefResolverEl, startCache: Map<RefResolverEl, number>, visiting: Set<RefResolverEl>): number;
export {};
//# sourceMappingURL=referenceResolver.d.ts.map