Merge highlights into results; size for the blog column; pipeline step buttons

index.html

@@ -401,6 +401,7 @@ pre.code .lang{
 .anim .m{color:var(--dim)} .anim .w{color:var(--hi)} .anim .g{color:var(--acc)}
 .anim .miss{color:var(--ink)} .anim .hit{color:var(--acc)}
 .ctl{background:none;border:1px solid var(--rule);color:var(--dim);font:inherit;padding:.1rem 1ch;cursor:pointer}
+.ctls{display:flex; gap:.5ch; align-items:center}
 .ctl:hover{color:var(--acc);border-color:var(--acc-dim)}
 
 footer{margin:6rem 0 0; padding-top:1.5rem; border-top:1px solid var(--rule); color:var(--dim); font-size:.9em}
@@ -461,7 +462,7 @@ html{scroll-behavior:smooth}
   </div>
 
   <div class="panel" id="pScaling" hidden>
-    <p>Batch encoding matters most in data pipelines, where a tokenizer must process many inputs at once. How well it scales across CPU cores depends on how much state the threads have to share. In the M4 native-thread sweep, v1 scales from one to eight workers at <b>76%</b> of linear.</p>
+    <p>Batch encoding matters most in data pipelines, where a tokenizer must process many inputs at once. How well it scales across CPU cores depends on how much state the threads have to share. In a native-thread sweep on Apple M4 Max, v1 scales from one to eight workers at <b>76%</b> of linear.</p>
     <div class="repro" data-repro="threads">
       <div class="scroll"><div class="chart" id="mtLine"></div></div>
       <p class="note">Absolute throughput as workers are added, v1 against the released library, on a linear axis from zero.</p>
@@ -523,7 +524,7 @@ html{scroll-behavior:smooth}
   <div class="key-wins">
     <article class="key-win">
       <h3>multilingual by design</h3>
-      <p>UTF-8 uses more bytes for many characters outside Latin scripts, and tokenizer implementations can compound that cost with extra splitting work. Performance work often centers English. V1 treats non-Latin languages as part of the performance target.</p>
+      <p>UTF-8 uses more bytes for many characters outside Latin scripts, and tokenizer implementations can compound that cost with extra splitting work. Performance work often centers on English. V1 treats non-Latin languages as part of the performance target.</p>
       <div class="mini-chart" id="keyLanguageChart"></div>
     </article>
     <article class="key-win">
@@ -549,7 +550,7 @@ html{scroll-behavior:smooth}
   <p>The model stage is where most of the work described here happens. Eight of the ten model families measured in this article use byte pair encoding, or BPE. BPE starts from the bytes of a pre-token and repeatedly joins the highest ranked adjacent pair until no ranked pair remains. The ranking is learned when the tokenizer is trained and ships with it, so the same text always produces the same IDs. A merge never crosses a pre-token boundary. The other two families use WordPiece and Unigram, the two other model types the library supports.</p>
   <p>The <a href="https://huggingface.co/docs/tokenizers/pipeline">tokenization pipeline</a> page documents the four stages. <a href="https://huggingface.co/docs/transformers/tokenizer_summary">Tokenization algorithms</a> documents BPE, WordPiece and Unigram.</p>
   <div class="anim" id="a-pipe">
-    <div class="cap"><span>one sentence through the pipeline <span class="dim">/ real tokenizer output</span></span><button class="ctl" data-toggle="a-pipe">pause</button></div>
+    <div class="cap"><span>one sentence through the pipeline <span class="dim">/ real tokenizer output</span></span><span class="ctls"><button class="ctl" data-step="a-pipe" data-dir="-1" aria-label="previous frame">◀</button><button class="ctl" data-toggle="a-pipe">pause</button><button class="ctl" data-step="a-pipe" data-dir="1" aria-label="next frame">▶</button></span></div>
     <pre class="pipe" id="pipe" aria-label="the five pipeline stages"></pre>
     <div class="tabs mdl" role="tablist" id="mtabs"></div>
     <pre class="walk" id="walk"></pre>
@@ -686,14 +687,25 @@ const reduced = matchMedia("(prefers-reduced-motion: reduce)").matches;
 
 /* ---- animations ------------------------------------------------------- */
 const running = {};
+// step(t, dir): t is the running frame count, dir is which way this call moves.
+// dir is 0 on the first paint, 1 for each interval tick, and -1 or 1 when a
+// reader uses the step buttons. An animation that just counts can ignore dir; an
+// animation a reader can walk backwards through needs it, because t alone cannot
+// say whether the last move was forward or back.
 function toggler(id, step, fps){
   let t = 0, on = !reduced;
   running[id] = on;
   const btn = document.querySelector(`[data-toggle="${id}"]`);
-  if (btn) btn.onclick = () => { running[id] = !running[id]; btn.textContent = running[id] ? "pause" : "play"; };
+  const label = () => { if (btn) btn.textContent = running[id] ? "pause" : "play"; };
+  if (btn) btn.onclick = () => { running[id] = !running[id]; label(); };
   if (btn && reduced) btn.textContent = "play";
-  step(0);
-  setInterval(() => { if (running[id]) step(++t); }, 1000 / fps);
+  // Stepping implies wanting to look at a frame, so it pauses first.
+  document.querySelectorAll(`[data-step="${id}"]`).forEach(b => {
+    const dir = Number(b.dataset.dir) || 1;
+    b.onclick = () => { running[id] = false; label(); t += dir; step(t, dir); };
+  });
+  step(0, 0);
+  setInterval(() => { if (running[id]) step(++t, 1); }, 1000 / fps);
 }
 
 /* ---- decorative rules ------------------------------------------------- */
@@ -1229,9 +1241,11 @@ renderCrates();
     };
   });
 
-  toggler("a-pipe", () => {
-    const f = seq[tick % seq.length];
-    tick++;
+  // tick is kept here rather than taken from the toggler's counter because the
+  // model tabs reset it: switching model restarts the walk at its first frame.
+  toggler("a-pipe", (t, dir) => {
+    tick = ((tick + dir) % seq.length + seq.length) % seq.length;
+    const f = seq[tick];
     light(f.box);
     $("#walk").innerHTML = `<span class="k">${f.box} · ${f.name}</span>`
       + `<span class="d">${" ".repeat(Math.max(1, 14 - f.name.length))}${esc(f.desc)}</span>\n`
@@ -1756,8 +1770,15 @@ addEventListener("resize", () => { clearTimeout(rt); rt = setTimeout(drawAll, 12
      so scrolling="no" cannot be relied on. A few pixels of reflow at an unlucky
      width would otherwise raise a scrollbar inside the frame, on top of the
      blog's own. HEIGHTS in make_blog_post.py carries the slack that makes
-     hiding the overflow safe rather than lossy. */
+     hiding the overflow safe rather than lossy.
+
+     Hiding it unconditionally forced every box to be sized for the worst case,
+     a 320px phone, which left a desktop reader staring at hundreds of pixels of
+     blank. So the boxes are sized for the blog's reading column instead, and
+     below that width the figure scrolls rather than clipping: a scrollbar on a
+     phone is honest, silent truncation is not. */
   html, body{overflow:hidden}
+  @media (max-width:640px){ html, body{overflow:auto} }
   /* body's background normally propagates to the canvas. Paint it directly so
      the slack below the content does not depend on that rule. */
   html{background:var(--bg)}