GODRICH
#css-animation#button#loader#transition#scroll#dashboard#ui#design-trends

PDF Viewer Implementation: 9 UI Patterns

· Godrich · 9 items · 32 min read

EmbedsVanilla JSScrollDashboard

pdf viewer implementation: Does scroll decide the page number, or the reverse?

Thumbnail Rail That Syncs to the Current Page by Calculating Scroll Ratio01 pdf-viewer-thumbnail-rail-sync-scroll Focal Zoom That Calculates Its Center From the Pointer's Coordinates02 pdf-viewer-pointer-zoom-focal-point Search Highlight That Calculates a Match's Position and Jumps to It03 pdf-viewer-search-match-highlight-jump Swipe Flip That Calculates Whether to Advance From Release Velocity04 pdf-viewer-swipe-velocity-page-flip Progressive Load Bar That Calculates Progress From Bytes Received05 pdf-viewer-byte-progress-load-bar Rotate Snap Control That Locks the Angle to 90-Degree Steps06 pdf-viewer-rotate-snap-control Keyboard Page Navigation That Calculates the Remaining Distance and Eases Into It07 pdf-viewer-keyboard-page-ease-scroll Download Progress Ring That Fills to the Ratio of Bytes Received08 pdf-viewer-download-progress-ring Hero Scene Combining Several Calculations Into One Viewer Toolbar09 pdf-viewer-hero-toolbar-scene

Auto-plays · click a tile to jump to its section · all nine in one zip

PDF Viewer Implementation: How Scroll and Zoom Stay in Sync Through Calculation

All nine builds below answer the same question a different way: what single calculated value should drive the rest of the interface? Item 01 turns scroll position into a visibility ratio read straight off the page. By item 04 that same idea turns pointer or touch movement into a velocity threshold, item 06 turns button presses into a continuously interpolated angle, and item 09 folds three of the earlier calculations into one toolbar. The order moves from a value read once per scroll event toward a value that keeps recalculating itself every animation frame while the visitor does something else entirely.

01Thumbnail Rail That Syncs to the Current Page by Calculating Scroll Ratio

Thumbnail Rail That Syncs to the Current Page by Calculating Scroll Ratio
Open in a new tab

01 · Thumbnail Rail That Syncs to the Current Page by Calculating Scroll Ratio — Measured area 59.608% · moving frames 23/23Original by GODRICH · SCSS and React ship in the zip · See the password

RAIL_LERPcomputeCurrentvisibleRatio
  var current = 0;
  function visibleRatio(el, viewTop, viewH) {
    var top = el.offsetTop, h = el.offsetHeight;
    var lo = Math.max(top, viewTop), hi = Math.min(top + h, viewTop + viewH);
    return Math.max(0, hi - lo) / h;
  }
  function computeCurrent() {
    var viewTop = doc.scrollTop, viewH = doc.clientHeight, best = 0, bestR = -1;
    for (var i = 0; i < docEls.length; i += 1) {
      var r = visibleRatio(docEls[i], viewTop, viewH);
      if (r > bestR) { bestR = r; best = i; }
    }
    if (best !== current) {
      current = best;
      for (var j = 0; j < thumbEls.length; j += 1) thumbEls[j].classList.toggle('pvt__thumb--active', j === current);
      badge.textContent = (current + 1) + ' / ' + pages.length;
    }
  }

computeCurrent() runs on every scroll event and calls visibleRatio() against all six fake pages to find whichever one overlaps the viewport the most, rather than waiting on an IntersectionObserver threshold to fire. Once the best-overlapping page changes, the matching thumbnail gets the active class, and a lerp step eases the rail's position toward that thumbnail's center only while the auto-demo loop is still playing — the instant a visitor actually scrolls or clicks, the same line snaps the rail straight to the new target in one frame instead. Item 01 moves across 23/23 captured frames at an average intensity of 39.5, repainting 59.6% of cumulative area as the rail glides and the badge text updates.

02Focal Zoom That Calculates Its Center From the Pointer's Coordinates

Focal Zoom That Calculates Its Center From the Pointer's Coordinates
Open in a new tab

02 · Focal Zoom That Calculates Its Center From the Pointer's Coordinates — Measured area 57.451% · moving frames 23/23Original by GODRICH · SCSS and React ship in the zip · See the password

ZOOM_FOCAL_STEP_RATIOapplyWheeleaseInOut
  function render(scale, ox, oy) {
    page.style.transformOrigin = (ox * 100) + '% ' + (oy * 100) + '%';
    page.style.transform = 'scale(' + scale.toFixed(3) + ')';
    var vr = view.getBoundingClientRect();
    dot.style.left = (ox * vr.width) + 'px';
    dot.style.top = (oy * vr.height) + 'px';
    dot.style.transform = 'translate(-50%,-50%) scale(' + (1 / scale).toFixed(3) + ')';
    label.textContent = Math.round(scale * 100) + '%';
  }

  function scheduled(elapsed) {
    var phase = elapsed % LOOP_MS;
    var i = 0;
    while (i < KF.length - 1 && phase >= KF[i + 1].t) i += 1;
    var a = KF[i], b = KF[Math.min(i + 1, KF.length - 1)];
    var span = Math.max(1, b.t - a.t);
    var t = easeInOut(Math.max(0, Math.min(1, (phase - a.t) / span)));
    var s = a.s + (b.s - a.s) * t;
    render(s, b.x, b.y);
  }

  var manual = { s: 1, x: .5, y: .5 };
  function applyWheel(dir, ox, oy) {
    manual.s = Math.max(1, Math.min(L2 * 1.4, manual.s * Math.pow(ZOOM_FOCAL_STEP_RATIO, dir * 0.6)));

applyWheel() converts wherever a wheel or pinch happened into an (ox, oy) ratio of the page's own width and height, then render() sets transform-origin to that exact ratio before scaling, so the enlarged view grows outward from that point instead of the page's fixed center. The step size itself comes from raising ZOOM_FOCAL_STEP_RATIO to a power of the wheel direction, which is why a small ratio change produces a barely-there zoom step and a large one produces a jump. Item 02 moves across 23/23 captured frames at an average intensity of 93.4, repainting 57.5% of cumulative area on every step of the zoom.

03Search Highlight That Calculates a Match's Position and Jumps to It

Search Highlight That Calculates a Match's Position and Jumps to It
Open in a new tab

03 · Search Highlight That Calculates a Match's Position and Jumps to It — Measured area 40.346% · moving frames 22/23Original by GODRICH · SCSS and React ship in the zip · See the password

buildPagespageOfjumpTo
  var words = Array.prototype.slice.call(doc.querySelectorAll('.pvs__w'));
  function pageOf(el) {
    var i = 1, node = el;
    while (node && !node.classList.contains('doc__page')) node = node.parentElement;
    var all = Array.prototype.slice.call(doc.children);
    return all.indexOf(node) + 1;
  }

  function find(q) {
    q = q.toLowerCase();
    if (!q) return [];
    return words.filter(function (w) { return w.textContent.toLowerCase().indexOf(q) === 0; });
  }

  var scrollAnim = null;
  function startScroll(to, dur, nowMs) {
    scrollAnim = { from: doc.scrollTop, to: to, start: nowMs, dur: dur };
  }
  function easeOutCubic(t) { return 1 - Math.pow(1 - t, 3); }

  var lastHit = null;
  function jumpTo(el, nowMs) {
    var target = Math.max(0, el.offsetTop - doc.clientHeight * 0.35);

find() only matches a word whose text starts with the typed query — indexOf(q) === 0, not a substring search anywhere inside the word — so it behaves like a planted-vocabulary lookup rather than full-text search across real file bytes. Picking a hit calls jumpTo(), which scrolls to a position offset above the match by 35% of the viewport height and animates that scroll with easeOutCubic() over several frames rather than jumping there in one step. Item 03 moves across 22/23 captured frames at an average intensity of 67.8, repainting 40.3% of cumulative area as pages scroll past and the match background lights up.

04Swipe Flip That Calculates Whether to Advance From Release Velocity

Swipe Flip That Calculates Whether to Advance From Release Velocity
Open in a new tab

04 · Swipe Flip That Calculates Whether to Advance From Release Velocity — Measured area 42.158% · moving frames 10/23Original by GODRICH · SCSS and React ship in the zip · See the password

SWIPE_FLIP_VELOCITY_PX_SvelocityNowspringEase
  function velocityNow(nowT) {
    if (samples.length < 2) return 0;
    var windowStart = nowT - 120, first = samples[0];
    for (var i = 0; i < samples.length; i += 1) { if (samples[i].t >= windowStart) { first = samples[i]; break; } }
    var last = samples[samples.length - 1];
    var dt = (last.t - first.t) / 1000;
    if (dt <= 0) return 0;
    return (last.x - first.x) / dt;
  }

  function startDrag(x, t) { dragging = true; flying = false; springAnim = null; samples = []; dragStartX = x; cardStartX = curX; pushSample(x, t); }
  function moveDrag(x, t) {
    if (!dragging) return;
    var dx = x - dragStartX;
    curX = cardStartX + dx;
    curRot = dx / 22;
    pushSample(x, t);
    render();
  }
  function release(t) {
    if (!dragging) return;
    dragging = false;
    var v = velocityNow(t);

velocityNow() only looks at samples taken within the last 120 milliseconds before release, throwing out anything earlier so a card that was dragged slowly and then flicked fast at the end still reads as a fast release. That velocity value is what release() compares against SWIPE_FLIP_VELOCITY_PX_S to decide between finishing the flip and springing the card back to center. Item 04 moved on only 10 of 23 captured frames because the auto-demo loop pauses between swipes rather than dragging continuously, at an average intensity of 27.2 and 42.2% cumulative area.

05Progressive Load Bar That Calculates Progress From Bytes Received

Progressive Load Bar That Calculates Progress From Bytes Received
Open in a new tab

05 · Progressive Load Bar That Calculates Progress From Bytes Received — Measured area 2.847% · moving frames 22/23Original by GODRICH · SCSS and React ship in the zip · See the password

speedCurveTOTAL_BYTESHOLD_MS
  var TOTAL_BYTES = 480000;
  var TOTAL_PAGES = 12;
  var HOLD_MS = 260;

  function speedCurve(tSec) {
    // Deterministic pseudo-jitter: three sine waves added together for a network feel that speeds up and slows down
    var base = 210000;
    var v = base
      + 90000 * Math.sin(tSec * 2.3)
      + 40000 * Math.sin(tSec * 5.1 + 1.4)
      + 20000 * Math.sin(tSec * 9.7 + 0.6);
    return Math.max(30000, v);
  }

  var received = 0, speedMul = 1, paused = false, holdT = 0;

  function render() {
    var ratio = Math.max(0, Math.min(1, received / TOTAL_BYTES));
    fill.style.width = (ratio * 100).toFixed(1) + '%';
    pctEl.textContent = Math.round(ratio * 100) + '%';
    bytesEl.textContent = Math.round(received / 1000) + ' / ' + Math.round(TOTAL_BYTES / 1000) + ' KB';

speedCurve() never reads a real network — it adds three sine waves at different frequencies and phases on top of a 210000 base, which is what produces the "faster, then slower" feel without ever calling out to anything real. render() divides the simulated received total by TOTAL_BYTES on every frame to set both the bar's width and the KB counter, so the remaining-page count and the fill percentage always stay derived from the same one ratio. Item 05 moves across 22/23 captured frames at an average intensity of 114.3, and its 2.8% cumulative area is normal for a thin progress-indicator element rather than a full-card backdrop.

06Rotate Snap Control That Locks the Angle to 90-Degree Steps

Rotate Snap Control That Locks the Angle to 90-Degree Steps
Open in a new tab

06 · Rotate Snap Control That Locks the Angle to 90-Degree Steps — Measured area 11.449% · moving frames 23/23Original by GODRICH · SCSS and React ship in the zip · See the password

ROTATE_SNAP_DEGboxSizerotateBy
  function boxSize(angleDeg, w, h) {
    var r = angleDeg * Math.PI / 180;
    var c = Math.abs(Math.cos(r)), s = Math.abs(Math.sin(r));
    return { w: w * c + h * s, h: w * s + h * c };
  }

  var target = 0, current = 0;
  function render() {
    var box = boxSize(current, PAGE_W, PAGE_H);
    frame.style.width = box.w + 'px';
    frame.style.height = box.h + 'px';
    page.style.width = PAGE_W + 'px';
    page.style.height = PAGE_H + 'px';
    page.style.transform = 'translate(-50%,-50%) rotate(' + current.toFixed(1) + 'deg)';
    degEl.textContent = Math.round(((current % 360) + 360) % 360) + '°';
  }

  function rotateBy(dir) { target += dir * ROTATE_SNAP_DEG; }

Pressing the rotate button only raises target by ROTATE_SNAP_DEG — it does not touch current directly — and a separate lerp step (current += (target - current) * 0.18 in the render loop) closes that gap gradually, so the page turns through a continuous sweep rather than cutting straight to the next 90-degree position. boxSize() recalculates the frame's width and height from current on every one of those in-between angles too, using the standard rotated-bounding-box formula, so the frame keeps resizing smoothly through the turn instead of only at rest. Item 06 moves across 23/23 captured frames at an average intensity of 96.2, repainting 11.4% of cumulative area.

07Keyboard Page Navigation That Calculates the Remaining Distance and Eases Into It

Keyboard Page Navigation That Calculates the Remaining Distance and Eases Into It
Open in a new tab

07 · Keyboard Page Navigation That Calculates the Remaining Distance and Eases Into It — Measured area 67.574% · moving frames 23/23Original by GODRICH · SCSS and React ship in the zip · See the password

easeScrollTonavigatepageTops
  Array.prototype.forEach.call(doc.children, function (el) { pageTops.push(el.offsetTop); });

  var currentIndex = 0, scrollAnim = null;
  function easeOutCubic(t) { return 1 - Math.pow(1 - t, 3); }
  function easeScrollTo(target, dur, nowT) { scrollAnim = { from: doc.scrollTop, to: target, start: nowT, dur: dur }; }
  function navigate(dir, nowT) {
    var idx = Math.max(0, Math.min(N - 1, currentIndex + dir));
    if (idx === currentIndex) return;
    currentIndex = idx;
    easeScrollTo(pageTops[idx], 520, nowT);
    badge.textContent = (idx + 1) + ' / ' + N;
  }

  var userActive = false;
  function markActive() { if (!userActive) { userActive = true; root.classList.remove('is-demo'); } }
  root.addEventListener('keydown', function (e) {
    if (e.key === 'ArrowDown' || e.key === 'PageDown') { e.preventDefault(); markActive(); navigate(1, lastTs || 0); }
    else if (e.key === 'ArrowUp' || e.key === 'PageUp') { e.preventDefault(); markActive(); navigate(-1, lastTs || 0); }
  });
  doc.addEventListener('wheel', function () { markActive(); }, { passive: true });

pageTops is built once from every page's own offsetTop, so navigate() always knows the exact target before it moves rather than measuring scroll distance on the fly. easeScrollTo() stores that target alongside a fixed 520-millisecond duration, and a separate animation loop interpolates doc.scrollTop toward it with easeOutCubic() across many frames instead of setting scrollTop once. Item 07 moves across 23/23 captured frames at an average intensity of 45.8, repainting 67.6% of cumulative area — the highest of the nine, because the whole scrollable document redraws its position every one of those frames.

08Download Progress Ring That Fills to the Ratio of Bytes Received

Download Progress Ring That Fills to the Ratio of Bytes Received
Open in a new tab

08 · Download Progress Ring That Fills to the Ratio of Bytes Received — Measured area 2.737% · moving frames 22/23Original by GODRICH · SCSS and React ship in the zip · See the password

lineLenCIRCfinish
  var TOTAL_BYTES = 260000;
  var SPEED = 230000;
  var LOOP_MS = 2000;

  var phase = 'idle', received = 0, doneAt = 0, checkAnim = null;

  function render(ratio) {
    fill.style.strokeDashoffset = (CIRC * (1 - ratio)).toFixed(2);
    pctEl.textContent = Math.round(ratio * 100) + '%';
  }
  function startDownload(nowT) {
    if (phase === 'loading') return;
    phase = 'loading'; received = 0;
    root.classList.remove('pvg--done');
    checkA.style.strokeDashoffset = lenA.toFixed(2);
    checkB.style.strokeDashoffset = lenB.toFixed(2);
    btn.textContent = 'Downloading';
    render(0);
  }
  function finish(nowT) {
    phase = 'done'; doneAt = nowT;
    root.classList.add('pvg--done');
    btn.textContent = 'Done';
    checkAnim = { start: nowT };
  }

render() divides received by TOTAL_BYTES on every frame and turns that ratio into a stroke-dashoffset on the ring, so the fill angle is always the current byte count expressed as a fraction of a circle rather than a separate percentage tracked on the side. finish() only fires once ratio reaches 1, and it hands off to checkAnim, which pulls the two checkmark strokes' dashoffset down from their full length to zero on a staggered timer so the check draws itself stroke by stroke instead of appearing all at once. Item 08 moves across 22/23 captured frames at an average intensity of 132.2, and its 2.7% cumulative area is normal for a ring this size rather than a sign the download animation is broken.

09Hero Scene Combining Several Calculations Into One Viewer Toolbar

Hero Scene Combining Several Calculations Into One Viewer Toolbar
Open in a new tab

09 · Hero Scene Combining Several Calculations Into One Viewer Toolbar — Measured area 40.053% · moving frames 21/23Original by GODRICH · SCSS and React ship in the zip · See the password

HERO_ZOOM_STEPHERO_RAIL_LERPHERO_TOTAL_BYTES
  function computeCurrent() {
    var top = doc.scrollTop, h = doc.clientHeight, best = 0, bestRatio = -1;
    pages.forEach(function (pg, i) {
      var pTop = pg.offsetTop, pBot = pTop + pg.offsetHeight;
      var visTop = Math.max(top, pTop), visBot = Math.min(top + h, pBot);
      var ratio = Math.max(0, visBot - visTop) / pg.offsetHeight;
      if (ratio > bestRatio) { bestRatio = ratio; best = i; }
    });
    return best;
  }
  var activeIdx = -1;
  function markRail(idx) {
    if (idx === activeIdx) return;
    activeIdx = idx;
    thumbs.forEach(function (t, i) { t.classList.toggle('pht__thumb--active', i === idx); });
  }
  var railX = 0;
  function railTarget(idx) {
    var t = thumbs[idx]; if (!t) return 0;
    var want = t.offsetLeft + t.offsetWidth / 2 - rail.clientWidth / 2;
    return -Math.max(0, Math.min(railTrack.scrollWidth - rail.clientWidth, want));
  }

computeCurrent() here is the same overlap-ratio calculation item 01 uses on its own, and railTarget() reuses item 01's centering math to keep the active thumbnail aligned — the hero scene runs that calculation alongside item 02's pointer-anchored zoom and item 08's byte-ratio ring on the same toolbar rather than replacing any of them. Each of the three keeps its own input and output pair, so none of them has to wait for the others to finish a frame before drawing its own update. Item 09 moves across 21/23 captured frames at an average intensity of 46.2, repainting 40.1% of cumulative area across the combined scene.

Where Each Calculation Actually Gets Used

A pdf viewer's nine calculations split across a handful of real jobs rather than one. Item 01's scroll-ratio rail and item 09's hero toolbar suit a document collaboration tool that needs a persistent page map on screen at all times, while item 02's pointer-anchored zoom fits reviewing a blueprint where the exact spot under the cursor has to stay fixed while it grows — the same anchored-point tradeoff behind most pdf viewer mobile ui builds for a small screen. Item 03's search highlight belongs in a contract viewer where a clause number needs to be found fast, item 04's swipe flip and item 07's keyboard easing are two different paths to the same page turn for touch and keyboard visitors respectively, and item 05's load bar and item 08's download ring both answer the same received-bytes question for a large report's first load and its final download button. The pointer-anchored zoom behind item 02 has a close relative in 9 Image Zoom Viewer Interactions — No Photo Files, and the ratio-driven fill behind item 08's ring is the same shape of calculation as the seek bar covered in 9 Custom Video Player CSS Controls, No Video File.

Nine PDF Viewer Patterns, Measured in Area and Intensity

Several of these nine redraw a full scroll container or transform-origin backdrop as their state changes, which is why cumulative area for items 01, 02, 03, 07, and 09 all clear 40% below — cumulative area is the share of each fixed-camera frame that actually repainted, averaged across every measured frame, and intensity is the average pixel delta where it did. Item 05's load bar and item 08's download ring sit at 2.8% and 2.7% cumulative area because a thin progress indicator is a small fraction of the frame by design, and that gap is most of what separates a considered pdf viewer ui design from one that just swaps a static icon at 0% and 100%. Item 04's swipe card moved on only 10 of the 23 captured frames because the auto-demo loop pauses between swipes instead of dragging continuously.

| Pattern | Cumulative area | Avg. intensity | Frames moved |

|---|---|---|---|

| 01 Thumbnail rail scroll sync | 59.6% | 39.5 | 23/23 |

| 02 Pointer focal zoom | 57.5% | 93.4 | 23/23 |

| 03 Search match highlight | 40.3% | 67.8 | 22/23 |

| 04 Swipe velocity page flip | 42.2% | 27.2 | 10/23 |

| 05 Byte progress load bar | 2.8% | 114.3 | 22/23 |

| 06 Rotate snap control | 11.4% | 96.2 | 23/23 |

| 07 Keyboard page ease scroll | 67.6% | 45.8 | 23/23 |

| 08 Download progress ring | 2.7% | 132.2 | 22/23 |

| 09 Hero toolbar scene | 40.1% | 46.2 | 21/23 |

Where the Value Changes the Reaction — Zoom Focal Ratio, Swipe Flip Velocity, Rotate Snap Angle

Three numbers below do most of the deciding: ZOOM_FOCAL_STEP_RATIO sets how much scale item 02 jumps per wheel tick around the pointer's own coordinate, SWIPE_FLIP_VELOCITY_PX_S sets how fast a release has to be before item 04 commits to the next page instead of springing back to center, and ROTATE_SNAP_DEG sets how many degrees item 06's target angle advances per button press before the continuous lerp catches up to it. None of the three change which value gets calculated or how it is read — only how far one wheel tick, one release, or one press pushes that value before the animation settles on it.

Where It Breaks — Touch-Scroll Conflicts, Large-File Load Delay, Keyboard Alternatives

Item 01's rail sync and item 04's swipe flip both listen for movement on their own stage, but computeCurrent() in item 01 runs off the document container's native scroll event while item 04 tracks raw pointer deltas directly — combine the two on a page that scrolls vertically and swipes horizontally without scoping each listener to its own element, and a diagonal drag can fire a scroll-driven page change and a swipe-driven flip from the same gesture, a seam common to any pdf reader animation that mixes scroll and swipe on the same stage. Item 05's speedCurve() and item 08's fixed SPEED constant both calculate received bytes fresh every frame from a per-second rate, so raising TOTAL_BYTES without also raising that rate does not change how the ratio itself is calculated — it only stretches the loading phase across more real seconds before the ratio reaches 1. Every one of the nine attaches exactly one keydown listener to its own tabindex root, and the key sets genuinely differ from item to item — item 01 and item 07 already answer the identical four keys (ArrowUp, ArrowDown, PageUp, PageDown) for their page-to-page moves, while item 04 recognizes only ArrowLeft and ArrowRight for its swipe flip and item 06 recognizes only ArrowLeft/[ and ArrowRight/] for its rotate, so stitching any two of these nine onto one page still means keeping each root's own tabindex rather than merging their keydown handlers into one. The nine index.html files behind these builds, hat2hhry, are the fastest way to see exactly which items recalculate straight off a scroll event and which only recalculate once a drag or a click starts.

Three Variants and Accessibility

| Variant | Value change | Feel |

|---|---|---|

| Adjust the zoom focal ratio | 02 ZOOM_FOCAL_STEP_RATIO 1.2 → 2.4 | Lowering the value zooms in only a little per wheel tick, while raising it makes the same wheel action jump to a much larger zoom. |

| Adjust the swipe flip velocity threshold | 04 SWIPE_FLIP_VELOCITY_PX_S 300 → 600 | Lowering the value flips to the next page with only a light push, while raising it requires a much faster swipe to flip. |

| Adjust the rotate snap angle | 06 ROTATE_SNAP_DEG 90 → 45 | Raising the value rotates a larger angle per button press, while lowering it splits the same button into finer rotation steps. |

prefers-reduced-motion is checked at the top of all nine scripts — item 01's rail stops auto-cycling through pages and item 08's ring jumps straight to a resting 50% instead of animating toward it, the same one-line matchMedia() check repeated in every file rather than shared through a library. Keyboard support is not uniform across the nine: item 01 and item 07 both answer ArrowUp, ArrowDown, PageUp, and PageDown to move between pages, item 04 answers only ArrowLeft and ArrowRight to flip a page, and item 08 answers Enter and Space to start a download and Escape to cancel it early, so stitching two of these onto one page means keeping each root's own tabindex rather than merging their keydown handlers into one. None of the nine calculate page overlap through IntersectionObserver — computeCurrent() in items 01 and 09 reads scrollTop, offsetTop, and offsetHeight directly on every requestAnimationFrame() tick instead, which is more code to write but never waits behind a threshold callback trying to catch up with a fast scroll. Every drag in item 04 is tracked through pointer events rather than separate mouse and touch listeners, and prefers-reduced-motion is documented on MDN alongside the other three.

Can PDF Viewer UI Calculate Scroll and Zoom Together Without a Library?

If you've searched can pdf viewer ui calculate scroll and zoom together without a library, the answer sitting inside item 09 is yes for the specific pairing it demonstrates: item 01's getBoundingClientRect()-based scroll ratio and item 02's pointer-anchored transform-origin scale run side by side on the same toolbar, each reading its own input — scroll position for one, wheel or pinch coordinate for the other — and writing to its own output without either one waiting on the other's calculation to finish. What keeps them from fighting over the same frame is that neither technique owns shared global state — computeCurrent() only ever reads scrollTop and writes a CSS class, while applyWheel() only ever reads pointer coordinates and writes a transform — so folding a third calculation like item 08's byte-ratio ring onto the same page is a matter of adding one more independent read-and-write pair, not untangling the first two.

Questions Worth Answering Before You Wire Up One of These Nine

Does item 06's rotation snap instantly to each 90-degree step?

No — pressing the button only raises the target angle by ROTATE_SNAP_DEG; a separate lerp (current += (target - current) * 0.18) closes the gap toward that target gradually every frame, so the page sweeps continuously through the angles in between rather than cutting straight from one 90-degree position to the next, and boxSize() recalculates the frame's aspect ratio at every one of those in-between angles too.

Which of the nine repaints the most of the frame, and why?

Item 07 leads at 67.6% cumulative area because its easing scroll redraws the document container's scroll position across many frames rather than animating one small element, with item 01 close behind at 59.6% for the same reason applied to its own thumbnail-synced scroll container.

Is item 03's search box reading real file text, or a pdf viewer ui ux shortcut over something simpler?

It is a shortcut, by design — find() matches only against a small planted words array using indexOf(q) === 0, a starts-with comparison rather than a full-text search over any real file bytes, since these nine builds work over simulated pages rather than an actual parsed document.

Sources and Further Reading

IntersectionObserver, requestAnimationFrame(), prefers-reduced-motion, and pointer events are documented on MDN and cover the browser APIs behind all nine calculations above.

Enter the archive password

The password is inside this article. You will find it as you read.