Heading Underline Read Progress — Native CSS view-timeline

Most scroll-driven CSS demos bind an element's animation to its own view timeline — the element watches itself. This snippet shows the less commonly demonstrated but equally native pattern: a view timeline whose *source* is one element (a paragraph) driving an animation on a completely different element (a heading's underline bar), so the underline fills in step with how far the reader has scrolled through that specific block of text, not with the underline's own tiny transit through the viewport.

Splitting the timeline source from the animated element

view-timeline-name: --para-read and view-timeline-axis: block are declared on .hup-source, the <p> element — this makes the paragraph the *source* of a named timeline representing its own scroll-driven visibility, from first entering to fully exiting the viewport. The underline bar's ::after pseudo-element then references that exact same name via animation-timeline: --para-read, even though it is a sibling element, not the paragraph itself and not a descendant of it. CSS scroll-driven animations resolve a named timeline by searching up the accessible tree for the nearest element or ancestor exposing that name, which is what allows one element's scroll position to drive a completely different element's animation.

Why this is more honest than animating the underline's own timeline

If view-timeline-name were declared on the underline bar instead, the fill would track the underline's own two-pixel-tall transit through the viewport — which happens almost instantly, since it is a thin line, not a real "reading progress" signal. Sourcing the timeline from the full paragraph instead means the fill genuinely represents how much of that block of prose has scrolled past the reader, which is the actual semantic the effect is named for.

animation-range narrows it to the readable window

animation-range: cover 0% cover 85% completes the fill slightly before the paragraph's absolute last pixel leaves the viewport, so the underline reaches 100% right around when a reader has plausibly finished reading the passage rather than only at the exact geometric edge case of the last line scrolling out.

Comparing to a document-wide reading bar

CSS Scroll-Driven Progress Bar and Scroll Reading Time both represent progress through the *entire* document. This underline is deliberately scoped — three separate underlines in this demo each track their own paragraph independently, useful for structured content like a FAQ or a stepped explainer where "progress through this specific answer" matters more than "progress through the whole page."

Browser support

Chromium-based browsers (Chrome, Edge, Opera, Brave) support named view() timelines referenced across sibling elements today. Firefox and Safari support is still landing, so an @supports not (animation-timeline: view()) block shows every underline fully filled rather than stuck empty.

Customizing it

Move view-timeline-name onto a different, more meaningful element (a whole <section> instead of a single paragraph) to change what "read" means, swap scaleX for a width change to a percentage-based fill instead, or add a small percentage label using the same --para-read timeline for a numeric readout beside each underline. Pair it with a FAQ Search Accordion for a "how much of this answer have you read" cue on long answers.