The Core Model: A Seekable Composition

HyperFrames becomes easier to judge when its composition rules, frame clock, and animation adapters are treated as one system. The useful test is predictive: given a source document and a requested frame, can you explain whether HyperFrames will show the intended state, freeze or mis-time it, or produce a valid result whose exact pixels depend on the environment? That judgment is more valuable than memorizing isolated attributes or commands.

One frame is a contract between several owners

Start with a single request rather than with the whole video. A composition root defines the canvas and its finite window. Timed clips tell the runtime which elements belong in that window at the requested moment. CSS determines how simultaneously active elements are painted. The animation adapter moves motion to the same moment, and the capture engine commits the resulting browser state as pixels. Each part has a different job, but the frame is correct only when the jobs agree.

Suppose a five-second composition has a title that enters at one second, a background video that runs throughout, and a transition that overlaps the final half-second with a result card. The source supplies the title's and card's time windows. The media runtime selects the background video's source moment. CSS decides whether the card sits above the video. The animation system places the title and transition at the time derived from the requested frame. The renderer does not need to infer any of those relationships by watching the page from the beginning.

This is the important ownership boundary. The composition declares what should be active; the runtime applies visibility and media behavior; an adapter makes a particular animation system addressable; the Engine captures; and the higher-level Producer or CLI completes the output pipeline. If one owner silently takes over another's job, the result becomes history-dependent. A script that seeks a video while the media runtime also seeks it creates two answers to the same question. A timeline that plays itself while the renderer expects a direct seek introduces the wall clock. A track row that is mistaken for a CSS layer changes the editor's view without changing the actual paint order.

classDiagram class Composition { declares timing } class Runtime { owns visibility and media } class Adapter { owns animation state } class Engine { captures frames } class ProducerCLI { assembles output } class Environment { can affect pixels } Composition --> Runtime : supplies timing to Runtime --> Adapter : requests state from Runtime --> Engine : presents state to Engine --> ProducerCLI : passes frames to Environment ..> Engine : influences pixels

The diagram is not a package inventory. It is a way to locate responsibility when a frame is wrong. If an element appears outside its intended time window, inspect the composition timing. If the element is active but behind another element, inspect CSS paint order. If motion is absent while the static page is present, inspect the animation binding and adapter. If the state is correct but the file has the wrong audio or transparency behavior, inspect the output stage. The same source project crosses those boundaries, but the boundaries should remain visible.