Live Log Stream Panel — Free HTML CSS JS Snippet

Any tool that streams data in real time — a server log viewer, a CI build console, a chat feed, a live sports ticker — runs into the exact same UX problem: should the view auto-scroll to show new content, or respect that the user has deliberately scrolled up to read something older? Auto-scrolling unconditionally is hostile, because it yanks the view away from whatever the user was reading the instant a new line arrives. Never auto-scrolling is equally bad, because the user has to manually scroll down constantly just to keep up. This snippet implements the standard, correct solution — pause auto-scroll the moment the user scrolls away from the bottom, and resume it only when they explicitly ask to — on top of a simulated log feed with severity color-coding and live filter toggles.

Detecting "at the bottom" with scrollTop math

The entire auto-scroll-pause mechanism rests on one function, isAtBottom(), which checks whether logBody.scrollTop + logBody.clientHeight >= logBody.scrollHeight - SCROLL_THRESHOLD. scrollTop is how far the content has been scrolled down from the top, clientHeight is the visible height of the scrollable box, and scrollHeight is the total height of all the content including what is currently off-screen. Adding scrollTop and clientHeight together gives the pixel position of the bottom edge of the visible viewport within the full content; if that position is close enough to scrollHeight (the very end of the content), the user is effectively at the bottom. The SCROLL_THRESHOLD constant (24px) exists because exact pixel equality is unreliable — sub-pixel rendering and rounding in different browsers means scrollTop + clientHeight almost never equals scrollHeight exactly even when the user is visibly at the bottom, so a small tolerance window is required.

Checking bottom state before appending, not after

Every time a new log line is about to be added, appendLine() calls isAtBottom() and stores the result in wasAtBottom before inserting the new DOM node. This ordering matters: checking after insertion would always report "not at bottom" for a viewer who was at the bottom a moment ago, because the newly taller scrollHeight has already pushed the current scrollTop away from the new true bottom. Capturing the scroll state immediately before the DOM mutation is what correctly answers "was the user watching the live edge right before this line arrived" — the only question that determines whether to auto-scroll.

The manual-scroll flag and the Jump to Latest button

A separate scroll event listener on the log container continuously re-evaluates isAtBottom() independent of new lines arriving, and sets a userScrolledUp boolean flag accordingly. That flag is the tie-breaker appendLine() checks alongside wasAtBottom: even if the container happens to measure as "at bottom" for a stray render, an explicit history-reading gesture from the user takes priority. Whenever the container is not at the bottom, a floating "Jump to latest" pill fades into view; clicking it sets logBody.scrollTop = logBody.scrollHeight, clears userScrolledUp, and hides the button again — a single, obvious way back to live-tailing after reading backlog.

Filtering without breaking the stream

The INFO/WARN/ERROR chips do not remove log lines from the DOM or stop new ones from arriving — they toggle a .hidden-level class via CSS display: none on matching .log-line elements. This is deliberate: the streaming setTimeout loop in streamNext() keeps running and keeps appending every scripted line regardless of filter state, so toggling a filter mid-stream never causes lines to be lost or the timer to desync — it only changes what is currently rendered. Newly arriving lines respect the current filter state immediately because appendLine() checks activeLevels[entry.level] and applies .hidden-level at creation time, so a filtered-out severity never even flashes into view before disappearing.

Severity styling and the ERROR flash

Each line's level string doubles as both a CSS class (.log-line.info, .warn, .error) driving its text color, and a lookup key into the activeLevels filter object — one string, two responsibilities, no duplicated mapping tables. ERROR lines additionally receive a .flash class that layers a second @keyframes animation fading a red background tint out over 900ms, purely to draw the eye to the highest-severity events the instant they appear, the same way real observability tools like Datadog or Sentry pulse-highlight new critical alerts.