Automatic scrolling and sticky element handling

If you have ever taken a scrolling screenshot and got a navigation bar stamped across the image every few hundred pixels, you have met the core problem. A sticky header is, by definition, always in the viewport — so it is in every capture.

Four page behaviours, four handlers

Fixed and sticky elements

Elements with position: fixed are hidden after the first capture, so the header appears once at the top where it belongs. Sticky elements are converted to relative positioning with their offsets cleared, which puts them back in the document flow at their natural place. Anything covering more than 80% of the viewport is left alone — that is a layout wrapper, not a header, and hiding it would blank the page.

Lazy-loaded images

Before capturing, the engine prompts content to load and waits for decoding. This is why a capture takes a moment longer on an image-heavy page, and why the result does not have grey rectangles in it.

Animations and transitions

A stylesheet is injected that sets animation and transition durations to 1 millisecond and iteration counts to 1. Fade-in-on-scroll effects land at their final state instead of being photographed half-transparent.

Nested scroll containers

If the document itself does not overflow, the engine looks for the largest element whose scroll height genuinely exceeds its visible height, scrolls that, and crops each capture to its bounds so the surrounding application chrome is not repeated.