npm - @toclocoinc/lattice-grid - Versions diffs - 1.11.0 → 1.12.0 - Mend

@toclocoinc/lattice-grid 1.11.0 → 1.12.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (21) hide show

package/README.md +34 -34
package/docs/AI-SKILL.md +22 -22
package/docs/API.html +2910 -247
package/docs/CHART-CODES.md +60 -60
package/docs/api-detail.html +365 -365
package/lattice-grid.d.ts +345 -73
package/lattice-grid.esm.min.js +493 -58
package/lattice-grid.min.cjs +493 -58
package/lattice-grid.min.css +1 -1
package/lattice-grid.min.js +493 -58
package/modules/charts.esm.min.js +308 -18
package/modules/devtools.esm.min.js +8 -8
package/modules/dhtmlx-compat.esm.min.js +499 -64
package/modules/htmx.esm.min.js +460 -59
package/modules/htmx.min.cjs +460 -59
package/modules/htmx.min.js +460 -59
package/modules/react.esm.min.js +2 -2
package/modules/svelte.esm.min.js +2 -2
package/modules/vue.esm.min.js +2 -2
package/modules/webcomponent.esm.min.js +493 -58
package/package.json +1 -1

package/docs/api-detail.html CHANGED Viewed

@@ -3,16 +3,16 @@
 <head>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
-<meta name="description" content="Lattice Grid — a high-performance JavaScript data grid with no dependencies and no build step. What every part of the API does, and why.">
+<meta name="description" content="Lattice Grid, a high-performance JavaScript data grid with no dependencies and no build step. What every part of the API does, and why.">
 <!--
-  Lattice Grid — developer guide.
+  Lattice Grid: developer guide.
   Copyright (c) 2026 TOCLOCO Inc. All rights reserved.
   Self-contained: no stylesheet, script or font is fetched, so this opens from
   disk, from a file share or from behind a firewall with nothing else present.
   API.html is the reference; this is the explanation.
 -->
-<title>Lattice Grid — Developer Guide</title>
+<title>Lattice Grid: Developer Guide</title>
 <style>
   /* ---------------------------------------------------------------
      Palette lifted from the grid's own theme, so the reference reads as an
@@ -210,7 +210,7 @@
   a { color: var(--accent); }
-  /* Inline identifiers — the primary content of the whole document. */
+  /* Inline identifiers, the primary content of the whole document. */
   code {
     font-family: var(--mono);
     font-size: 0.885em;
@@ -238,7 +238,7 @@
   .kw { color: var(--accent); }
   /* ---------------------------------------------------------------
-     Reference tables. Dense, hairline, sticky-headed — the grid's own
+     Reference tables. Dense, hairline, sticky-headed, the grid's own
      visual language, and the right density for scanning an API.
      --------------------------------------------------------------- */
   .table-wrap {
@@ -387,7 +387,7 @@
   }
   /* Why a thing is the way it is. Distinct from .note, which is a
-     caveat — this is the reasoning, and it is the part a developer
+     caveat: this is the reasoning, and it is the part a developer
      evaluating the product actually reads. */
   .why {
     /* Constrained to the reading measure plus its own padding. Left to fill
@@ -553,7 +553,7 @@ createGrid(element, { locale: 'fr-FR', messages: FR_FR });</code></pre>
     <p>Where <code>locale</code> is not set, the grid takes the language the page declares in its <code>lang</code> attribute. Overrides merge over the default, so translating part of the interface leaves the remainder in English rather than showing raw keys, and a key that is not in the catalogue is ignored with a warning.</p>
-    <p>Catalogues ship for twenty-one locales: British and American English, French (France and Canada), Italian, Spanish, Brazilian Portuguese, German, Dutch, Swedish, Danish, Norwegian, Finnish, Polish, Czech, Hungarian, Romanian, Ukrainian, Greek, Japanese and Arabic. Each is an export of the package, so importing one does not reduce what is bundled. <code>EN_US</code> is a partial overlay carrying only what differs from British English and merging over it. <code>AR_SA</code> is an alias for <code>AR</code> rather than a separate catalogue — Arabic ships pan-Arabic, and a region appears in a name only where two variants exist. For anything else, <code>resolveCatalogue(tag)</code> resolves a tag to a catalogue and falls back to the base language, so <code>ar-EG</code> and <code>es-MX</code> both find one. <code>FR_CA</code> is a complete catalogue that follows Quebec usage where it differs — a column there is <em>figée</em> rather than <em>épinglée</em>.</p>
+    <p>Catalogues ship for twenty-one locales: British and American English, French (France and Canada), Italian, Spanish, Brazilian Portuguese, German, Dutch, Swedish, Danish, Norwegian, Finnish, Polish, Czech, Hungarian, Romanian, Ukrainian, Greek, Japanese and Arabic. Each is an export of the package, so importing one does not reduce what is bundled. <code>EN_US</code> is a partial overlay carrying only what differs from British English and merging over it. <code>AR_SA</code> is an alias for <code>AR</code> rather than a separate catalogue: Arabic ships pan-Arabic, and a region appears in a name only where two variants exist. For anything else, <code>resolveCatalogue(tag)</code> resolves a tag to a catalogue and falls back to the base language, so <code>ar-EG</code> and <code>es-MX</code> both find one. <code>FR_CA</code> is a complete catalogue that follows Quebec usage where it differs, a column there is <em>figée</em> rather than <em>épinglée</em>.</p>
     <p class="section-note">None of the translations has been reviewed by a native speaker. They are structurally complete and checked for placeholder integrity and plural coverage, but they are a starting point for review rather than finished copy.</p>
@@ -565,17 +565,17 @@ createGrid(element, { locale: 'fr-FR', messages: FR_FR });</code></pre>
   'count.rows': { one: '{count} rad', other: '{count} rader' },
 }</code></pre>
-    <p>Placeholders are named, so word order is yours to choose. The parameter called <code>count</code> selects the plural form, using the categories the language actually has — English needs two, French treats zero as singular, Arabic has six. Numbers are formatted for the locale automatically; do not format them yourself.</p>
+    <p>Placeholders are named, so word order is yours to choose. The parameter called <code>count</code> selects the plural form, using the categories the language actually has: English needs two, French treats zero as singular, Arabic has six. Numbers are formatted for the locale automatically; do not format them yourself.</p>
     <p><code>MESSAGE_KEYS</code> lists every key. <code>auditCatalogue(yours)</code> returns what is missing and what is not a real key, which is the quickest way to check a translation before shipping it.</p>
     <div class="why">
-      <p><strong>The grid is checked in the other direction too.</strong> <code>auditCatalogue</code> tells you a catalogue is complete — that a translator covered every key. It cannot tell you the grid only ever renders text that came from a catalogue in the first place, and a string written into the source passes every test, because the tests assert on the English the grid happens to produce.</p>
+      <p><strong>The grid is checked in the other direction too.</strong> <code>auditCatalogue</code> tells you a catalogue is complete: that a translator covered every key. It cannot tell you the grid only ever renders text that came from a catalogue in the first place, and a string written into the source passes every test, because the tests assert on the English the grid happens to produce.</p>
       <p>So the build refuses one. Any literal reaching an element's text, or an announced attribute such as <code>aria-label</code>, <code>title</code> or <code>placeholder</code>, has to come from the catalogue. That is what stops a localised grid drifting back into English one plausible change at a time.</p>
     </div>
     <h3>Right-to-left</h3>
-    <p>The grid lays out right to left. Set <code>direction: 'rtl'</code> outright, or leave it unset and it follows the element's computed <code>dir</code> first and the locale second — so <code>locale: 'ar'</code> renders right to left with no further configuration, and a grid inside a page that has already declared <code>dir="rtl"</code> agrees with it.</p>
+    <p>The grid lays out right to left. Set <code>direction: 'rtl'</code> outright, or leave it unset and it follows the element's computed <code>dir</code> first and the locale second, so <code>locale: 'ar'</code> renders right to left with no further configuration, and a grid inside a page that has already declared <code>dir="rtl"</code> agrees with it.</p>
     <pre><code>createGrid(element, { locale: 'ar' });        <span class="cmt">// direction follows the locale</span>
 createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so outright</span></code></pre>
@@ -584,7 +584,7 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
     <p>Pinned columns swap sides, the header and pinned rows follow the scroll the other way, and column resize and reorder, the fill handle, annotations, the facet band, the comment marker and menu placement all follow the writing direction rather than the physical one.</p>
-    <p><strong>Not yet exercised with bidirectional text.</strong> The layout is verified, but only with Latin text in a right-to-left grid. Cells, headings and editors holding actual Arabic or Hebrew — particularly mixed with Latin text or numbers — have not been tested.</p>
+    <p><strong>Not yet exercised with bidirectional text.</strong> The layout is verified, but only with Latin text in a right-to-left grid. Cells, headings and editors holding actual Arabic or Hebrew (particularly mixed with Latin text or numbers) have not been tested.</p>
 <h2 id="what">What it is</h2>
     <p class="lead-in">
@@ -596,7 +596,7 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
     <p class="lead-in">
       A grid of a hundred thousand rows and thirty columns is three million values. Held as row
       objects, that is three million property lookups per pass and a great deal of memory the
-      garbage collector has opinions about. Lattice stores each column as one typed array — numbers
+      garbage collector has opinions about. Lattice stores each column as one typed array: numbers
       in a <code>Float64Array</code>, repeated strings as integers into a dictionary, booleans as
       bits in a bitset.
     </p>
@@ -614,7 +614,7 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
       flatten. Each remembers its result and the inputs it was computed from.
     </p>
     <div class="why">
-      <p>Change a sort and the filter stage is not recomputed — its inputs did not change. Edit a
+      <p>Change a sort and the filter stage is not recomputed: its inputs did not change. Edit a
       cell in a column nobody sorts, filters or groups on and <em>none</em> of the first five run;
       only the totals move. This is why a grid that is heavily filtered and grouped still feels
       immediate when you type in a cell.</p>
@@ -629,7 +629,7 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
     <h3>No dependencies, and no build step</h3>
     <p class="lead-in">
-      Not "few dependencies" — none, at runtime and at build time. No lodash, no date library, no
+      Not "few dependencies": none, at runtime and at build time. No lodash, no date library, no
       virtualisation library, no icon font. The bundler and minifier that produce the distribution
       are part of the repository. You can drop two files into a page and be finished.
     </p>
@@ -640,7 +640,7 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
     </div>
     <h2 id="install">Install</h2>
-    <p class="lead-in">Two files. Nothing is fetched at runtime — no CDN, no font, no sprite sheet — however the two files themselves got onto the page. Four equally valid ways to get them there:</p>
+    <p class="lead-in">Two files. Nothing is fetched at runtime (no CDN, no font, no sprite sheet) however the two files themselves got onto the page. Four equally valid ways to get them there:</p>
     <div class="example">
       <p class="example__label">npm</p>
@@ -651,7 +651,7 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
     </div>
     <div class="example">
-      <p class="example__label">jsDelivr — no npm install, no bundler</p>
+      <p class="example__label">jsDelivr, no npm install, no bundler</p>
       <pre><code>&lt;link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@1.7.1/lattice-grid.min.css"&gt;
 &lt;script src="https://cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@1.7.1/lattice-grid.min.js"&gt;&lt;/script&gt;
@@ -678,7 +678,7 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
     <div class="note">
       <p><strong>jsDelivr mirrors every version published to npm</strong> at
-      <code>cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@&lt;version&gt;/&lt;file&gt;</code> — pin an
+      <code>cdn.jsdelivr.net/npm/@toclocoinc/lattice-grid@&lt;version&gt;/&lt;file&gt;</code>: pin an
       exact version, e.g. <code>@1.7.1</code> rather than <code>@latest</code>, so a later release
       does not change what a page already in production loads. The same convention reaches a
       module: <code>.../modules/htmx.esm.min.js</code>, <code>.../modules/dhtmlx-compat.esm.min.js</code>,
@@ -694,9 +694,9 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
         <thead><tr><th>File</th><th>Gzipped</th><th>What it is</th></tr></thead>
         <tbody>
           <tr><td class="sig">lattice-grid.min.js</td><td class="desc">The whole product as a UMD build. Defines <code>window.LatticeGrid</code>, and works with AMD and CommonJS loaders.</td></tr>
-          <tr><td class="sig">lattice-grid.min.css</td><td class="desc">The single stylesheet. Without it the grid is in the DOM and unreadable — no widths, no scrolling, no theme.</td></tr>
+          <tr><td class="sig">lattice-grid.min.css</td><td class="desc">The single stylesheet. Without it the grid is in the DOM and unreadable, no widths, no scrolling, no theme.</td></tr>
           <tr><td class="sig">lattice-grid.esm.min.js</td><td class="desc">The same, as an ES module.</td></tr>
-          <tr><td class="sig">lattice-core.esm.js</td><td class="desc">Headless core for Node — no renderer. See <a href="#export-guide">server-side export</a>.</td></tr>
+          <tr><td class="sig">lattice-core.esm.js</td><td class="desc">Headless core for Node, no renderer. See <a href="#export-guide">server-side export</a>.</td></tr>
           <tr><td class="sig">lattice-grid.d.ts</td><td class="desc">Type declarations.</td></tr>
         </tbody>
       </table>
@@ -724,7 +724,7 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
     <p class="lead-in">
       A few things happened there without being asked for. <code>region</code> got a title of
-      "Region" — a field name is turned into a readable heading rather than left as-is. The number
+      "Region", a field name is turned into a readable heading rather than left as-is. The number
       column right-aligned itself, because numbers align right and a grid should not need telling.
       The date column parsed <code>2024-03-11</code> and rendered <code>11 Mar 2024</code>. And
       <code>total: 'sum'</code> put a figure in the totals row.
@@ -733,7 +733,7 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
     <div class="why">
       <p><strong>On <code>rowKey</code>:</strong> it names the field that identifies a row. Set it
       if you have one. Without it the grid assigns keys per row object, which is enough for
-      sorting, filtering, selection and copying within a session — but not across a reload, because
+      sorting, filtering, selection and copying within a session, but not across a reload, because
       new objects are new rows. Change tracking, streaming dedupe, selection persistence and remote
       reload all want a real key, and the grid warns once, naming them.</p>
     </div>
@@ -785,7 +785,7 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
       deep-comparing a million-row array on every render would cost more than the reload it
       avoids. Build <code>columns</code> once outside the component, or memoise it; a fresh array
       literal on each render tells the grid the columns changed and it will rebuild them. Rows are
-      the same — hand back a new array when the data actually changes, not before.</p>
+      the same: hand back a new array when the data actually changes, not before.</p>
       <p>StrictMode is handled. React 18 deliberately mounts, unmounts and mounts again in
       development; the effect cleanup destroys the first grid, so the second starts clean and
       nothing leaks.</p>
@@ -808,8 +808,8 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
 /&gt;</code></pre>
     </div>
     <div class="why">
-      <p>Events are re-emitted under dashed names — <code>cell:changed</code> becomes
-      <code>@cell-changed</code> — because a colon in a Vue template is directive syntax and
+      <p>Events are re-emitted under dashed names: <code>cell:changed</code> becomes
+      <code>@cell-changed</code>, because a colon in a Vue template is directive syntax and
       cannot be bound. Every event in the table below is declared in <code>emits</code>.</p>
     </div>
@@ -840,20 +840,20 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
     </div>
     <div class="why">
-      <p><strong>What the adapters do not do.</strong> They add no features and wrap no API — the
+      <p><strong>What the adapters do not do.</strong> They add no features and wrap no API: the
       grid instance is the same object the vanilla examples use, and anything without a prop is
       reached through it directly (via the ref in React, <code>expose</code> in Vue, or a
       reference you keep in Svelte). Nothing is proxied, so nothing can lag behind the grid.</p>
     </div>
-    <h3>The web component is self-contained &mdash; use it or the API, not both</h3>
+    <h3>The web component is self-contained: use it or the API, not both</h3>
     <p class="lead-in">
       The custom element carries the grid inside it, rather than being handed one. That is the point
       of the format: you add the element and it works, with nothing to wire up.
     </p>
     <div class="why">
       <p><strong>Do not load it alongside <code>createGrid</code> in the same page.</strong> You would
-      get two independent copies of the grid, and the cost is not the download &mdash; it is that
+      get two independent copies of the grid, and the cost is not the download, it is that
       each copy keeps its own registries. A renderer, editor, data type or variant registered
       through one is invisible to the other, and a licence key validated in one is not validated in
       the other. Nothing errors; the custom renderer you registered simply never appears.</p>
@@ -865,9 +865,9 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
     <h2 id="dhtmlx-guide">Coming from dhtmlx Grid</h2>
     <p class="lead-in">
       <code>lattice-grid/modules/dhtmlx-compat</code> exposes a <code>Grid</code> class shaped
-      like dhtmlx's own <code>dhx.Grid</code> &mdash; the same constructor call, the same
+      like dhtmlx's own <code>dhx.Grid</code>, the same constructor call, the same
       <code>.data</code>, <code>.selection</code>, <code>.history</code>, <code>.export</code> and
-      <code>.events</code> namespaces &mdash; sitting on top of a real Lattice grid underneath.
+      <code>.events</code> namespaces: sitting on top of a real Lattice grid underneath.
       Swap the import and, for the surface below, the calling code does not change.
     </p>
@@ -884,7 +884,7 @@ createGrid(element, { direction: 'rtl' });    <span class="cmt">// or say so out
 });
 grid.events.on('cellClick', (row, column, event) =&gt; {
-  <span class="cmt">// row and column carry .id, row's own fields sit alongside it &mdash;</span>
+  <span class="cmt">// row and column carry .id, row's own fields sit alongside it , </span>
   <span class="cmt">// the same shape dhtmlx's own IRow/ICol declare.</span>
 });</code></pre>
     </div>
@@ -908,19 +908,19 @@ grid.events.on('cellClick', (row, column, event) =&gt; {
       <code>afterColumnHide</code>, <code>afterColumnShow</code>, <code>afterExpand</code>,
       <code>afterCollapse</code>, <code>afterSelect</code>, <code>afterUnSelect</code>,
       <code>afterCopy</code>, <code>afterRowDrop</code> and <code>scroll</code>. Grid-level
-      <code>dragItem: 'row'</code> becomes <code>rowReorder: true</code> &mdash; same-grid
+      <code>dragItem: 'row'</code> becomes <code>rowReorder: true</code>: same-grid
       drag-to-reorder.</p>
       <p><code>cellClick</code>, <code>cellDblClick</code>, <code>cellRightClick</code>,
       <code>afterEditStart</code>, <code>afterEditEnd</code> and <code>afterSort</code> call your
-      handler with dhtmlx's own positional arguments &mdash; <code>(row, column, event)</code>,
-      not Lattice's own event object &mdash; because that is dhtmlx's own documented signature for
+      handler with dhtmlx's own positional arguments: <code>(row, column, event)</code>,
+      not Lattice's own event object, because that is dhtmlx's own documented signature for
       them. <code>afterRowDrop</code> calls your handler with <code>(data, event)</code>, firing
-      from either a same-grid reorder settling or a row landing here from another grid &mdash;
+      from either a same-grid reorder settling or a row landing here from another grid ,
       dhtmlx has one event name for what Lattice models as two. Every other mapped event calls your
       handler with Lattice's own event object, under Lattice's own field names, since a wrong guess
       at a fabricated positional shape is worse than an honest one.</p>
-      <p><strong>Index means current display order</strong> &mdash; after sort, filter and
-      grouping &mdash; everywhere <code>.data</code> takes or returns one. dhtmlx is not fully
+      <p><strong>Index means current display order</strong>: after sort, filter and
+      grouping: everywhere <code>.data</code> takes or returns one. dhtmlx is not fully
       consistent about this across its own methods; this is the one meaning, held everywhere.</p>
       <p><strong>Cross-grid dragging needs an explicit <code>rowTransfer</code>.</strong> dhtmlx
       lets any two grids with <code>dragItem: 'row'</code> on the same page exchange rows by
@@ -932,15 +932,15 @@ grid.events.on('cellClick', (row, column, event) =&gt; {
     <div class="why">
       <p><strong>What is not.</strong> Every <code>before*</code>/<code>can*</code>/<code>cancel*</code>
       event is unmapped: dhtmlx's convention lets a handler return <code>false</code> to cancel the
-      action, and Lattice has no cancelable-event model to honour that with &mdash; approximating one
+      action, and Lattice has no cancelable-event model to honour that with: approximating one
       would silently ignore a <code>return false</code> a caller depends on. Row and column
-      drag-<em>negotiation</em> events &mdash; <code>beforeRowDrag</code>, <code>dragRowOut</code>,
+      drag-<em>negotiation</em> events (<code>beforeRowDrag</code>, <code>dragRowOut</code>,
       <code>canRowDrop</code>, <code>cancelRowDrop</code>, <code>beforeRowDrop</code> and their
-      column equivalents &mdash; are unmapped for the same reason: each can refuse or steer a drag
+      column equivalents) are unmapped for the same reason: each can refuse or steer a drag
       mid-gesture, which Lattice has no live protocol to offer. <code>export.pdf()</code> and
-      <code>export.png()</code> throw &mdash; there is no raster export to translate to.
+      <code>export.png()</code> throw: there is no raster export to translate to.
       <code>.rangeSelection</code> is offered on a best-effort basis and its range shape is this
-      wrapper's own design, not dhtmlx's — a genuine <code>RangeSelection</code> module is a
+      wrapper's own design, not dhtmlx's, a genuine <code>RangeSelection</code> module is a
       separate part of dhtmlx's own product, and this wrapper does not know its exact shape.
       Classic <code>dhtmlXGridObject</code> (pre-Suite 5, string-configured,
       index-addressed) is a different product in every respect that matters here and is not covered
@@ -954,7 +954,7 @@ grid.events.on('cellClick', (row, column, event) =&gt; {
     <p class="lead-in">
       <code>lattice-grid/modules/htmx</code> lets a grid survive htmx's own DOM swaps,
       hydrate from a server-rendered <code>&lt;table&gt;</code>, and drive sort, filter and
-      infinite scroll over plain htmx requests &mdash; the server owns pagination and the
+      infinite scroll over plain htmx requests, the server owns pagination and the
       request lifecycle; this module only wires the grid's own state to it. Importing it
       is enough for the lifecycle half: it registers itself against
       <code>document</code> on load.
@@ -977,7 +977,7 @@ autoInit(document);</code></pre>
     <div class="why">
       <p><strong>One file, not two.</strong> <code>autoInit</code> comes from
-      <code>modules/htmx</code> itself here, not from the base package — this module
+      <code>modules/htmx</code> itself here, not from the base package: this module
       already carries a complete, independently-bundled copy of <code>createGrid</code> and
       everything it depends on, the same way every module built this way does (a bundle
       inlines what it imports; it has no way to reach across to a copy some other
@@ -986,18 +986,18 @@ autoInit(document);</code></pre>
       again for the base package's own <code>createGrid</code>. This module re-exports
       <code>createGrid</code>, <code>autoInit</code>, <code>hydrateTable</code>,
       <code>readTable</code>, <code>serialiseState</code> and <code>restoreState</code>
-      precisely so a page never has to choose between the two — it is the complete package
+      precisely so a page never has to choose between the two, it is the complete package
       for anything touching htmx, not an add-on alongside the base one.</p>
       <p><strong>Surviving a swap.</strong> <code>autoInit(root)</code> builds a grid on
       every <code>[data-lattice-grid]</code> element under <code>root</code> it has not
-      already built one for &mdash; idempotent, so calling it again after a swap only picks
+      already built one for: idempotent, so calling it again after a swap only picks
       up what is new. A sibling <code>&lt;script type="application/json"
       data-lattice-config&gt;</code> supplies columns and options; without one, a
       <code>&lt;table&gt;</code> element is hydrated instead, reading its header row for
       columns and its body rows for data, then replacing itself with the grid. Once
       imported, this module listens for htmx's own <code>htmx:beforeCleanupElement</code>
       and <code>htmx:load</code> and calls <code>grid.destroy()</code> / <code>autoInit</code>
-      at the right moments automatically &mdash; a grid inside a swapped-out subtree is torn
+      at the right moments automatically, a grid inside a swapped-out subtree is torn
       down before htmx detaches it; a grid inside newly-loaded content is built without
       re-scanning the whole page. A page with JavaScript disabled sees the plain
       <code>&lt;table&gt;</code>, still readable, since it is only ever replaced once the
@@ -1015,10 +1015,10 @@ autoInit(document);</code></pre>
 <span class="kw">const</span> grid = createGrid(host, { columns, rows: [], rowKey: 'id' });
 <span class="kw">const</span> COLUMNS = columns.map(c =&gt; ({ field: c.field }));
-<span class="cmt">// Replaces the view outright &mdash; fires whenever sort or filter changes.</span>
+<span class="cmt">// Replaces the view outright: fires whenever sort or filter changes.</span>
 driveServerMode(grid, document.getElementById('query-trigger'), { columns: COLUMNS });
-<span class="cmt">// Appends the next chunk &mdash; fires as the grid's own visible rows near the end.</span>
+<span class="cmt">// Appends the next chunk: fires as the grid's own visible rows near the end.</span>
 driveInfiniteScroll(grid, document.getElementById('sentinel'), { columns: COLUMNS });</code></pre>
       <pre><code>&lt;div id="query-trigger" hx-get="/rows" hx-trigger="lattice:query-changed" hx-swap="none" hidden&gt;&lt;/div&gt;
 &lt;div id="sentinel" hx-get="/rows" hx-trigger="revealed, lattice:scroll-near-end" hx-swap="none" hidden&gt;&lt;/div&gt;</code></pre>
@@ -1026,38 +1026,38 @@ driveInfiniteScroll(grid, document.getElementById('sentinel'), { columns: COLUMN
     <div class="why">
       <p><strong>Two triggers, two elements, deliberately.</strong> A sort or filter
-      change and a scroll asking for more rows are different operations &mdash; one
-      replaces every loaded row, the other appends to them &mdash; and there is no way to
+      change and a scroll asking for more rows are different operations: one
+      replaces every loaded row, the other appends to them, and there is no way to
       tell the two apart once a response has landed if they share a trigger. Each function
       configures the request (<code>offset</code>, <code>limit</code>, <code>sort</code>,
-      <code>filters</code> &mdash; a small, stable convention any server-side language can
+      <code>filters</code>, a small, stable convention any server-side language can
       read with a JSON parser and a slice) and reads the response back into the grid
       itself, so <code>hx-swap="none"</code> is required on both: htmx sends the request
       and nothing else, since a grid is not an HTML swap target.</p>
       <p><strong>The sentinel's own trigger names two events for a reason.</strong>
       <code>revealed</code> is htmx's own once-per-element mechanism and gets the very
-      first chunk, firing the moment htmx has processed the element &mdash; reliable
+      first chunk, firing the moment htmx has processed the element: reliable
       because it needs nothing from this module's own timing. Every chunk after that fires
       through <code>lattice:scroll-near-end</code>, which <code>driveInfiniteScroll</code>
       dispatches once the grid's own visible row window comes within
       <code>opts.threshold</code> rows (default 20) of what is loaded. That split matters
       for a fixed-height, virtualised grid specifically: nothing about it ever leaves the
-      page's own viewport once first revealed &mdash; new rows land inside the grid's own
-      scroll area, not the page's &mdash; so a page-scroll-only trigger would fire exactly
+      page's own viewport once first revealed: new rows land inside the grid's own
+      scroll area, not the page's, so a page-scroll-only trigger would fire exactly
       once and then go silent. Reading the grid's own render position instead is what
       makes every later chunk fire on genuine scroll, not on the repaint a successful load
       causes by itself.</p>
       <p><strong>Out-of-band updates.</strong> <code>driveOobUpdates(grid, opts)</code>
       watches for htmx's own out-of-band swaps landing on an element carrying
       <code>data-lattice-row="&lt;key&gt;"</code>, reads the swapped fragment as that row's
-      cells, and applies it to the grid in place &mdash; scroll position, selection and
+      cells, and applies it to the grid in place: scroll position, selection and
       filter state are untouched, since nothing about the view is reloaded.</p>
       <p><strong>Browser history.</strong> On <code>htmx:beforeHistorySave</code>, every
-      live grid's state (<code>serialiseState</code> &mdash; sort, filters, column order and
+      live grid's state (<code>serialiseState</code>: sort, filters, column order and
       widths, scroll position and selection, base64url-encoded and diffed against defaults
       so an untouched grid costs almost nothing) is written onto its element as
       <code>data-lattice-state</code>, which rides along in htmx's own history snapshot. On
-      <code>htmx:historyRestore</code>, it is read back and applied &mdash; browser back
+      <code>htmx:historyRestore</code>, it is read back and applied: browser back
       returns a visitor to the sort, filter and scroll position they had, not a blank
       slate. A cache miss (the page was re-fetched from the server) restores nothing, since
       a fresh response is already the truth.</p>
@@ -1070,13 +1070,13 @@ driveInfiniteScroll(grid, document.getElementById('sentinel'), { columns: COLUMN
     <div class="why">
       <p><strong>What this does not do.</strong> It does not call <code>fetch</code> or
-      <code>htmx.ajax()</code> anywhere &mdash; htmx owns every request end to end; this
+      <code>htmx.ajax()</code> anywhere: htmx owns every request end to end; this
       only supplies the moment and the parameters, and reads the response back in. It does
       not import htmx: every htmx-specific call goes through <code>globalThis.htmx</code>,
       read at call time, so loading this module never requires htmx to already be on the
       page, only to be present by the time a driven request actually fires. It ships as
       ESM and as a plain <code>&lt;script src&gt;</code> build with no bundler required,
-      with zero runtime dependencies beyond the grid itself and, at call time, htmx &mdash;
+      with zero runtime dependencies beyond the grid itself and, at call time, htmx ,
       but because it references the grid's own internals directly rather than the copy
       already on the page, the bundle carries a full copy of the grid core alongside its
       own code, the same trade-off the web component and dhtmlx wrappers already make.</p>
@@ -1084,7 +1084,7 @@ driveInfiniteScroll(grid, document.getElementById('sentinel'), { columns: COLUMN
     <h2 id="concepts">How it works</h2>
     <p class="lead-in">
-      Four ideas explain most of the API. If you read nothing else, read this section — the rest of
+      Four ideas explain most of the API. If you read nothing else, read this section, the rest of
       the guide assumes it.
     </p>
@@ -1092,7 +1092,7 @@ driveInfiniteScroll(grid, document.getElementById('sentinel'), { columns: COLUMN
     <p class="lead-in">
       Your data objects are held by reference and never copied. What the grid hands back is a
       <em>row wrapper</em>: your object under <code>data</code>, plus the identity and position the
-      grid needs — <code>key</code>, <code>index</code>, <code>level</code>, whether it is a group
+      grid needs: <code>key</code>, <code>index</code>, <code>level</code>, whether it is a group
       row, whether it is expanded.
     </p>
     <div class="example">
@@ -1111,20 +1111,20 @@ grid.rows.values('r1')       <span class="cmt">// every readable column, as an o
     <h3>Display index and row key are different things</h3>
     <p class="lead-in">
-      A display index is a position — row 0 is whatever is at the top right now, and it changes when
+      A display index is a position: row 0 is whatever is at the top right now, and it changes when
       you sort. A key identifies a record for as long as it exists. Anything that has to survive a
       sort, a filter or a page change is keyed.
     </p>
     <div class="split">
       <div>
-        <p class="split__title split__title--no">Position — fragile</p>
+        <p class="split__title split__title--no">Position: fragile</p>
         <pre><code>grid.rows.get(4)
 grid.selection.setRange({
   startRow: 0, endRow: 9, columns: ['cap'],
 })</code></pre>
       </div>
       <div>
-        <p class="split__title split__title--yes">Identity — durable</p>
+        <p class="split__title split__title--yes">Identity: durable</p>
         <pre><code>grid.rows.byKey('CIR-100042')
 grid.edit.setCells([
   { key: 'CIR-100042', colId: 'cap', value: 99 },
@@ -1147,7 +1147,7 @@ grid.on('*', e =&gt; console.log(e.type, e));   <span class="cmt">// wildcard, f
 off();                                       <span class="cmt">// every subscription returns its own unsubscribe</span></code></pre>
     </div>
     <div class="why">
-      <p><code>origin</code> tells you where a change came from — <code>'user'</code>,
+      <p><code>origin</code> tells you where a change came from: <code>'user'</code>,
       <code>'api'</code>, <code>'init'</code>, <code>'undo'</code>. It is what stops a feedback
       loop when you persist changes: a handler that writes to a server on
       <code>cell:changed</code> should usually ignore its own <code>'undo'</code> traffic, or at
@@ -1178,14 +1178,14 @@ LatticeGrid.getVersion();   <span class="cmt">// the same, when you have no grid
     </p>
     <h2 id="columns-guide">Defining columns</h2>
     <p class="lead-in">
-      A column is an object with a <code>field</code> — the path to read from your data — and
+      A column is an object with a <code>field</code> (the path to read from your data) and
       whatever else it needs. Everything except <code>field</code> or <code>id</code> is optional.
     </p>
     <div class="sig-line">{ field: 'site.address.postcode', title: 'Postcode', type: 'text', width: 110 }</div>
     <p class="lead-in">
       <code>field</code> reads a dot path, so nested data needs no flattening. The column's
-      <code>id</code> defaults to the field, which is what you use everywhere else — in
+      <code>id</code> defaults to the field, which is what you use everywhere else: in
       <code>setCells</code>, in filters, in saved state.
     </p>
@@ -1222,7 +1222,7 @@ LatticeGrid.getVersion();   <span class="cmt">// the same, when you have no grid
   },
 }
-<span class="cmt">// compute(deps, ctx) — deps holds the resolved values of the columns you</span>
+<span class="cmt">// compute(deps, ctx): deps holds the resolved values of the columns you</span>
 <span class="cmt">// named; ctx carries { data, row, column, grid, context } when you need more.</span></code></pre>
     </div>
     <div class="why">
@@ -1249,13 +1249,13 @@ LatticeGrid.getVersion();   <span class="cmt">// the same, when you have no grid
       <code>grid.columns.fit()</code> distributes the viewport width across visible columns, and
       <code>autoSize</code> measures content.
     </p>
-    <p>Both are also on the column menu &mdash; Move left, Move right, Move to start, Move to end, and
-      a Width submenu &mdash; and bound to the keyboard with a heading focused: <kbd>Alt</kbd> with a
+    <p>Both are also on the column menu: Move left, Move right, Move to start, Move to end, and
+      a Width submenu, and bound to the keyboard with a heading focused: <kbd>Alt</kbd> with a
       left or right arrow resizes, <kbd>Shift</kbd> with one moves the column. Neither operation
       depends on dragging.</p>
     <p>A pinned region holds the edge of the viewport only while there is something to scroll. Where
-      the columns are narrower than the grid &mdash; fixed widths, or a <code>flex</code> column that
-      has reached its <code>max</code> &mdash; nothing scrolls, so the pinned columns sit directly
+      the columns are narrower than the grid: fixed widths, or a <code>flex</code> column that
+      has reached its <code>max</code>: nothing scrolls, so the pinned columns sit directly
       after the centre ones and the spare width falls beyond them all, at the right of the grid.</p>
     <p>To take that space up rather than leave it, give a column <code>flex</code> and no
       <code>max</code>, or call <code>grid.columns.fit()</code>. Note that removing a column&rsquo;s
@@ -1278,10 +1278,10 @@ LatticeGrid.getVersion();   <span class="cmt">// the same, when you have no grid
           <tr><td class="name">Temporal</td><td class="desc"><code>datetime</code>, <code>time</code>, <code>duration</code></td></tr>
           <tr><td class="name">Network</td><td class="desc"><code>ipv4</code>, <code>ipv6</code>, <code>cidr</code>, <code>mac</code></td></tr>
           <tr><td class="name">Numeric bases</td><td class="desc"><code>hex</code>, <code>hex8</code>, <code>hex16</code>, <code>hex32</code>, <code>binary</code>, <code>binary8</code>, <code>octal</code></td></tr>
-          <tr><td class="name">Units — computing</td><td class="desc"><code>bytes</code>, <code>megabytes</code>, <code>gigabytes</code>, <code>bitrate</code>, <code>gigabits</code></td></tr>
-          <tr><td class="name">Units — physical</td><td class="desc"><code>metres</code>, <code>millimetres</code>, <code>kilometres</code>, <code>grams</code>, <code>kilograms</code>, <code>tonnes</code>, <code>seconds</code>, <code>milliseconds</code>, <code>hours</code></td></tr>
-          <tr><td class="name">Units — engineering</td><td class="desc"><code>speed</code>, <code>kph</code>, <code>mph</code>, <code>knots</code>, <code>acceleration</code>, <code>area</code>, <code>hectares</code>, <code>volume</code>, <code>cubicMetres</code>, <code>energy</code>, <code>kilowattHours</code>, <code>power</code>, <code>kilowatts</code>, <code>force</code>, <code>pressure</code>, <code>bar</code>, <code>psi</code>, <code>torque</code>, <code>density</code>, <code>flow</code>, <code>litresPerMinute</code>, <code>radians</code>, <code>degrees</code></td></tr>
-          <tr><td class="name">Units — electrical and scientific</td><td class="desc"><code>voltage</code>, <code>current</code>, <code>resistance</code>, <code>capacitance</code>, <code>inductance</code>, <code>charge</code>, <code>conductance</code>, <code>fluxDensity</code>, <code>luminousFlux</code>, <code>illuminance</code>, <code>substance</code>, <code>absorbedDose</code>, <code>equivalentDose</code>, <code>radioactivity</code>, <code>luminousIntensity</code>, <code>doseRate</code>, <code>rpm</code>, <code>angularVelocity</code>, <code>ppm</code>, <code>ppb</code>, <code>basisPoints</code>, <code>molarity</code>, <code>massFlow</code>, <code>tonnesPerHour</code>, <code>viscosity</code>, <code>kinematicViscosity</code>, <code>thermalConductivity</code>, <code>specificHeat</code>, <code>frequency</code></td></tr>
+          <tr><td class="name">Units: computing</td><td class="desc"><code>bytes</code>, <code>megabytes</code>, <code>gigabytes</code>, <code>bitrate</code>, <code>gigabits</code></td></tr>
+          <tr><td class="name">Units: physical</td><td class="desc"><code>metres</code>, <code>millimetres</code>, <code>kilometres</code>, <code>grams</code>, <code>kilograms</code>, <code>tonnes</code>, <code>seconds</code>, <code>milliseconds</code>, <code>hours</code></td></tr>
+          <tr><td class="name">Units: engineering</td><td class="desc"><code>speed</code>, <code>kph</code>, <code>mph</code>, <code>knots</code>, <code>acceleration</code>, <code>area</code>, <code>hectares</code>, <code>volume</code>, <code>cubicMetres</code>, <code>energy</code>, <code>kilowattHours</code>, <code>power</code>, <code>kilowatts</code>, <code>force</code>, <code>pressure</code>, <code>bar</code>, <code>psi</code>, <code>torque</code>, <code>density</code>, <code>flow</code>, <code>litresPerMinute</code>, <code>radians</code>, <code>degrees</code></td></tr>
+          <tr><td class="name">Units: electrical and scientific</td><td class="desc"><code>voltage</code>, <code>current</code>, <code>resistance</code>, <code>capacitance</code>, <code>inductance</code>, <code>charge</code>, <code>conductance</code>, <code>fluxDensity</code>, <code>luminousFlux</code>, <code>illuminance</code>, <code>substance</code>, <code>absorbedDose</code>, <code>equivalentDose</code>, <code>radioactivity</code>, <code>luminousIntensity</code>, <code>doseRate</code>, <code>rpm</code>, <code>angularVelocity</code>, <code>ppm</code>, <code>ppb</code>, <code>basisPoints</code>, <code>molarity</code>, <code>massFlow</code>, <code>tonnesPerHour</code>, <code>viscosity</code>, <code>kinematicViscosity</code>, <code>thermalConductivity</code>, <code>specificHeat</code>, <code>frequency</code></td></tr>
           <tr><td class="name">Temperature</td><td class="desc"><code>celsius</code>, <code>fahrenheit</code>, <code>kelvin</code></td></tr>
           <tr><td class="name">Structured</td><td class="desc"><code>json</code>, <code>colour</code>, <code>rating</code>, <code>percent</code></td></tr>
         </tbody>
@@ -1326,14 +1326,14 @@ dataTypes: {
     <div class="why">
       <p><strong>Ambiguous units are refused, not guessed.</strong> A US gallon and an imperial
       gallon differ by about a fifth, and "ton" means three different masses. Each has its own
-      symbol — <code>gal (US)</code>, <code>ton (UK)</code> — and the bare word is claimed by all of
+      symbol: <code>gal (US)</code>, <code>ton (UK)</code>, and the bare word is claimed by all of
       them, so typing it is rejected rather than resolved. A <code>gal</code> silently taken as US
       in a UK deployment is data corruption that reads as rounding.</p>
       <p>The same rule catches case: <code>mV</code> and <code>MV</code> are a billion apart, so both
       exact spellings work and the case-folded <code>mv</code> is refused.</p>
       <p><strong>Customary units are accepted but never chosen.</strong> <code>display: 'auto'</code>
       walks the coherent SI ladder only. With the calorie, the BTU and the kilojoule all on one
-      ladder, 4,000 J would render as <code>3.79 BTU</code> — auto picks the largest unit that fits,
+      ladder, 4,000 J would render as <code>3.79 BTU</code>: auto picks the largest unit that fits,
       and the BTU happens to be larger than the kilojoule. Ask for a BTU by name and you get one.</p>
     </div>
@@ -1348,7 +1348,7 @@ dataTypes: {
     <div class="why">
       <p><strong>Angles wrap, so their mean is replaced.</strong> The average of 359° and 1° is 0°,
-      and the arithmetic answer — 180° — is a confident, plausible number pointing in exactly the
+      and the arithmetic answer (180°) is a confident, plausible number pointing in exactly the
       wrong direction. A <code>degrees</code> or <code>radians</code> column averages by direction
       instead, and reports nothing where the angles cancel and there is no mean direction to give.
       The <em>sum</em> stays arithmetic, because a total rotation of 720° is two turns and that is a
@@ -1356,8 +1356,8 @@ dataTypes: {
       <p><strong>Temperature is its own type, not a unit.</strong> Every other unit is a
       multiplication; Celsius to Fahrenheit carries an offset, and zero Celsius is not zero
       anything, so no factor converts it. <code>celsius</code>, <code>fahrenheit</code> and
-      <code>kelvin</code> convert on input — type <code>72 F</code> into a Celsius column and it
-      stores 22.2 — and <strong>refuse to be summed</strong>: twenty degrees plus twenty degrees is
+      <code>kelvin</code> convert on input: type <code>72 F</code> into a Celsius column and it
+      stores 22.2, and <strong>refuse to be summed</strong>: twenty degrees plus twenty degrees is
       not forty degrees, and a footer saying so would be believed.</p>
     </div>
@@ -1371,14 +1371,14 @@ dataTypes: {
       <p class="example__label">One key each, and the types arrive</p>
       <pre><code>columns: [
   { field: 'sku' },                          <span class="cmt">// text</span>
-  { field: 'quantity' },                     <span class="cmt">// number — aligned right, numeric filter</span>
+  { field: 'quantity' },                     <span class="cmt">// number: aligned right, numeric filter</span>
   { field: 'shipped' },                      <span class="cmt">// date</span>
-  { field: 'expedited' }                     <span class="cmt">// boolean — checkbox editor</span>
+  { field: 'expedited' }                     <span class="cmt">// boolean: checkbox editor</span>
 ]</code></pre>
     </div>
     <p>Sampling happens once, when rows first arrive. A grid built empty and filled later infers on
     that first load, so fetching after construction is no reason to declare types you would otherwise
-    leave out. Later loads keep the types already settled on — data that arrives tomorrow cannot
+    leave out. Later loads keep the types already settled on: data that arrives tomorrow cannot
     change a column's type under a formatter or an editor that was configured around it.</p>
     <p>Only the built-in names are ever inferred. Candidates are tried in registration order, so every
     string reaches <code>text</code> and every number reaches <code>number</code> before an extended
@@ -1397,7 +1397,7 @@ dataTypes: {
       parsed back into a value, how the value is formatted, which filter kind the header offers, how
       the column is stored, and what lands in Excel and on the clipboard. That is what inference
       supplies for free on a plain column, and what naming a type explicitly gives you where the data
-      cannot say it — a duration, a byte count, a network address.</p>
+      cannot say it, a duration, a byte count, a network address.</p>
     </div>
     <h3>Dates are stored as strings, deliberately</h3>
@@ -1413,7 +1413,7 @@ dataTypes: {
       convert.</p>
       <p>It is also faster and smaller: ISO 8601 sorts lexicographically in the same order it sorts
       chronologically, so a date column sorts as text, and repeated dates dictionary-encode well.</p>
-      <p>When you genuinely mean an instant — a log timestamp — use <code>datetime</code> and set
+      <p>When you genuinely mean an instant (a log timestamp) use <code>datetime</code> and set
       <code>format.timeZone</code>.</p>
     </div>
@@ -1429,14 +1429,14 @@ format: {                                    <span class="cmt">// when the short
   style: 'currency', currency: 'GBP', decimals: 2,
   negative: 'parentheses',                   <span class="cmt">// (£1,234.50)</span>
   negativeClass: 'is-loss',
-  nullDisplay: '—',
+  nullDisplay: ', ',
 }</code></pre>
     </div>
     <h3>Lookups</h3>
     <p class="lead-in">
       A lookup column stores an id and shows a label. Sorting, filtering, grouping, copying and
-      exporting all use the label, because that is the thing the user is reasoning about — but the
+      exporting all use the label, because that is the thing the user is reasoning about, but the
       data keeps the id.
     </p>
     <div class="example">
@@ -1487,7 +1487,7 @@ columns: [{ field: 'flags', type: 'reg32' }],
     </p>
     <div class="example">
-      <p class="example__label">Decorations — the common cases, without writing a renderer</p>
+      <p class="example__label">Decorations, the common cases, without writing a renderer</p>
       <pre><code>cell: { decoration: 'pill' }                     <span class="cmt">// a status chip</span>
 cell: { decoration: 'bar', min: 0, max: 1 }      <span class="cmt">// an inline bar</span>
 cell: { decoration: 'heat', ramp: 'redGreen' }   <span class="cmt">// a heat fill</span>
@@ -1495,7 +1495,7 @@ cell: { decoration: 'dot' }                      <span class="cmt">// a leading
     </div>
     <div class="example">
-      <p class="example__label">Variants — mapping a value to a semantic colour</p>
+      <p class="example__label">Variants: mapping a value to a semantic colour</p>
       <pre><code>cell: {
   decoration: 'pill',
   variant: { when: [
@@ -1505,7 +1505,7 @@ cell: { decoration: 'dot' }                      <span class="cmt">// a leading
 }</code></pre>
     </div>
     <div class="why">
-      <p>Variants are semantic tokens rather than colours — <code>danger</code>, not
+      <p>Variants are semantic tokens rather than colours: <code>danger</code>, not
       <code>#c22b2b</code>. The theme decides what danger looks like, and it looks the same in the
       status pill, the filter chip and the validation message. Changing the palette is one custom
       property, not a search for hex codes.</p>
@@ -1525,7 +1525,7 @@ columns: [{ field: 'history', cell: { render: 'sparkline' } }],</code></pre>
     <div class="why">
       <p><code>refresh</code> returning <code>true</code> is the contract that makes recycling work:
       it means "I updated in place, keep this element". Return <code>false</code> and the grid
-      rebuilds the cell. A renderer that only implements <code>render</code> still works — it is
+      rebuilds the cell. A renderer that only implements <code>render</code> still works, it is
       just rebuilt on every reuse.</p>
     </div>
@@ -1540,8 +1540,8 @@ cell: { template: '&lt;span&gt;{{{ value }}}&lt;/span&gt;' }</code></pre>
     <div class="why">
       <p><strong>The flag permits markup, not code.</strong> Without it, <code>{{ }}</code> escapes
       and a <code>{{{ }}}</code> segment is refused outright. With it, an interpolated value may
-      carry presentational markup — <code>&lt;b&gt;</code>, <code>&lt;a href&gt;</code>, a
-      <code>&lt;span&gt;</code> — and everything executable is still stripped from it:
+      carry presentational markup: <code>&lt;b&gt;</code>, <code>&lt;a href&gt;</code>, a
+      <code>&lt;span&gt;</code>, and everything executable is still stripped from it:
       <code>&lt;script&gt;</code>, <code>&lt;iframe&gt;</code>, <code>&lt;style&gt;</code> and the
       other code-bearing tags, every <code>on*</code> handler attribute, and
       <code>javascript:</code> or <code>data:</code> URLs including entity-encoded spellings of
@@ -1562,21 +1562,21 @@ cell: { template: '&lt;span&gt;{{{ value }}}&lt;/span&gt;' }</code></pre>
     </p>
     <div class="example">
       <p class="example__label">By scope</p>
-      <pre><code><span class="cmt">// Cells and columns — declared on the column</span>
+      <pre><code><span class="cmt">// Cells and columns: declared on the column</span>
 { field: 'margin', cell: {
   class: 'tabular',
   classWhen: { 'is-loss': (p) =&gt; p.value &lt; 0 },
   style: (p) =&gt; ({ fontWeight: p.value &gt; 1e6 ? 650 : 400 }),
 }}
-<span class="cmt">// Rows — on the grid</span>
+<span class="cmt">// Rows: on the grid</span>
 rowClass: (p) =&gt; p.data.slaBreached ? 'row-breach' : null,
 rowStyle: (p) =&gt; p.data.region === 'AMER' ? { borderLeft: '3px solid #7c3aed' } : null,</code></pre>
     </div>
     <div class="why">
       <p>All of these are re-evaluated on every repaint and remove what they added last time first.
       That is not caution. Rows and cells come from pools, so an element that carried a class for
-      one row will later carry a different row — a class written once and left alone smears down
+      one row will later carry a different row, a class written once and left alone smears down
       the grid as the user scrolls.</p>
     </div>
@@ -1596,8 +1596,8 @@ rowStyle: (p) =&gt; p.data.region === 'AMER' ? { borderLeft: '3px solid #7c3aed'
     <p class="lead-in">
       Four themes ship. With no <code>theme</code> set, the grid follows the viewer's
       <code>prefers-color-scheme</code> between light and dark; naming one pins it.
-      Density is separate — <code>compact</code>, <code>standard</code>, <code>comfortable</code>
-      or <code>spacious</code> — and combines with any of them.
+      Density is separate: <code>compact</code>, <code>standard</code>, <code>comfortable</code>
+      or <code>spacious</code>, and combines with any of them.
     </p>
     <div class="example">
       <p class="example__label">Pinning a theme, at build time or at runtime</p>
@@ -1611,14 +1611,14 @@ grid.set('theme', <span class="kw">null</span>);   <span class="cmt">// back to
         <tbody>
           <tr><td class="name"><code>light</code></td><td class="desc">The default. Follows <code>prefers-color-scheme</code> when <code>theme</code> is unset.</td></tr>
           <tr><td class="name"><code>dark</code></td><td class="desc">The same palette inverted, with the accent and status hues re-picked for a dark ground rather than reused.</td></tr>
-          <tr><td class="name"><code>high-contrast</code></td><td class="desc">Not "dark with more contrast". Text is 21:1 and borders 6.1:1 against the background, where the other themes sit near 1.3:1 on borders — WCAG 1.4.11 asks for 3:1 on the boundaries a user has to find. Cell borders are drawn rather than implied, selected rows carry an outline as well as a fill, and every status pill has a solid border so it does not depend on hue alone.</td></tr>
+          <tr><td class="name"><code>high-contrast</code></td><td class="desc">Not "dark with more contrast". Text is 21:1 and borders 6.1:1 against the background, where the other themes sit near 1.3:1 on borders, WCAG 1.4.11 asks for 3:1 on the boundaries a user has to find. Cell borders are drawn rather than implied, selected rows carry an outline as well as a fill, and every status pill has a solid border so it does not depend on hue alone.</td></tr>
           <tr><td class="name"><code>terminal</code></td><td class="desc">A phosphor console: one hue on near-black, monospaced throughout. Status is carried by brightness rather than colour, so the palette stays a palette.</td></tr>
         </tbody>
       </table>
     </div>
     <h3>Forced colours</h3>
     <p class="lead-in">
-      Windows High Contrast Mode replaces the palette outright &mdash; that is the point of it, and
+      Windows High Contrast Mode replaces the palette outright: that is the point of it, and
       no stylesheet should fight it. What the grid does instead is translate every piece of meaning
       it normally carries in a background tint into something the mode preserves.
     </p>
@@ -1626,8 +1626,8 @@ grid.set('theme', <span class="kw">null</span>);   <span class="cmt">// back to
       which forced colours do not render, and gains a rule in its place. Status pills, fill
       decorations, progress tracks and histogram bars each gain a border, because a fill with no
       edge is invisible once its colour is discarded. Diff states stop depending on hue altogether:
-      added, removed and changed are told apart by border style &mdash; solid, dashed and doubled
-      &mdash; since the mode offers no way to keep four distinct colours.</p>
+      added, removed and changed are told apart by border style: solid, dashed and doubled
+     : since the mode offers no way to keep four distinct colours.</p>
     <p>Two things deliberately keep their colour, declared with
       <code>forced-color-adjust</code>: a colour swatch, where the colour <em>is</em> the value being
       shown, and a collaborator's presence colour, which is how one person is told from another.
@@ -1645,21 +1645,21 @@ grid.set('theme', <span class="kw">null</span>);   <span class="cmt">// back to
     <p class="lead-in">
       Every selector in the stylesheet is namespaced under <code>.lattice</code>, so the grid cannot
       restyle your page. From 1.4.0 the reverse is also true: the grid gives the elements it builds
-      a floor for the properties a page is most likely to set on a bare tag — margin, padding,
+      a floor for the properties a page is most likely to set on a bare tag: margin, padding,
       border, radius, background, shadow, text transform and letter spacing, plus type and colour on
       form controls, which inherit neither.
     </p>
     <div class="why">
       <p><strong>Why this is needed at all.</strong> A grid is mounted inside somebody else's
-      stylesheet. A rule as ordinary as <code>section { padding: 5.5rem 0 }</code> — a marketing
-      page, a CMS theme, a Tailwind preflight — matches by tag name, and the grid builds parts of
+      stylesheet. A rule as ordinary as <code>section { padding: 5.5rem 0 }</code>, a marketing
+      page, a CMS theme, a Tailwind preflight: matches by tag name, and the grid builds parts of
       its own interface from those tags: the tool panel's filter rows are
       <code>&lt;section&gt;</code> elements. Without the reset, 5.5rem of somebody else's padding
       lands on every one of them.</p>
       <p>The reset uses no <code>!important</code>. It is specificity (0,1,1) and every rule that
       dresses a grid element is (0,2,0) or higher, so the grid's own styling always wins and the
-      reset only fills a gap. Yours wins too, on the same terms: a rule aimed at a Lattice class —
-      <code>.lattice .lat-cell { … }</code> — outranks it, so overriding the grid deliberately works
+      reset only fills a gap. Yours wins too, on the same terms: a rule aimed at a Lattice class ,
+      <code>.lattice .lat-cell { … }</code>: outranks it, so overriding the grid deliberately works
       exactly as before. Only bare-tag rules are shut out.</p>
       <p>It touches box model and decoration only. Nothing in it sets <code>display</code>,
       <code>position</code> or any dimension: those belong to the renderer, and a reset that reached
@@ -1667,7 +1667,7 @@ grid.set('theme', <span class="kw">null</span>);   <span class="cmt">// back to
     </div>
     <h2 id="loading">Loading and updating data</h2>
     <p class="lead-in">
-      Data usually arrives after the grid does. Build it empty, then load — the sort, filters,
+      Data usually arrives after the grid does. Build it empty, then load, the sort, filters,
       grouping and column layout you set up in the meantime all survive and apply to the new data.
     </p>
     <div class="example">
@@ -1682,8 +1682,8 @@ grid.overlay.hide();</code></pre>
     <h3>Incremental changes</h3>
     <p class="lead-in">
-      <code>rows.load</code> replaces everything. When you have a delta — a websocket message, a
-      save that returned the updated record — apply just that.
+      <code>rows.load</code> replaces everything. When you have a delta, a websocket message, a
+      save that returned the updated record: apply just that.
     </p>
     <div class="example">
       <p class="example__label">Adds, updates and removals in one call</p>
@@ -1698,15 +1698,15 @@ grid.overlay.hide();</code></pre>
     <div class="why">
       <p><strong>An update is a patch.</strong> Fields absent from it are untouched, so a delta
       arriving from a websocket or coming back from a save can be applied as-is without reading the
-      row first. This has to be said explicitly because the opposite &mdash; assigning the patch
-      over the row &mdash; looks identical for a caller who happens to send whole rows and silently
+      row first. This has to be said explicitly because the opposite: assigning the patch
+      over the row: looks identical for a caller who happens to send whole rows and silently
       destroys data for one who does not.</p>
       <p><strong>Coalescing merges fields rather than keeping the last message.</strong> A feed
       sending <code>{price}</code> and <code>{volume}</code> as separate messages inside one window
       keeps both. Coalescing may reorder work; it may not lose it.</p>
       <p><strong>Flushing happens on a frame, with a timer behind it.</strong> A queued batch lands
       on a paint boundary, which is what makes "ten thousand updates, one repaint" true rather than
-      usually true &mdash; a timer can fire twice between two paints. But
+      usually true, a timer can fire twice between two paints. But
       <code>requestAnimationFrame</code> is not guaranteed to fire at all: a backgrounded tab stops
       firing it entirely. So a frame and a timer are armed together and the first to arrive wins. In
       a foreground tab the frame always wins, at ~16ms against a 50ms fallback; in a hidden tab the
@@ -1715,7 +1715,7 @@ grid.overlay.hide();</code></pre>
       <p><strong>A long flush defers rather than blocks.</strong> <code>updates.budgetMs</code> caps
       how long one flush spends applying; over budget, the remainder returns to the queue and lands
       next frame, and the promise a caller is holding resolves when their rows actually land rather
-      than when the first slice does. Slicing is by row and only for updates &mdash; a partially
+      than when the first slice does. Slicing is by row and only for updates, a partially
       applied row is not a state the store should be in, and splitting a structural change would
       re-run the pipeline twice for one batch. <code>stats().deferrals</code> rising steadily means
       the feed is arriving faster than the grid can apply it.</p>
@@ -1727,7 +1727,7 @@ grid.overlay.hide();</code></pre>
       <p>This runs the minimum pipeline. An update touching no sorted, filtered or grouped column
       skips those stages entirely and only the totals and the affected cells refresh. Adds and
       removals are structural and re-run everything.</p>
-      <p>Removals tombstone in place rather than compacting, so every existing index stays valid —
+      <p>Removals tombstone in place rather than compacting, so every existing index stays valid ,
       which is what lets selection, expansion state and cached permutations survive a delete.</p>
     </div>
@@ -1778,7 +1778,7 @@ grid.rows.forEachAll(r =&gt; { total += r.data.amount });   <span class="cmt">//
     <div class="why">
       <p>A remote or paged source holds the page it has fetched, not the whole set, so there is
       nothing there to walk past the filters. It warns and walks what it has rather than quietly
-      returning the filtered rows &mdash; a caller who asked for everything and silently received a
+      returning the filtered rows, a caller who asked for everything and silently received a
       subset gets a number that looks entirely plausible and is wrong.</p>
     </div>
@@ -1799,7 +1799,7 @@ grid.sort.clear();</code></pre>
     <p class="lead-in">
       Clicking a header cycles ascending, descending, none; shift-clicking a second header adds to
       the sort rather than replacing it. A column can supply its own <code>compare</code>, and a
-      type already has one — dates compare chronologically, IP addresses numerically rather than as
+      type already has one: dates compare chronologically, IP addresses numerically rather than as
       strings, durations by length.
     </p>
@@ -1890,7 +1890,7 @@ grid.rows.collapse('EMEA');</code></pre>
       </table>
     </div>
     <p class="lead-in">
-      Nothing has to be configured for this, and the reported number is the same either way —
+      Nothing has to be configured for this, and the reported number is the same either way ,
       where a running value cannot be trusted, the column falls back to a full pass rather than
       reporting a value it is unsure of.
     </p>
@@ -1898,7 +1898,7 @@ grid.rows.collapse('EMEA');</code></pre>
     <h3 id="show-total-in-header">showTotalInHeader</h3>
     <p class="lead-in">
       Under grouping or pivot, a totalled column's cells hold an aggregate rather than a row's own
-      value. On by default, the heading says which — a small <code>SUM</code> line above
+      value. On by default, the heading says which, a small <code>SUM</code> line above
       <code>Capacity</code>, <code>AVERAGE</code> above <code>Margin</code>. The heading returns to
       the column's own title when grouping and pivot are both off.
     </p>
@@ -1909,7 +1909,7 @@ grid.rows.collapse('EMEA');</code></pre>
     <p class="lead-in">
       The reduction goes on its own line rather than reading <code>Sum of Capacity</code> across
       one. A header cell reserves width for its sort, filter and menu buttons whether or not they
-      are showing, so the label gets well under half the column — on a default column, 54px of
+      are showing, so the label gets well under half the column: on a default column, 54px of
       129px. One line truncated to <code>Sum o…</code>, trading the column's identity for its
       reduction. Stacked, it costs no width at all.
     </p>
@@ -1936,7 +1936,7 @@ pivot: { groupTotals: 'after', totalsLabel: 'All regions' }</code></pre>
       the near edge, beside the row headings; <code>'after'</code> puts it at the far edge, which is
       where a spreadsheet puts a grand total.</p>
       <p><strong>It costs a column, not a pass.</strong> A pivoted group row still carries its
-      reduction over every one of its leaves — which is exactly the total across all pivot values —
+      reduction over every one of its leaves, which is exactly the total across all pivot values ,
       so these columns read a number that has already been computed. They also count towards
       <code>maxColumns</code>, since they are columns like any other.</p>
       <p><strong>Opt in.</strong> Omitted, a pivot has the columns it has always had, so the option
@@ -1950,7 +1950,7 @@ pivot: { groupTotals: 'after', totalsLabel: 'All regions' }</code></pre>
     </div>
     <p class="lead-in">
       By default a total describes what is on screen: filter the grid and every total moves with
-      it. Setting this to <code>false</code> makes the filter a lens instead — totals report the
+      it. Setting this to <code>false</code> makes the filter a lens instead: totals report the
       whole dataset no matter what is filtered out. Both the grand total and each group total
       follow the setting, so a group row shows the total for every row belonging to that group,
       not only the ones currently visible.
@@ -1958,7 +1958,7 @@ pivot: { groupTotals: 'after', totalsLabel: 'All regions' }</code></pre>
     <p class="lead-in">
       A group whose every row the filter removed has no row to appear on, but its rows still count
       toward the totals above it. Editing a hidden row moves the totals, because it is part of the
-      dataset they describe — under the default it does not, because it is not part of the view
+      dataset they describe: under the default it does not, because it is not part of the view
       they describe.
     </p>
     <p class="lead-in">
@@ -1981,7 +1981,7 @@ pivot: { groupTotals: 'after', totalsLabel: 'All regions' }</code></pre>
     <p class="lead-in">
       Group totals re-reduce every totalled column on every change, including columns the change
       did not touch. Switching this on reduces only the columns whose values actually moved, and
-      an update that rewrites a field with the value it already held reduces nothing at all —
+      an update that rewrites a field with the value it already held reduces nothing at all ,
       which is what a feed resending unchanged fields looks like.
     </p>
     <p class="lead-in">
@@ -1993,7 +1993,7 @@ pivot: { groupTotals: 'after', totalsLabel: 'All regions' }</code></pre>
         <tbody>
           <tr><td class="name">One of the four columns</td><td class="desc">15.4ms</td><td class="desc">7.3ms</td></tr>
           <tr><td class="name">All four columns</td><td class="desc">15.0ms</td><td class="desc">14.5ms</td></tr>
-          <tr><td class="name">Nothing — same values rewritten</td><td class="desc">15.6ms</td><td class="desc">7.3ms</td></tr>
+          <tr><td class="name">Nothing: same values rewritten</td><td class="desc">15.6ms</td><td class="desc">7.3ms</td></tr>
         </tbody>
       </table>
     </div>
@@ -2005,14 +2005,14 @@ pivot: { groupTotals: 'after', totalsLabel: 'All regions' }</code></pre>
       <strong>It is off by default because it is an assertion, not just an optimisation.</strong>
       Skipping a column assumes its total depends on nothing but that column's own values. That
       is true of every built-in reduction. It need not be true of a <code>total</code> supplied as
-      a function, which also receives the row, the grid and <code>config.context</code> — such a
+      a function, which also receives the row, the grid and <code>config.context</code>: such a
       total is only recomputed when its own column changes, so a function that reads application
       state outside the column will report the value from the last time that column moved. Leave
       the option off if any of your total functions work that way.
     </p>
     <p class="lead-in">
-      Anything that changes which rows a total covers — adding or removing rows, filtering,
-      sorting, grouping, or changing which columns are totalled — reduces everything again
+      Anything that changes which rows a total covers: adding or removing rows, filtering,
+      sorting, grouping, or changing which columns are totalled: reduces everything again
       regardless of the option.
     </p>
@@ -2043,7 +2043,7 @@ grid.setPinnedRows([], { edge: 'top' });        <span class="cmt">// clear</span
     </div>
     <p class="lead-in">
-      The objects are yours and are rendered through the ordinary column pipeline — value getters,
+      The objects are yours and are rendered through the ordinary column pipeline: value getters,
       formatters, cell renderers and conditional formatting all run, so a pinned row looks like the
       data it sits against without you rebuilding any of that.
     </p>
@@ -2068,7 +2068,7 @@ grid.setPinnedRows([], { edge: 'top' });        <span class="cmt">// clear</span
         <thead><tr><th>Point</th><th>Behaviour</th></tr></thead>
         <tbody>
           <tr><td class="name">Order</td><td class="desc">Rows appear in the order of the array. At the bottom edge, the grand total comes first and your rows sit below it.</td></tr>
-          <tr><td class="name">Height</td><td class="desc">From <code>rowHeight</code>, including the function form — which is called with the pinned row, so you can measure your own content. The body reserves exactly the strip's height, so no data row hides underneath it.</td></tr>
+          <tr><td class="name">Height</td><td class="desc">From <code>rowHeight</code>, including the function form, which is called with the pinned row, so you can measure your own content. The body reserves exactly the strip's height, so no data row hides underneath it.</td></tr>
           <tr><td class="name">Updating</td><td class="desc">Pass a <em>new</em> array. Array identity is how the grid knows the rows changed; pushing into the array you passed before will not repaint.</td></tr>
           <tr><td class="name">Editing</td><td class="desc">A pinned row has no place in the store to write to, so it is not editable.</td></tr>
         </tbody>
@@ -2078,7 +2078,7 @@ grid.setPinnedRows([], { edge: 'top' });        <span class="cmt">// clear</span
     <h2 id="full-width-rows">Full-width rows</h2>
     <p class="lead-in">
       A row drawn as a single band across every column instead of being divided into them: a
-      section banner, an explanatory note, an empty-group message, a “load more” affordance —
+      section banner, an explanatory note, an empty-group message, a “load more” affordance ,
       anything that belongs between rows and is not itself divided by the columns.
     </p>
@@ -2102,7 +2102,7 @@ grid.setPinnedRows([], { edge: 'top' });        <span class="cmt">// clear</span
     <p class="lead-in">
       The band <strong>holds still while the columns scroll under it</strong>, which is what a
-      banner is for — text that scrolled sideways out of view with the columns would be a worse
+      banner is for: text that scrolled sideways out of view with the columns would be a worse
       version of a cell. It is drawn over the pinned regions as well as the centre, so it genuinely
       spans every column.
     </p>
@@ -2115,8 +2115,8 @@ grid.setPinnedRows([], { edge: 'top' });        <span class="cmt">// clear</span
       between them: <em>full-width</em> changes how a row looks, <em>pinned</em> changes whether a
       row is data at all.</p>
       <p>So if your banners must not appear in an export or a row count, they should not be in the
-      data. If they are section headings that belong with the records they head — and should sort,
-      filter and export alongside them — this is the right tool.</p>
+      data. If they are section headings that belong with the records they head, and should sort,
+      filter and export alongside them: this is the right tool.</p>
       <p>One consequence worth stating plainly: sorting reorders banners along with everything
       else, because the predicate follows the row and not its position. Either do not offer sorting
       on such a grid, or sort on a key that keeps each section together.</p>
@@ -2153,7 +2153,7 @@ grid.on('row:moved', ({ key, from, to }) =&gt; {
       <p><strong>The order is your data, not a view of it.</strong> A move reorders the array you
       gave the grid and tells you it happened; writing it somewhere permanent is yours, because
       only you know where the order lives. A grid that rearranged rows on screen and stopped there
-      would look finished and lose the order on the next load — which is worse than not offering
+      would look finished and lose the order on the next load, which is worse than not offering
       the feature.</p>
       <p>If the save fails, move it back: <code>grid.rows.move(key, from)</code>.</p>
     </div>
@@ -2161,7 +2161,7 @@ grid.on('row:moved', ({ key, from, to }) =&gt; {
     <p class="lead-in">
       <strong>It refuses while a sort, filter or grouping is active</strong>, and says why out loud
       rather than springing the row back in silence. The reason is that dropping between two
-      visible rows says nothing about where the row belongs in the underlying array — under a
+      visible rows says nothing about where the row belongs in the underlying array: under a
       filter there may be hidden rows between them, and under a sort the displayed order is
       something the grid computed rather than something the data says. Rather than pick an
       interpretation and put the row somewhere you did not ask for, the move is declined.
@@ -2171,7 +2171,7 @@ grid.on('row:moved', ({ key, from, to }) =&gt; {
     <h2 id="row-transfer">Moving rows between grids</h2>
     <p class="lead-in">
-      A row can be dragged out of one grid and into another — a picker beside a basket, an inbox
+      A row can be dragged out of one grid and into another, a picker beside a basket, an inbox
       beside a queue, an available list beside an assigned one.
     </p>
@@ -2210,10 +2210,10 @@ createGrid(right, { columns, rows,
       <p><strong>Off by default, and both ends have to agree.</strong> Rows leaving a grid is a data
       change you have to want: a grid that quietly let its rows be dragged away would lose one to a
       mis-drag, and there is no gesture a user would think to try to get it back. A one-way
-      relationship is a declaration on both grids rather than a convention — the sender refuses to
+      relationship is a declaration on both grids rather than a convention, the sender refuses to
       receive, and the receiver never starts a drag.</p>
-      <p><strong>The target adds before the source removes.</strong> If the add is refused — a
-      duplicate key, most likely — nothing is removed, so a rejected transfer loses no data. The
+      <p><strong>The target adds before the source removes.</strong> If the add is refused: a
+      duplicate key, most likely: nothing is removed, so a rejected transfer loses no data. The
       other order would delete a row and then discover it had nowhere to go.</p>
       <p><strong>The row object is cloned, not shared.</strong> Two grids holding the same object
       would edit each other's rows through it, which is the sort of coupling nobody goes looking for
@@ -2229,7 +2229,7 @@ createGrid(right, { columns, rows,
     <p class="lead-in">
       <strong>Picking up a row shows it, wherever the pointer goes.</strong> The row being dragged
       dims in its own grid, and a small label naming it follows the pointer for as long as the drag
-      is held — over the gap between two grids, over one that is about to refuse the drop, anywhere
+      is held: over the gap between two grids, over one that is about to refuse the drop, anywhere
       the row's own dimming cannot reach. Both clear on release, and a handle press never also starts
       a range selection underneath it.
     </p>
@@ -2258,7 +2258,7 @@ createGrid(right, { columns, rows,
     <div class="why">
       <p><strong>Only tagged columns are ever hidden.</strong> That is the rule the whole feature
       turns on. A financial grid with sixty month columns also has an account name, a total and a
-      variance, and none of those belong to a year — if filtering hid them the view would be
+      variance, and none of those belong to a year: if filtering hid them the view would be
       useless, and tagging every column merely to keep it visible would be busywork. So "show 2024"
       does not mean "hide everything else"; it means "hide tagged columns that are not 2024".</p>
       <p>The same rule runs the other way: an untagged column you hid yourself stays hidden, because
@@ -2266,7 +2266,7 @@ createGrid(right, { columns, rows,
     </div>
     <p class="lead-in">
-      A column can carry more than one tag, which gives you a second axis for free — tag each month
+      A column can carry more than one tag, which gives you a second axis for free: tag each month
       with its year <em>and</em> its quarter, and a user can pick either. The dropdown lists tags in
       the order they were declared rather than alphabetically, since they are usually already in a
       meaningful sequence and sorting would put <code>Q10</code> before <code>Q2</code>.
@@ -2287,7 +2287,7 @@ createGrid(right, { columns, rows,
     <h3>Headings without the controls</h3>
     <p class="lead-in">
       A dense grid often wants the heading and nothing else. <code>showColumnFunctions: false</code>
-      leaves each heading as its label, with no sort, filter or menu control — they are not drawn
+      leaves each heading as its label, with no sort, filter or menu control, they are not drawn
       rather than hidden, so the label has the whole cell. Sorting, filtering and the column menu
       stay reachable through the API, the keyboard and the tool panel; only the furniture goes. The
       resize grip stays, since dragging a column wider is a view adjustment rather than a function
@@ -2328,7 +2328,7 @@ createGrid(right, { columns, rows,
     <div class="why">
       <p><strong>What is not shared is the design.</strong> If sort, filters and selection travelled
-      too, this would not be a feature — it would be one grid with extra steps. The reason to have
+      too, this would not be a feature, it would be one grid with extra steps. The reason to have
       two is that the sections hold different data, so each keeps its own view of it.</p>
       <p>Vertical scroll stays independent for the same reason: the grids hold different numbers of
       rows, and yoking them would make the shorter one run out.</p>
@@ -2336,7 +2336,7 @@ createGrid(right, { columns, rows,
     <p class="lead-in">
       A column one grid has and another does not is skipped rather than invented, and nothing checks
-      that the column sets match — aligning grids with different columns is a caller error that
+      that the column sets match: aligning grids with different columns is a caller error that
       produces a visibly wrong result rather than a silent one. Destroying any grid releases its
       link and leaves the rest working.
     </p>
@@ -2349,8 +2349,8 @@ createGrid(right, { columns, rows,
     <div class="why">
       <p><strong>The failure this prevents is a confident wrong number.</strong> You cannot add
-      decibels — 90&nbsp;dB and 90&nbsp;dB make 93&nbsp;dB, not 180. The mean of a column of rates
-      is not the mean — a 100% conversion on two visits and a 1% conversion on ten thousand average
+      decibels: 90&nbsp;dB and 90&nbsp;dB make 93&nbsp;dB, not 180. The mean of a column of rates
+      is not the mean, a 100% conversion on two visits and a 1% conversion on ten thousand average
       to 1.02%, not 50.5%. Both mistakes produce a plausible figure rather than an error, and a
       footer nobody can check gets used. A missing total gets asked about; a wrong one does not.</p>
     </div>
@@ -2382,7 +2382,7 @@ createGrid(right, { columns, rows,
         <thead><tr><th>Type</th><th>What it does differently</th></tr></thead>
         <tbody>
           <tr><td class="name">decibel</td><td class="desc">Sums and averages in the linear domain and converts back. Power scale, factor 10.</td></tr>
-          <tr><td class="name">decibelAmplitude</td><td class="desc">The same, on the field scale — factor 20, for voltage and current.</td></tr>
+          <tr><td class="name">decibelAmplitude</td><td class="desc">The same, on the field scale: factor 20, for voltage and current.</td></tr>
           <tr><td class="name">ratio</td><td class="desc">Averages by weight, using the column named in <code>typeOptions.weight</code>. Refuses <code>sum</code>, since two rates do not add to a rate.</td></tr>
           <tr><td class="name">percentRate</td><td class="desc">As <code>ratio</code>, displayed with a percent sign.</td></tr>
         </tbody>
@@ -2397,7 +2397,7 @@ createGrid(right, { columns, rows,
     <p class="lead-in">
       Without a weight column the average returns nothing rather than falling back to the
-      unweighted mean — falling back would be the exact mistake the type exists to prevent, arrived
+      unweighted mean: falling back would be the exact mistake the type exists to prevent, arrived
       at silently. Rows with no rate, or no weight, are left out rather than counted as zero.
     </p>
@@ -2418,7 +2418,7 @@ createGrid(element, { stickyGroupHeaders: 3 });       <span class="cmt">// stack
       often not in the page at all: the grid renders a window of rows, and a heading five hundred
       rows above the viewport was recycled long ago. So the pinned heading is synthesised from
       whichever group the top visible row belongs to, which the grid answers by binary search over
-      an index it builds while flattening the rows — the ten-thousandth row of a group costs what
+      an index it builds while flattening the rows, the ten-thousandth row of a group costs what
       the second one does.</p>
       <p>The cap exists because each heading costs a row of viewport. A five-level grouping without
       one would spend a third of the screen describing what the other two thirds contain.</p>
@@ -2432,13 +2432,13 @@ createGrid(element, { stickyGroupHeaders: 3 });       <span class="cmt">// stack
     <p class="lead-in">
       The same answer is available directly as <code>grid.rows.groupHeadings(index)</code>, which
-      returns the enclosing group rows outermost first — for a breadcrumb, or a heading elsewhere on
+      returns the enclosing group rows outermost first, for a breadcrumb, or a heading elsewhere on
       your page.
     </p>
     <h2 id="sources">Working with large data</h2>
     <p class="lead-in">
-      A million rows in memory is fine — that is what the columnar store is for. Beyond that, or
+      A million rows in memory is fine: that is what the columnar store is for. Beyond that, or
       when the data lives behind an API, a source takes over.
     </p>
     <div class="table-wrap">
@@ -2448,7 +2448,7 @@ createGrid(element, { stickyGroupHeaders: 3 });       <span class="cmt">// stack
           <tr><td class="name">memory</td><td class="desc">The default. Everything is present; the grid does all the work.</td></tr>
           <tr><td class="name">paged</td><td class="desc">A page at a time from a server that paginates.</td></tr>
           <tr><td class="name">remote</td><td class="desc">Blocks fetched on demand as the user scrolls, with sort and filter pushed to the server.</td></tr>
-          <tr><td class="name">stream</td><td class="desc">Rows arriving over time — a query that streams, a socket. Promotes to memory once complete.</td></tr>
+          <tr><td class="name">stream</td><td class="desc">Rows arriving over time, a query that streams, a socket. Promotes to memory once complete.</td></tr>
         </tbody>
       </table>
     </div>
@@ -2477,7 +2477,7 @@ createGrid(element, { stickyGroupHeaders: 3 });       <span class="cmt">// stack
       viewport reaches them and cached; changing the sort or the filter invalidates the cache and
       re-queries.</p>
       <p>The <code>filters</code> your callback receives is the same condition tree documented
-      above. You are not handed an opaque object to reverse-engineer — it is the published format,
+      above. You are not handed an opaque object to reverse-engineer, it is the published format,
       and the same shape you would have written by hand.</p>
     </div>
@@ -2524,7 +2524,7 @@ columns: [
       <code>gridLines</code> chooses which rules are drawn between cells. <code>'horizontal'</code>
       is the default and is what the grid has always drawn; vertical rules between body cells are
       additive, so the default is unchanged and nothing moves on upgrade. <code>'rows'</code> and
-      <code>'columns'</code> are accepted as aliases. Only the rules between data are affected — the
+      <code>'columns'</code> are accepted as aliases. Only the rules between data are affected: the
       header underline and the seams beside pinned columns are structure rather than decoration, and
       removing them would make the pinned regions look detached.
     </p>
@@ -2539,7 +2539,7 @@ columns: [
     <h2 id="cards">Cards, lists and feeds</h2>
     <p class="lead-in">
       <code>rowTemplate</code> draws each row with a layout of your own instead of dividing it into
-      columns. A card list, a feed, a search-result list, a message list — any presentation where a
+      columns. A card list, a feed, a search-result list, a message list: any presentation where a
       record is a small piece of layout rather than a line of cells.
     </p>
@@ -2559,28 +2559,28 @@ columns: [
       <p><strong>The template compiles; it does not call back.</strong> There is deliberately no
       "here is a container, build what you like for this row" hook. That shape is easy to offer and
       would be used to allocate DOM per row, and at that moment the virtualisation stops paying for
-      itself — quietly, and in a way nobody can attribute to a change. A row template is the same
+      itself: quietly, and in a way nobody can attribute to a change. A row template is the same
       declarative string a cell template is: parsed once, built into real DOM the first time an
       element is used, and afterwards updated by writing text into the few nodes the bindings own.
       Scrolling ten thousand records through a hundred pooled cards allocates nothing.</p>
       <p><strong>Everything underneath is unchanged.</strong> Sorting, filtering, grouping,
       selection, permissions, redaction, saved views, undo, export and the remote source all apply
-      exactly as they do to a table — only the drawing changes. That is the reason to build a card
+      exactly as they do to a table: only the drawing changes. That is the reason to build a card
       view on a grid rather than beside one.</p>
     </div>
     <p class="lead-in">
       <strong>A card is still a row.</strong> It carries the same row identity a table row does, so
       <code>row:clicked</code> and <code>row:dblclicked</code> fire with the same payload, clicking
-      selects, the context menu opens, and <code>rowReorder</code> works — with the card itself as
+      selects, the context menu opens, and <code>rowReorder</code> works, with the card itself as
       the drag handle, since there is no cell to put a grip in. None of that is a second
       implementation; it is the same code that serves a table.
     </p>
     <div class="why">
       <p><strong>It is announced as a list, not a grid.</strong> A card has no columns, so the
-      <code>grid</code> role — which promises columns, <code>gridcell</code> children and a
-      two-dimensional keyboard model — would misdescribe it completely. The layer is a
+      <code>grid</code> role, which promises columns, <code>gridcell</code> children and a
+      two-dimensional keyboard model: would misdescribe it completely. The layer is a
       <code>list</code>, each card a <code>listitem</code> carrying its position and the size of the
       whole set, and the column header is not drawn. <code>role</code> and <code>itemRole</code>
       override both, for a presentation that is really a <code>listbox</code>.</p>
@@ -2612,7 +2612,7 @@ columns: [
       filling a small tablet is not. The grid already watches its own element for size changes, so
       the same observer answers this.</p>
       <p><strong>The state a user built survives the switch.</strong> Rotating a phone must not lose
-      the sort, the filters, the selection or the scroll position, and it does not — it is one grid
+      the sort, the filters, the selection or the scroll position, and it does not, it is one grid
       throughout, and only the drawing changes. An open cell editor is closed, since the cell it
       belonged to stops existing.</p>
     </div>
@@ -2621,7 +2621,7 @@ columns: [
       <strong>Sorting and filtering need a home</strong> when there are no column headings to click,
       and the tool panel is it: set <code>toolPanel: true</code> and its rail stays available in card
       presentation with the columns and filter panels behind it. <strong>Export is unaffected</strong>
-      — the columns are still the data model, so a CSV or an Excel file from a collapsed grid holds
+     , the columns are still the data model, so a CSV or an Excel file from a collapsed grid holds
       every column, including ones the card does not show.
     </p>
@@ -2634,7 +2634,7 @@ columns: [
     <h3>Showing what the grid shows</h3>
     <p class="lead-in">
-      <code>{{cell.<em>column</em>}}</code> is the text the table puts in that cell — the column's
+      <code>{{cell.<em>column</em>}}</code> is the text the table puts in that cell, the column's
       own formatter, data type, number and date settings and lookup label, all of it.
       <code>{{data.<em>field</em>}}</code> is the raw value underneath.
     </p>
@@ -2643,10 +2643,10 @@ columns: [
       <table>
         <thead><tr><th>Binding</th><th>Reads</th></tr></thead>
         <tbody>
-          <tr><td class="sig">{{cell.value}}</td><td class="desc">£1,250.50 — the cell's rendered text</td></tr>
-          <tr><td class="sig">{{data.value}}</td><td class="desc">1250.5 — the stored number</td></tr>
-          <tr><td class="sig">{{cell.stage}}</td><td class="desc">Held — a lookup's label</td></tr>
-          <tr><td class="sig">{{data.stage}}</td><td class="desc">2 — the lookup's id</td></tr>
+          <tr><td class="sig">{{cell.value}}</td><td class="desc">£1,250.50, the cell's rendered text</td></tr>
+          <tr><td class="sig">{{data.value}}</td><td class="desc">1250.5, the stored number</td></tr>
+          <tr><td class="sig">{{cell.stage}}</td><td class="desc">Held, a lookup's label</td></tr>
+          <tr><td class="sig">{{data.stage}}</td><td class="desc">2, the lookup's id</td></tr>
         </tbody>
       </table>
     </div>
@@ -2654,7 +2654,7 @@ columns: [
     <p class="lead-in">
       Both are wanted, which is why both exist: a card showing a value to a person wants
       <code>cell</code>, and a template comparing or calculating wants <code>data</code>. A lookup is
-      the case that decides it — a card showing <code>2</code> where the table shows
+      the case that decides it, a card showing <code>2</code> where the table shows
       <code>Held</code> is not a formatting preference but a plain bug.
     </p>
@@ -2662,7 +2662,7 @@ columns: [
       <p><strong>A protected column cannot be read raw.</strong> Binding
       <code>{{data.password}}</code> on a secret or redacted column would print the value the column
       exists to hide, while the table beside it shows dots. Such a binding reads the masked text
-      instead and says once that it did — a card must not become the hole a redaction closes.</p>
+      instead and says once that it did, a card must not become the hole a redaction closes.</p>
     </div>
     <h3>Several cards on a line</h3>
@@ -2681,7 +2681,7 @@ rowTemplate: { template: CARD, maxCardWidth: 260 }    <span class="cmt">// as ma
     <p class="lead-in">
       <code>cardsPerRow</code> is a count, for a layout that must not reflow. <code>maxCardWidth</code>
       is a ceiling: the grid fits as many whole cards as it can without exceeding it, and they share
-      the remaining space rather than leaving a ragged margin — so 900px at a 200px ceiling is four
+      the remaining space rather than leaving a ragged margin, so 900px at a 200px ceiling is four
       cards of 225px, and the count changes with the container. <code>gap</code> sets the space
       between them. Where both are given, <code>cardsPerRow</code> wins, being an instruction rather
       than a preference.
@@ -2690,14 +2690,14 @@ rowTemplate: { template: CARD, maxCardWidth: 260 }    <span class="cmt">// as ma
     <div class="why">
       <p><strong>The scroll height counts lines, not records.</strong> Four records on a line means
       the content is a quarter as tall as the row model alone would make it, and a scrollbar sized
-      per record would be four times too long — the last several screens empty. The tiled layout
+      per record would be four times too long, the last several screens empty. The tiled layout
       works out its own window from the scroll position for the same reason: the window it would
       otherwise be handed counts one record per line and would leave the bottom of the screen bare.
       Pooling is unaffected; scrolling a tiled gallery reuses its elements exactly as a list does.</p>
     </div>
     <p class="lead-in">
-      Tiles are a fixed height, taken from <code>rowHeight</code> —
+      Tiles are a fixed height, taken from <code>rowHeight</code> ,
       <code>rowHeight: 'auto'</code> measures a rendered row and cannot describe a line holding
       several of different heights. Variable-height tiles flowing into the shortest column is a
       masonry layout, which is a different thing and is not offered.
@@ -2705,14 +2705,14 @@ rowTemplate: { template: CARD, maxCardWidth: 260 }    <span class="cmt">// as ma
     <p class="lead-in">
       Row heights work as they do everywhere else, including <code>rowHeight: 'auto'</code>, which
-      measures the rendered card — content-driven card heights need no extra configuration. The
+      measures the rendered card: content-driven card heights need no extra configuration. The
       columns are still declared and still hold the data: they are what sorting, filtering and
       export operate on, and what the bindings read.
     </p>
     <h2 id="row-form">Editing a row on a form</h2>
     <p class="lead-in">
-      Double-clicking a row opens it in a panel — a right-hand drawer or a centred dialog — with
+      Double-clicking a row opens it in a panel (a right-hand drawer or a centred dialog) with
       one control per field, a Save and a Cancel. It is the shape almost every application built on
       a grid ends up wanting, and until now the shape they had to build themselves.
     </p>
@@ -2729,7 +2729,7 @@ rowTemplate: { template: CARD, maxCardWidth: 260 }    <span class="cmt">// as ma
     <p class="lead-in">
       That is the whole of it for the common case: the form is the row, edited with the same
       editors, types, formats and lookups the cells use. Where the record has more to it than the
-      grid shows, give a <code>load</code> function — and then say which fields and in what order,
+      grid shows, give a <code>load</code> function, and then say which fields and in what order,
       because nothing in the grid knows the shape of something it has never seen.
     </p>
@@ -2750,21 +2750,21 @@ rowTemplate: { template: CARD, maxCardWidth: 260 }    <span class="cmt">// as ma
     <h3>Which editor a field gets</h3>
     <p class="lead-in">
-      Every editor is available on a form, including your own from the module registry — the form
+      Every editor is available on a form, including your own from the module registry, the form
       builds its controls through the same call a cell does, so a field gets the same editor, type,
       formatting and lookup its column would have given it. A field named after a column borrows
       that column outright and needs nothing further.
     </p>
     <p class="lead-in">
-      A field the grid has never seen — or one you want entered differently from its cell — says so
+      A field the grid has never seen (or one you want entered differently from its cell) says so
       on the field itself. <code>editor</code> names it, and <code>type</code>, <code>props</code>
       and <code>lookup</code> configure it exactly as they would on a column. Overriding the control
       does not change where the value goes: a field still writes back only if it maps to a column.
     </p>
     <div class="why">
-      <p><strong>A picker opens when it is asked to.</strong> A popup editor — a date, a dropdown, a
-      tree, a colour, a code panel — <em>is</em> its panel: in a cell it opens the moment the cell
+      <p><strong>A picker opens when it is asked to.</strong> A popup editor, a date, a dropdown, a
+      tree, a colour, a code panel: <em>is</em> its panel: in a cell it opens the moment the cell
       does, which is right, because the user has just asked to edit that one cell. A form builds
       every field at once, so on a form the field shows the current value on a control and the panel
       opens over it when clicked. Choosing puts the panel away again and updates the control.</p>
@@ -2780,7 +2780,7 @@ rowTemplate: { template: CARD, maxCardWidth: 260 }    <span class="cmt">// as ma
       <p><strong>And a load that never answers is a failure too.</strong> A promise that neither
       resolves nor rejects is what a dropped request looks like from the page; left alone it spins
       until the user gives up, which reads as an application that has hung rather than a request
-      that failed. After <code>timeout</code> milliseconds — two seconds unless you say otherwise —
+      that failed. After <code>timeout</code> milliseconds, two seconds unless you say otherwise ,
       the form stops waiting and shows the same message and retry as any other failure. Set
       <code>timeout: false</code> to wait indefinitely, which is right only where your own loader
       already has a limit and would rather report that one. A record that turns up after the form
@@ -2791,7 +2791,7 @@ rowTemplate: { template: CARD, maxCardWidth: 260 }    <span class="cmt">// as ma
     <p class="lead-in">
       The fields scroll and the heading and buttons do not, so Save stays reachable on a record with
       forty fields. If a validator refuses one of them, the form stays open, the field is marked, and
-      it is scrolled into view and focused — on a long form the offending field is otherwise nowhere
+      it is scrolled into view and focused: on a long form the offending field is otherwise nowhere
       near the button that was just pressed.
     </p>
@@ -2821,7 +2821,7 @@ rowTemplate: { template: CARD, maxCardWidth: 260 }    <span class="cmt">// as ma
     <div class="why">
       <p><strong>The form takes the double click.</strong> On an editable grid that gesture also
-      opens a cell editor, and the two cannot both own it — a form that quietly did nothing where a
+      opens a cell editor, and the two cannot both own it, a form that quietly did nothing where a
       cell happened to be editable would be worse than no form. So where <code>rowForm</code> is
       configured, double-clicking a row opens the form and the cell editor stays reachable by
       Enter or by typing into the cell. Set <code>trigger: false</code> to leave opening entirely to
@@ -2831,7 +2831,7 @@ rowTemplate: { template: CARD, maxCardWidth: 260 }    <span class="cmt">// as ma
     <h3>Putting the form in your own element</h3>
     <p class="lead-in">
       A drawer and a dialog both sit over the grid. Give <code>container</code> an element of your
-      own and the form is built there instead — a sidebar beside the grid, a panel below it, a
+      own and the form is built there instead, a sidebar beside the grid, a panel below it, a
       column in a layout you already have. It fills what it is given, so the size and position are
       yours.
     </p>
@@ -2847,7 +2847,7 @@ rowTemplate: { template: CARD, maxCardWidth: 260 }    <span class="cmt">// as ma
     <p class="lead-in">
       A selector is resolved when the form <em>opens</em>, not when the grid is configured, because
       a grid is routinely built before the layout around it exists. A container that cannot be found
-      falls back to opening over the grid — better a form in the wrong place than a double-click
+      falls back to opening over the grid: better a form in the wrong place than a double-click
       that appears to do nothing.
     </p>
@@ -2869,18 +2869,18 @@ rowTemplate: { template: CARD, maxCardWidth: 260 }    <span class="cmt">// as ma
     <p class="lead-in">
       The grid has always written optimistically without calling it that: an edit lands in the
       model and is painted before anything else happens. What <code>edit.commit</code> adds is
-      <em>durability</em> — whether the write reached your server, and what to put back when it
+      <em>durability</em>: whether the write reached your server, and what to put back when it
       did not.
     </p>
     <div class="why">
       <p><strong>Nothing changes unless you ask for it.</strong> With no <code>commit</code> hook
       the grid behaves exactly as before: the value is written, history is recorded,
       <code>cell:changed</code> fires, and there is no pending state to think about. Subscribe to
-      <code>cell:changed</code>, fire your request and ignore the result — that keeps working and
+      <code>cell:changed</code>, fire your request and ignore the result: that keeps working and
       costs nothing.</p>
     </div>
     <div class="example">
-      <p class="example__label">The usual case — the promise is the answer</p>
+      <p class="example__label">The usual case, the promise is the answer</p>
       <pre><code>edit: {
   enabled: true,
   commit: async ({ key, colId, value }) =&gt; {
@@ -2894,7 +2894,7 @@ rowTemplate: { template: CARD, maxCardWidth: 260 }    <span class="cmt">// as ma
     </div>
     <p class="lead-in">
       Resolving confirms the write; throwing rolls it back and fires <code>cell:reverted</code>
-      with your error message as <code>reason</code>. A synchronous hook works too — returning
+      with your error message as <code>reason</code>. A synchronous hook works too: returning
       normally confirms, throwing reverts.
     </p>
     <div class="example">
@@ -2918,7 +2918,7 @@ socket.onmessage = (m) =&gt; {
       promise to resolve. <code>confirm: 'manual'</code> says so explicitly. The grid does not infer
       it from what <code>commit</code> returns, because then a synchronous hook that happens to
       return nothing would leave every cell pending for ever with nothing in your code that looks
-      wrong. If a write does stay pending, you get a console warning naming the cell — tune the
+      wrong. If a write does stay pending, you get a console warning naming the cell: tune the
       threshold with <code>pendingTimeout</code>.</p>
     </div>
@@ -2940,7 +2940,7 @@ socket.onmessage = (m) =&gt; {
       the part that is easy to get wrong by hand. Suppose a cell holding <code>1</code> is edited to
       <code>2</code>, then to <code>3</code>, then to <code>4</code>, all before any answer comes
       back. If the second write fails, restoring “the value before it” would put back
-      <code>2</code> — a value the server never held, and one the user has since replaced twice.
+      <code>2</code>, a value the server never held, and one the user has since replaced twice.
       So each cell remembers the newest value a confirmation has actually vouched for, and a write
       that a later edit has superseded reports its failure without writing anything back. You will
       see <code>cell:reverted</code> with <code>applied: false</code> for those.</p>
@@ -2951,8 +2951,8 @@ socket.onmessage = (m) =&gt; {
     <div class="why">
       <p><strong>Two behaviours worth knowing.</strong> An unconfirmed edit goes through the normal
       pipeline, so if it changes a sorted or filtered column the row moves immediately and moves
-      back if the write fails. And undo of an in-flight edit issues a <em>compensating write</em> —
-      a fresh write back to the previous value, itself tracked — rather than pretending to cancel a
+      back if the write fails. And undo of an in-flight edit issues a <em>compensating write</em> ,
+      a fresh write back to the previous value, itself tracked: rather than pretending to cancel a
       request that has already gone out.</p>
     </div>
@@ -2987,28 +2987,28 @@ grid.edit.status('r1', 'cap');    <span class="cmt">// 'pending' | null</span></
     </div>
     <p class="lead-in">
       <strong>Parent-reference</strong> is what a join or a document store produces. Every node is
-      a real row. A row whose parent is not in the data — filtered away, not loaded, or simply
-      wrong — is an orphan: it goes to the root by default, or into a named bucket. It is never
+      a real row. A row whose parent is not in the data (filtered away, not loaded, or simply
+      wrong) is an orphan: it goes to the root by default, or into a named bucket. It is never
       dropped, because hiding a record over a bad reference loses data the user can see in a flat
       view.
     </p>
     <p class="lead-in">
       <strong>Path-based</strong> rows describe their own place, so intermediate levels may have no
-      row at all — <code>EMEA/UK/Colchester</code> with no <code>EMEA/UK</code> row still needs a
+      row at all: <code>EMEA/UK/Colchester</code> with no <code>EMEA/UK</code> row still needs a
       <code>UK</code> node to sit under. Those are synthesised, and render as group rows: a heading
       over the rows beneath it with no record of its own. A real row arriving later for a level
       already synthesised fills that node rather than appearing beside it.
     </p>
     <p class="lead-in">
       A parent cycle is not a hierarchy and cannot be walked. It is reported once and cut, with the
-      rows shown at the root — wrong place beats vanished.
+      rows shown at the root: wrong place beats vanished.
     </p>
     <p class="lead-in">
       The grid generates a <strong>tree column</strong> to carry the expander and the indent, on the
       same terms as the auto-group, selection and detail columns: pinned to the start, and absent
       from <code>columns.visible()</code>, saved views, exports and the tool panel. Its text comes
       from <code>tree.label</code>; without one it falls back to your first visible column, which
-      then appears twice until you hide it — the grid does not remove a column you did not ask it
+      then appears twice until you hide it, the grid does not remove a column you did not ask it
       to remove.
     </p>
     <h3 id="tree-lazy">Loading a branch on demand</h3>
@@ -3022,7 +3022,7 @@ grid.edit.status('r1', 'cap');    <span class="cmt">// 'pending' | null</span></
     </div>
     <p class="lead-in">
       <code>hasChildren</code> lets a row declare children it does not hold, so the expander is
-      there before anything is fetched — without it there is nothing to click and the branch can
+      there before anything is fetched: without it there is nothing to click and the branch can
       never load. Such a node reads as <em>closed</em> even though tree nodes are otherwise expanded
       by default, because an open branch with nothing under it leaves no gesture to load it.
     </p>
@@ -3046,14 +3046,14 @@ grid.edit.status('r1', 'cap');    <span class="cmt">// 'pending' | null</span></
     <h2 id="master-detail">Master-detail</h2>
     <p class="lead-in">
-      A master row expands to reveal a detail region — by default a nested grid over whatever
+      A master row expands to reveal a detail region: by default a nested grid over whatever
       <code>detail.rows(row)</code> returns, which may be a promise. The grid adds an expander
       column while the feature is on, on the same terms as the auto-group and selection columns:
       pinned to the start, and absent from <code>columns.visible()</code>, saved views, exports and
       the tool panel.
     </p>
     <div class="example">
-      <p class="example__label">Inline — a detail row beneath its master</p>
+      <p class="example__label">Inline, a detail row beneath its master</p>
       <pre><code>detail: {
   rows: (row) =&gt; api.lines(row.data.id),   <span class="cmt">// array or promise</span>
   config: { columns: [{ field: 'port' }, { field: 'vlan' }] },
@@ -3074,7 +3074,7 @@ grid.detail.closeAll();</code></pre>
     <h3 id="detail-target">A detail pane instead of a detail row</h3>
     <div class="example">
-      <p class="example__label">Targeted — the list-and-pane layout</p>
+      <p class="example__label">Targeted, the list-and-pane layout</p>
       <pre><code>detail: {
   target: '#detail-pane',                 <span class="cmt">// a selector or an element</span>
   rows: (row) =&gt; api.lines(row.data.id),
@@ -3097,12 +3097,12 @@ grid.detail.placement();                  <span class="cmt">// 'inline' | 'targe
     </p>
     <p class="lead-in">
       A <code>target</code> selector that matches no element is reported once and leaves the
-      details unshown — silence there is indistinguishable from a detail that fails to open, and
+      details unshown: silence there is indistinguishable from a detail that fails to open, and
       the cause is not visible from the grid.
     </p>
     <p class="lead-in">
       <strong>The control changes with the placement, because the gesture does.</strong> Inline it
-      is a chevron that turns down when the row expands, carrying <code>aria-expanded</code> — the
+      is a chevron that turns down when the row expands, carrying <code>aria-expanded</code>: the
       ordinary disclosure pattern. Targeted, nothing expands: the row is being chosen and its
       detail appears elsewhere, so the control becomes the &ldquo;opens elsewhere&rdquo; glyph and
       a toggle (<code>aria-pressed</code>) rather than a disclosure. A chevron there would promise
@@ -3113,7 +3113,7 @@ grid.detail.placement();                  <span class="cmt">// 'inline' | 'targe
     <h3 id="detail-editing">An editable detail</h3>
     <p class="lead-in">
-      The detail is a whole grid, so it edits like one — put <code>edit</code> in
+      The detail is a whole grid, so it edits like one: put <code>edit</code> in
       <code>detail.config</code> and its cells are editable. The rows it shows are usually a
       sub-array of the master's own record, so an edit there changes the master's data directly;
       there is nothing to copy back.
@@ -3129,16 +3129,16 @@ grid.detail.placement();                  <span class="cmt">// 'inline' | 'targe
 }
 grid.on('detail:cell:changed', (e) =&gt; {
-  e.masterKey;   <span class="cmt">// 'C1'  — the row the detail belongs to</span>
-  e.path;        <span class="cmt">// 'ports.1.vlan' — where it lands on the master's record</span>
+  e.masterKey;   <span class="cmt">// 'C1' , the row the detail belongs to</span>
+  e.path;        <span class="cmt">// 'ports.1.vlan': where it lands on the master's record</span>
   e.value;       <span class="cmt">// 999</span>
   e.oldValue;    <span class="cmt">// 101</span>
 });</code></pre>
     </div>
     <p class="lead-in">
       A nested grid is created by the grid, not by you, so its own events would otherwise be out of
-      reach. The edit lifecycle — <code>detail:edit:started</code>,
-      <code>detail:edit:stopped</code>, <code>detail:cell:changed</code> — is re-emitted on the
+      reach. The edit lifecycle (<code>detail:edit:started</code>,
+      <code>detail:edit:stopped</code>, <code>detail:cell:changed</code>) is re-emitted on the
       master, tagged with the master it came from. You never have to hold the nested grid to hear
       about an edit inside it.
     </p>
@@ -3147,7 +3147,7 @@ grid.on('detail:cell:changed', (e) =&gt; {
       a host can persist a detail edit against the master and never think about the nested grid at
       all. It is worked out by identity: <code>rows(row)</code> usually returns an array that is
       already a property of the record, and that property is the prefix. A detail fetched from a
-      server is not part of the master's record, so its <code>path</code> is <code>null</code> —
+      server is not part of the master's record, so its <code>path</code> is <code>null</code> ,
       set <code>detail.path</code> to name it yourself when you want one anyway.
     </p>
     <p class="lead-in">
@@ -3173,33 +3173,33 @@ grid.on('detail:cell:changed', (e) =&gt; {
     <h2 id="selection-guide">Selection and ranges</h2>
     <p class="lead-in">
-      Row selection and cell ranges are separate answers to separate questions —
+      Row selection and cell ranges are separate answers to separate questions ,
       <em>which records</em> versus <em>which values</em>. Dragging across cells does not tick row
       checkboxes, and selecting rows does not build a range.
     </p>
     <div class="note">
       <p><strong>Cell ranges are on by default; row selection is not.</strong> Set
-      <code>selection: 'single'</code> or <code>'multiple'</code> to turn rows on — until you do,
+      <code>selection: 'single'</code> or <code>'multiple'</code> to turn rows on: until you do,
       <code>selection.set()</code> accepts the call and <code>keys()</code> comes back empty.</p>
     </div>
     <div class="example">
       <p class="example__label">Both</p>
       <pre><code>selection: 'multiple'                  <span class="cmt">// rows are off until you ask</span>
-<span class="cmt">// Rows — which records</span>
+<span class="cmt">// Rows, which records</span>
 grid.selection.set(['r1', 'r2']);
 grid.selection.keys();                 <span class="cmt">// the selected row keys</span>
 grid.selection.rows();                 <span class="cmt">// the row wrappers</span>
 grid.selection.all();                  <span class="cmt">// select everything that passes the filter</span>
 grid.selection.clear();
-<span class="cmt">// Cells — which values</span>
+<span class="cmt">// Cells, which values</span>
 grid.selection.setRange({ startRow: 0, endRow: 9, columns: ['cap', 'margin'] });
 grid.selection.cells();                <span class="cmt">// [{ key, colId }, …]</span>
 grid.selection.summary();              <span class="cmt">// count, sum, min, max, avg over the range</span>
 grid.selection.clearRange();
-<span class="cmt">// Several blocks at once — ctrl-click, Ctrl+Shift+Arrow, or from the API</span>
+<span class="cmt">// Several blocks at once: ctrl-click, Ctrl+Shift+Arrow, or from the API</span>
 grid.selection.addRange({ startRow: 20, endRow: 29, columns: ['cap'] });
 grid.selection.extendRange(34, 'cap');  <span class="cmt">// grows the block just added</span></code></pre>
     </div>
@@ -3213,7 +3213,7 @@ grid.selection.extendRange(34, 'cap');  <span class="cmt">// grows the block jus
       pinned so it does not scroll away. <code>headerCheckbox: true</code> puts a select-all box in
       its heading, which shows three states: unchecked when nothing is selected, checked when
       everything is, and the native indeterminate mark when some are. Clicking it selects
-      everything when it is not already full, and clears when it is — including from the
+      everything when it is not already full, and clears when it is: including from the
       indeterminate state, where the intent is "select the rest".
     </p>
     <p class="lead-in">
@@ -3239,7 +3239,7 @@ grid.selection.extendRange(34, 'cap');  <span class="cmt">// grows the block jus
       <p><strong>What multiple ranges do and do not support.</strong> Painting, <code>cells()</code>
       and the status-bar summary all work over the union of the selected blocks. Copy is narrower,
       because tab-separated text is a rectangle: blocks stacked over the same columns, or joined
-      over the same rows, copy fine — a diagonal pair has no rectangular form, so
+      over the same rows, copy fine, a diagonal pair has no rectangular form, so
       <code>rangeText()</code> returns <code>''</code> and <code>clipboard:copy</code> reports
       <code>reason: 'discontiguous'</code> rather than emitting misaligned rows. Filling is
       narrower still: with more than one block selected there is no single source to extend, so the
@@ -3269,12 +3269,12 @@ selection: { ranges: false }       <span class="cmt">// rows only, no drag-selec
     <div class="why">
       <p><strong>Months step as months.</strong> 15 January to 15 February is thirty-one days, and
       continuing in days would land on 18 March and drift further every step. A month step holds
-      the date the user picked, and clamps where the month is short — 31 January plus a month is
+      the date the user picked, and clamps where the month is short: 31 January plus a month is
       28 February, not 3 March.</p>
       <p><strong>Month ends are their own case.</strong> <code>31 Jan, 28 Feb</code> is a month
       series whose second value has already been clamped, so the two share no day of month and the
       day-preserving rule cannot see it. Where every source value is the last day of its own month,
-      the fill stays on the month end: 31 March, 30 April, 31 May — and 29 February in a leap year.
+      the fill stays on the month end: 31 March, 30 April, 31 May, and 29 February in a leap year.
       Values that share a day of month keep the day-preserving answer, so <code>30 Apr, 30 Jun</code>
       still gives 30 August rather than the 31st.</p>
       <p><strong>One limit worth knowing.</strong> Filling upwards is not supported; the handle
@@ -3287,7 +3287,7 @@ selection: { ranges: false }       <span class="cmt">// rows only, no drag-selec
 }</code></pre>
     </div>
     <div class="why">
-      <p>A domain series — order codes, fiscal periods, seat numbers — is not something the grid
+      <p>A domain series (order codes, fiscal periods, seat numbers) is not something the grid
       can infer, so <code>selection.fill</code> takes precedence when you supply it. It must return
       one value per target row; anything else is ignored in favour of the built-in detection,
       rather than being partly applied.</p>
@@ -3296,7 +3296,7 @@ selection: { ranges: false }       <span class="cmt">// rows only, no drag-selec
     <h2 id="updates-guide">Holding live updates</h2>
     <p class="lead-in">
       A pause button for incoming data. Changes are held and merged while paused, applied when
-      play is pressed, and counted throughout — so the coalescing that makes a live grid fast is
+      play is pressed, and counted throughout, so the coalescing that makes a live grid fast is
       finally visible.
     </p>
     <div class="example">
@@ -3318,7 +3318,7 @@ grid.updates.log({ since: Date.now() - 60000 });   <span class="cmt">// what arr
       no invisible state to explain.</p>
       <p><strong>Merging continues while paused</strong>, so a long pause costs one entry per
       changed row rather than one per update. Forty updates to one row are one row of work when
-      play is pressed — and <code>coalesced</code> is the thirty-nine, which is the number nobody
+      play is pressed, and <code>coalesced</code> is the thirty-nine, which is the number nobody
       could see before.</p>
       <p><strong>Bounding the rows themselves is separate.</strong> The log bounds change
       <em>history</em>; a streaming source also needs to bound row <em>retention</em>, or a grid
@@ -3327,8 +3327,8 @@ grid.updates.log({ since: Date.now() - 60000 });   <span class="cmt">// what arr
       many it let go through <code>evicted</code> on the progress report.</p>
       <p><strong>The log keeps the raw sequence, not the merged one.</strong> Merging is right for
       applying a backlog quickly and wrong for looking at what happened, because the intermediate
-      states are exactly what a time scrubber would move between. It survives the flush —
-      <code>pending</code> is what is waiting, the log is what happened — and it is capped, so a
+      states are exactly what a time scrubber would move between. It survives the flush ,
+      <code>pending</code> is what is waiting, the log is what happened, and it is capped, so a
       grid paused over lunch holds the recent past and reports how much it dropped rather than
       taking the tab with it.</p>
     </div>
@@ -3355,29 +3355,29 @@ expect(grid.diagnostics.renders().dom.cellWrites - before).toBeLessThan(200);</c
       reachable from the public API. Exposing what a system already knows is usually a better first
       move than measuring something new.</p>
       <p><strong>Warnings are mostly collection, not detection.</strong> The grid has 160 places
-      that warn once per cause, each already carrying a stable de-duplication key — which is
+      that warn once per cause, each already carrying a stable de-duplication key, which is
       exactly the stable identifier a support conversation needs. They went to the console and
       nowhere else. The console interleaves with your own logging, does not survive a reload, and
       cannot be asked what it has already complained about. They are now kept as records too.</p>
       <p><strong>Every warning names values, not just a condition.</strong> "Something is slow" is a
       warning nobody can act on. Each carries the specific numbers, a stable id, and is dismissible
-      for the session but not permanently — a permanently dismissible warning is one nobody sees
+      for the session but not permanently, a permanently dismissible warning is one nobody sees
       again after the person who dismissed it leaves.</p>
       <p><strong>The checks are tested for silence as much as for detection.</strong> A clean grid
       must raise nothing. A checker that cries wolf is one developers learn to ignore, and then it
       is worth less than no checker at all. The accessibility checks found two false positives in
-      themselves during development — first comparing <code>aria-rowcount</code> against the row
+      themselves during development: first comparing <code>aria-rowcount</code> against the row
       count when ARIA counts header rows too, then counting header row *elements*, of which a
       single-level header has three because the header is built once per pinned region.</p>
       <p><strong>Instrumentation must not change what it measures.</strong> Counters are integers
       incremented where the work already happened. Render phases are four <code>performance.now()</code>
-      marks around existing sections. Timings are sampled — a bounded window of recent operations —
+      marks around existing sections. Timings are sampled, a bounded window of recent operations ,
       and every report names which of its figures are sampled, because a number whose provenance is
       unclear is worse than no number. Paint wait is the browser's and is deliberately not claimed.</p>
       <p><strong>Render causes are captured, not inferred.</strong> By the time a paint runs,
       several distinct causes have collapsed into the same dirty flags, so working backwards gives a
       plausible answer rather than a true one. The renderer records the structural reason when the
-      invalidation arrives; the semantic one — filter, sort, data — is only knowable from the event
+      invalidation arrives; the semantic one (filter, sort, data) is only knowable from the event
       that preceded it, so the DOM layer supplies that and the structural reason is the fallback.</p>
       <p><strong>Providers are wrapped where they are installed</strong>, not at each call site, so
       one added later is instrumented by construction. The wrapper returns exactly what the original
@@ -3396,7 +3396,7 @@ expect(grid.diagnostics.renders().dom.cellWrites - before).toBeLessThan(200);</c
       because it imports it. A devtools module that imported anything from core would put the whole grid inside a
       bundle whose entire promise is that deployments not using it pay nothing.</p>
       <p><strong>The support bundle carries no row data.</strong> Configuration, query state, timing,
-      warnings, provider statistics, version and environment — and nothing from your data. Stated as
+      warnings, provider statistics, version and environment, and nothing from your data. Stated as
       a guarantee because a bundle that had to be inspected for confidential values before sending
       is a bundle that never gets attached to the ticket.</p>
       <p><strong>It observes and never mutates.</strong> A configuration editor in a debug panel is
@@ -3422,13 +3422,13 @@ const providerFor = (id) =&gt; ({
       <p><strong>Presence carries intent, never values.</strong> This is the line that matters most.
       A peer's committed edit reaches the grid as data, through the channel you already use for
       data. Presence is throttled, lossy and ephemeral <em>by design</em>, so a value carried on it
-      is a value that can be dropped &mdash; and that is the class of bug that appears once a month
+      is a value that can be dropped, and that is the class of bug that appears once a month
       in production and cannot be reproduced on demand.</p>
       <p><strong>Positions are row keys, resolved against your view at render time.</strong> Peers
       sort and filter independently, so index 12 is a different record on every screen. Publishing
       an index would put a colleague's cursor on an unrelated row the moment either of you sorted.
-      The cost of this is real &mdash; the grid resolves a key to a position rather than reading one
-      &mdash; and it is the difference between the feature working and the feature lying.</p>
+      The cost of this is real, the grid resolves a key to a position rather than reading one
+     , and it is the difference between the feature working and the feature lying.</p>
       <p><strong>Idle is measured from when a message arrived, not from what it says.</strong>
       Clocks between clients disagree by seconds routinely and by minutes occasionally. Keying idle
       detection on the sender's timestamp means a peer with a fast clock never goes idle and one
@@ -3442,19 +3442,19 @@ const providerFor = (id) =&gt; ({
       roster filling in slowly.</p>
       <p><strong>A peer's cursor is dashed; your focus ring is solid.</strong> The distinction has to
       be in the kind of line, not only its colour. Colour alone fails for anyone who cannot separate
-      two hues and fails for everyone at a glance &mdash; and the palette originally contained the
+      two hues and fails for everyone at a glance, and the palette originally contained the
       exact value of <code>--lattice-focus-color</code>, so the first peer assigned drew a cursor
       identical to the local user's own selection. An active edit is solid and tinted, because an
       edit is not a cursor and those two must not be confused with each other either.</p>
       <p><strong>Nothing is inserted into the grid.</strong> Every treatment is an attribute and a
       custom property written onto a cell that already exists, drawn with an outline and a
       pseudo-element. That is what keeps presence from shifting layout, covering an in-cell chart or
-      swallowing a click &mdash; none of which survives an implementation that appends overlay
+      swallowing a click: none of which survives an implementation that appends overlay
       elements. The overlay layer is pointer-transparent and presence deliberately does not opt back
       in; only the roster does, because it is a control.</p>
       <p><strong>The roster is the part people use.</strong> More than the cursors, in practice. It
       carries the name as well as the colour, because colour alone is not a signal everyone can
-      read, and it reports peers whose rows are not in your view rather than omitting them &mdash;
+      read, and it reports peers whose rows are not in your view rather than omitting them ,
       an absent peer reads as a disconnection that has not happened.</p>
       <p><strong>A parked cursor does not fade.</strong> The label does, after a couple of seconds,
       because permanent labels over a dense grid are unreadable. The border stays, dims at idle, and
@@ -3504,12 +3504,12 @@ const providerFor = (id) =&gt; ({
       <p><strong>Stable row identity is a hard requirement, enforced rather than documented.</strong>
       A comment is keyed on row identity plus field. Row index changes under sort, filter and
       grouping, so a comment keyed on it reattaches to whichever row later occupies that position
-      &mdash; and a comment on the wrong row is worse than no comment at all. A grid with no
+     , and a comment on the wrong row is worse than no comment at all. A grid with no
       <code>rowKey</code> disables comments and names them in the same single warning as the other
       identity-dependent features.</p>
       <p><strong>Identity has to survive more than the session.</strong> Comments outlive the page
-      that wrote them, so a key that is stable only within one load &mdash; anything derived from
-      arrival order, for instance &mdash; is not enough. Reload the data in a different order and
+      that wrote them, so a key that is stable only within one load (anything derived from
+      arrival order, for instance) is not enough. Reload the data in a different order and
       every thread points somewhere else. If you have only used the grid client-side you may never
       have needed a durable identity before; you do now.</p>
       <p><strong>Writes are optimistic, and rejections are taken back.</strong> The author sees
@@ -3523,14 +3523,14 @@ const providerFor = (id) =&gt; ({
       console. Reject in the provider.</p>
       <p><strong>A body is user input that has round-tripped through your storage.</strong> That is
       the exact shape of a stored cross-site script, so the default path sets text and nothing else.
-      Turning on <code>markdown</code> buys emphasis, code and links &mdash; three constructs, built
+      Turning on <code>markdown</code> buys emphasis, code and links: three constructs, built
       as elements rather than parsed as markup, with any scheme other than <code>http</code>,
       <code>https</code> and <code>mailto</code> refused. A refused link still shows its label, so
       nothing the author wrote vanishes without trace.</p>
       <p><strong>The marker cannot move the cell's contents.</strong> It is a corner triangle drawn
       with a border on a pseudo-element, so it occupies no space in the layout: no shifted text, no
       rewrapped number, no displaced sparkline. That constraint is why it is a corner rather than a
-      badge &mdash; every other position in a cell is already spoken for. Only the corner opens a
+      badge: every other position in a cell is already spoken for. Only the corner opens a
       thread; a click elsewhere belongs to selection, and taking it would make commented cells
       behave unlike every other cell. The hit region is larger than the drawn mark, because at
       compact density the triangle is about seven pixels across.</p>
@@ -3538,7 +3538,7 @@ const providerFor = (id) =&gt; ({
       matches the cell. Without it, a note reading "this looks too high" sits beside a number it
       never described and the reader concludes the comment is wrong. Changing a value never deletes
       or invalidates a comment.</p>
-      <p><strong>Filtered-out comments are hidden, not lost — and the grid says so.</strong>
+      <p><strong>Filtered-out comments are hidden, not lost, and the grid says so.</strong>
       <code>hiddenUnresolved()</code> reports what is still outstanding on rows the filter is
       hiding, because a user who filters and sees no markers should not conclude there is nothing
       left to deal with. The status bar carries this: its <code>comments</code> panel reads
@@ -3549,11 +3549,11 @@ const providerFor = (id) =&gt; ({
         <pre><code>statusBar: { panels: ['rowCount', 'comments'] }</code></pre>
       </div>
       <p>The count returns zero rather than a number it cannot stand behind: it is only meaningful
-      once the index covers every row, so it stays at zero &mdash; and the panel stays silent &mdash;
+      once the index covers every row, so it stays at zero, and the panel stays silent ,
       until <code>loadAll()</code> has resolved.</p>
       <p><strong>The comments-only filter is refused rather than approximated.</strong> Restricting
       the grid to rows carrying comments needs the index to cover the whole row set, not just what
-      has been scrolled past &mdash; a partial answer would hide precisely the rows the user opened
+      has been scrolled past, a partial answer would hide precisely the rows the user opened
       it to find. Call <code>loadAll()</code> first; until <code>complete</code> is true,
       <code>filterToCommented()</code> returns false and does nothing.</p>
       <p><strong>Comments stay available while streaming</strong>, unlike header histograms: a
@@ -3561,7 +3561,7 @@ const providerFor = (id) =&gt; ({
       debounced viewport path. A thread whose row is evicted by a bounded window closes with a
       short explanation rather than hovering over a row that has gone.</p>
       <p><strong>Keyboard and screen reader.</strong> <kbd>Alt</kbd>+<kbd>M</kbd> opens the thread
-      on the focused cell &mdash; Alt because the grid binds nearly every unmodified key to
+      on the focused cell: Alt because the grid binds nearly every unmodified key to
       navigation and editing. The panel traps <kbd>Tab</kbd>, which it has to: the grid behind it is
       still there and still focusable, so without the trap a keyboard user would be moving through
       cells with a dialog open over them. Focus returns to the originating cell on close rather than
@@ -3571,7 +3571,7 @@ const providerFor = (id) =&gt; ({
       other than what it holds.</p>
       <p><strong>Not in this release:</strong> mentions, notifications, rich text, attachments,
       reactions, row-level and column-level comments, and export of comments. The grid opens no
-      transport of its own &mdash; if your application pushes updates, call <code>refresh()</code>
+      transport of its own: if your application pushes updates, call <code>refresh()</code>
       and the index reloads.</p>
     </div>
@@ -3592,11 +3592,11 @@ const providerFor = (id) =&gt; ({
       <p><strong>The column being filtered is not counted against its own filter.</strong> Every
       other active filter applies; that column's own conditions are pruned out of the tree before
       counting. This is the whole of faceted browsing and it is the part that is easy to get subtly
-      wrong &mdash; a self-filtered chart collapses to a single bar the moment you click one, and
+      wrong, a self-filtered chart collapses to a single bar the moment you click one, and
       there is then no way to see what you excluded or to widen the selection. Getting it wrong
       does not degrade the feature, it removes it.</p>
       <p><strong>Pruning is not symmetric across operators.</strong> An <code>and</code> group
-      narrows with each condition, so dropping one widens the result &mdash; the direction faceting
+      narrows with each condition, so dropping one widens the result, the direction faceting
       wants. An <code>or</code> group widens with each branch, so dropping one would show
       <em>fewer</em> rows than the user's actual filter. There is no partial answer that is correct,
       so a disjunction naming the column is dropped whole.</p>
@@ -3606,7 +3606,7 @@ const providerFor = (id) =&gt; ({
       because the thing you are pointing at would move as you pointed at it.</p>
       <p><strong>Each bar carries two readings.</strong> Its full height is the bucket's share of
       the unfiltered column; the solid fill inside is how much survives the current filters. Either
-      alone misleads &mdash; scaling to the filtered maximum draws a full-height chart out of three
+      alone misleads: scaling to the filtered maximum draws a full-height chart out of three
       surviving rows, and scaling everything down together flattens the whole chart into a few
       pixels the moment anyone filters anything.</p>
       <p><strong>The filters are ordinary filters.</strong> They go through the same
@@ -3623,7 +3623,7 @@ const providerFor = (id) =&gt; ({
       than a scan. The first column anyone points this at is a name or an id, and one hairline per
       customer looks like a rendering fault rather than a distribution. Above
       <code>cardinalityLimit</code> the chart is suppressed, or shows a top-N with an aggregated
-      remainder if you ask for <code>aboveLimit: 'topN'</code> &mdash; aggregated rather than
+      remainder if you ask for <code>aboveLimit: 'topN'</code>: aggregated rather than
       truncated, because silently dropping the tail would misrepresent the bars it did draw.</p>
       <p><strong>Nulls are never dropped.</strong> They land in a terminal bucket, always last, and
       the counts always sum to the row count. A column where nine thousand of ten thousand rows are
@@ -3633,8 +3633,8 @@ const providerFor = (id) =&gt; ({
       <p><strong>Live streams suppress the charts.</strong> Constantly shifting distributions are
       unreadable, recounting on every batch is wasteful, and a filter control whose buckets move
       under the pointer is actively hostile. Filters already made stay applied, because they are
-      ordinary filters. Pausing the stream brings the charts back &mdash; a paused stream is a still
-      one &mdash; unless you set <code>whilePaused: false</code>.</p>
+      ordinary filters. Pausing the stream brings the charts back, a paused stream is a still
+      one: unless you set <code>whilePaused: false</code>.</p>
       <p><strong>Counting runs off the main thread above <code>workerThreshold</code>.</strong>
       Distributions are the only work the grid moves to a Worker. Sorting, filtering and grouping
       run on the main thread; nothing waits on a histogram, which is what makes this one
@@ -3643,24 +3643,24 @@ const providerFor = (id) =&gt; ({
       detach the buffer the grid is still rendering from.</p>
       <p><strong>The Worker settings.</strong> <code>useWorker</code> and
       <code>workerThreshold</code> decide whether and when a distribution is offloaded. Two more
-      control how the Worker is built, and both are settled when it is constructed &mdash; changing
+      control how the Worker is built, and both are settled when it is constructed: changing
       either discards the running Worker so the next offload builds a new one.</p>
       <div class="table-wrap">
         <table>
           <thead><tr><th>Setting</th><th>What it does</th></tr></thead>
           <tbody>
-            <tr><td class="name"><code>workerUrl</code></td><td class="desc">Loads the Worker from a URL you host instead of a <code>blob:</code>. Required under a Content-Security-Policy that forbids <code>blob:</code> workers &mdash; without it the Worker cannot be constructed at all on such a page, and compute stays on the main thread.</td></tr>
+            <tr><td class="name"><code>workerUrl</code></td><td class="desc">Loads the Worker from a URL you host instead of a <code>blob:</code>. Required under a Content-Security-Policy that forbids <code>blob:</code> workers: without it the Worker cannot be constructed at all on such a page, and compute stays on the main thread.</td></tr>
             <tr><td class="name"><code>sharedMemory</code></td><td class="desc">Off by default. Passes columns to the Worker in a <code>SharedArrayBuffer</code> rather than copying them on every message, at the cost of retaining a shared copy of each column that crosses. Needs the page to be cross-origin isolated; where it is not, it falls back to copying and says so once.</td></tr>
           </tbody>
         </table>
       </div>
       <p><code>grid.diagnostics.renders().worker</code> reports what the Worker host is actually
-      doing &mdash; whether one was spawned, how many calls ran locally versus remotely, and the
+      doing: whether one was spawned, how many calls ran locally versus remotely, and the
       threshold, <code>sharedMemory</code> and <code>workerUrl</code> it was built with.</p>
       <p><strong>Server-side sources need a <code>provider</code>, and its absence is silent.</strong>
       A grid holding one page of data cannot compute a distribution over the whole set. Supply a
       function and it receives the column, the pruned filter state and the bucketing settings, and
-      returns counts. Without one the charts are simply absent &mdash; no error, because most
+      returns counts. Without one the charts are simply absent, no error, because most
       deployments will never supply one. Be clear-eyed about the load: results are cached against
       the filter state, but this is one query per column per filter change, and a grid with eight
       faceted columns asks eight questions every time a filter moves.</p>
@@ -3669,13 +3669,13 @@ const providerFor = (id) =&gt; ({
       toggles, <kbd>Shift</kbd> with arrows extends a range on ordered columns, <kbd>Escape</kbd>
       clears. Selected buckets carry an outline as well as a colour. Beyond per-bucket labels the
       chart carries a sentence describing the distribution's shape, because twenty bucket readings
-      do not add up to "most of the mass is at the low end" &mdash; and that shape is the entire
+      do not add up to "most of the mass is at the low end", and that shape is the entire
       value of the chart.</p>
     </div>
     <h2 id="timeline-guide">Time scrubber</h2>
     <p class="lead-in">
-      Move the grid back through recent data changes — what did this look like a minute ago,
+      Move the grid back through recent data changes: what did this look like a minute ago,
       before that number moved.
     </p>
     <div class="example">
@@ -3691,17 +3691,17 @@ grid.timeline.detach();</code></pre>
     </div>
     <div class="why">
       <p><strong>Attaching puts a control on the grid.</strong> A slider along the bottom with two
-      readings beside it — how long ago, and the clock time. Relative answers the question actually
+      readings beside it: how long ago, and the clock time. Relative answers the question actually
       being asked; absolute is what someone reads out to the person next to them. It moves the grid
       while the handle is dragged rather than on release, and it turns accent-coloured the moment
       you are off live, because a grid quietly showing stale data is the failure this control can
       cause. It removes itself on <code>detach()</code>.</p>
       <p><strong>It reads the data, not your actions.</strong> Undo history records what the
-      <em>user</em> did — sorts, filters, edits — which is rarely the question. This reads the
+      <em>user</em> did (sorts, filters, edits) which is rarely the question. This reads the
       change log: a bounded, timestamped, deliberately unmerged record of everything that arrived,
       so the intermediate states are all still there to move between.</p>
       <p><strong>Nothing is scrubbable before <code>attach()</code>.</strong> What a value used to
-      be is not recoverable after the fact — no other part of the grid remembers it — so recording
+      be is not recoverable after the fact (no other part of the grid remembers it) so recording
       has to be switched on before there is a past to move through. It is off by default because
       reading a row per key on every change is real cost on a hot feed, and paying it for a
       scrubber nobody opened would be the wrong default.</p>
@@ -3711,7 +3711,7 @@ grid.timeline.detach();</code></pre>
       <p><strong>Value changes reverse; row additions and removals do not.</strong> An add would
       need a removal and a remove would need re-insertion at its old position, and neither is
       recoverable from what the log holds. A window containing them scrubs over the value changes
-      and leaves the row set alone — stated plainly because the alternative is a scrubber that
+      and leaves the row set alone: stated plainly because the alternative is a scrubber that
       silently half-works.</p>
       <p><strong>What moved is marked.</strong> Seeking compares each affected row before and after
       and marks the cells whose value changed, in <code>--lattice-timeline-changed</code>. Without
@@ -3719,13 +3719,13 @@ grid.timeline.detach();</code></pre>
       number you are hunting for goes past unseen.</p>
       <p><strong>The mark is held, not flashed.</strong> It stays until the next seek clears it.
       Every other transient signal in the grid fades on a timer, and this one deliberately does not
-      — a scrub is someone hunting for what changed, and a highlight they can miss while reading the
+     , a scrub is someone hunting for what changed, and a highlight they can miss while reading the
       other end of the row helps nobody. <code>timeline:seeking</code> fires before any change is
       applied, so a five-step drag clears once and marks once rather than strobing per entry.</p>
       <p><strong>It compares column values, not raw fields.</strong> A computed column has no field
       of its own; diffing the source row would leave it silently unmarked while its number visibly
       moved. Reading through the column instead costs a little more and marks what the viewer can
-      actually see change — which is the only definition of "changed" that matters here.</p>
+      actually see change, which is the only definition of "changed" that matters here.</p>
       <p><strong>The window is bounded by rows, not only by changes.</strong> A cap on entries
       alone does not bound memory, because an entry is not a fixed size: one carrying a single
       changed cell and one carrying a fifty-thousand-row batch both count as one. So the log holds
@@ -3734,7 +3734,7 @@ grid.timeline.detach();</code></pre>
       here than it looks: the log is what keeps superseded row objects alive after the source has
       swapped in their replacements, so on a feed delivering five thousand rows a batch an
       entry-only cap retains twenty million of them. The one exception is a single change larger
-      than the whole cap, which is kept — emptying the log would be worse than being briefly over,
+      than the whole cap, which is kept: emptying the log would be worse than being briefly over,
       and it would drop the newest change rather than the oldest. Watch <code>held</code> against
       <code>heldLimit</code> in <code>grid.updates.stats()</code>; <code>rows</code> is a lifetime
       total and says nothing about memory.</p>
@@ -3766,14 +3766,14 @@ grid.presentation.stop();                   <span class="cmt">// or Escape</span
         <thead><tr><th>Keys</th><th>Does</th></tr></thead>
         <tbody>
           <tr><td class="sig">Escape</td><td class="desc">Leave, restoring the grid exactly as it was.</td></tr>
-          <tr><td class="sig">Ctrl/Cmd + = / -</td><td class="desc">Enlarge or reduce live — a laptop on a call and a projector at the back of a room are different problems.</td></tr>
+          <tr><td class="sig">Ctrl/Cmd + = / -</td><td class="desc">Enlarge or reduce live, a laptop on a call and a projector at the back of a room are different problems.</td></tr>
           <tr><td class="sig">Ctrl/Cmd + 0</td><td class="desc">Back to the default enlargement.</td></tr>
         </tbody>
       </table>
     </div>
     <div class="why">
       <p><strong>The scale multiplies your density, it does not replace it.</strong> A grid built at
-      <code>spacious</code> presented at 1.5x is still recognisably that grid, half as big again —
+      <code>spacious</code> presented at 1.5x is still recognisably that grid, half as big again ,
       which is what makes a presentation look like the product rather than like a different one.
       Virtualisation follows the enlargement, so rows are positioned at the size they are drawn.</p>
       <p><strong>Full-screen is the maximiser, not a second implementation.</strong> A grid the user
@@ -3782,7 +3782,7 @@ grid.presentation.stop();                   <span class="cmt">// or Escape</span
       element the host had already hidden is not revealed on exit.</p>
       <p><strong>Events</strong> are <code>presentation:started</code>,
       <code>presentation:ended</code>, <code>presentation:scale</code> and
-      <code>presentation:changed</code> — colon-separated like every other grid event rather than
+      <code>presentation:changed</code>: colon-separated like every other grid event rather than
       the camelCase the original brief used, so a host subscribing to them does not have to
       remember which family a name belongs to.</p>
     </div>
@@ -3791,7 +3791,7 @@ grid.presentation.stop();                   <span class="cmt">// or Escape</span
       <pre><code>grid.presentation.start({ views: ['escalations', 'at-risk', 'margin-watch'] });
 grid.presentation.step(1);          <span class="cmt">// or an arrow key, space, Page Down</span>
 grid.presentation.goTo(0);          <span class="cmt">// or Home / End</span>
-grid.presentation.reset();          <span class="cmt">// or R — back to the view as saved</span></code></pre>
+grid.presentation.reset();          <span class="cmt">// or R: back to the view as saved</span></code></pre>
     </div>
     <div class="table-wrap">
       <table>
@@ -3810,14 +3810,14 @@ grid.presentation.reset();          <span class="cmt">// or R — back to the vi
       ordinary <code>views.apply</code>, as a single undo entry. Nothing about presenting changes
       what a view means.</p>
       <p><strong>The stepping keys only bind when there is a sequence</strong>, and never while
-      something is being typed into. Without a deck those keys belong to the grid — a presenter
-      with no slides still expects Page Down to scroll — and a quick filter answering a question
+      something is being typed into. Without a deck those keys belong to the grid, a presenter
+      with no slides still expects Page Down to scroll, and a quick filter answering a question
       from the room must not advance the deck on the space bar.</p>
       <p><strong>Stepping past either end sits there.</strong> It does not wrap: a presenter who
       sees the first slide again thinks the deck has restarted.</p>
       <p><strong>Transitions are a cross-fade, not continuous row motion.</strong> Rows are pooled
       and virtualised, so an element holding a row before a view change may hold a different row
-      after it — only rows visible in <em>both</em> states could be animated between positions, and
+      after it: only rows visible in <em>both</em> states could be animated between positions, and
       half a movement draws the eye to whichever rows happened to survive rather than to the change
       itself. <code>prefers-reduced-motion</code> removes it; a projected fade is far larger than
       one on a laptop, so someone who asked for less motion meant it.</p>
@@ -3842,7 +3842,7 @@ grid.presentation.start({ chrome: ['statusBar'] });</code></pre>
       the other rows are gone. It is opacity alone, so a dimmed sparkline keeps its colours instead
       of flattening to grey.</p>
       <p><strong>A spotlight does not survive a view change.</strong> It belongs to the point being
-      made, not to the deck — carried forward, it leaves the audience looking at a lit row that no
+      made, not to the deck: carried forward, it leaves the audience looking at a lit row that no
       longer means anything.</p>
       <p><strong>Redaction travels in views and undo.</strong> It is part of grid state, so a saved
       view carries its own masking and a view that redacts salary redacts it every time it is
@@ -3869,14 +3869,14 @@ grid.on('presentation:captured', (e) =&gt; {
       <p><strong>Mounting the bar elsewhere needs the grid's class.</strong> Every rule that styles
       the prompt bar is scoped under <code>.lattice</code>, and every colour token is declared
       there, so a bar mounted into your own chrome through <code>ai.element</code> arrives
-      unstyled. Add <code>class="lattice"</code> to the container — and the same
-      <code>data-theme</code> the grid carries, if you have set one — and it picks up the theme.</p>
+      unstyled. Add <code>class="lattice"</code> to the container, and the same
+      <code>data-theme</code> the grid carries, if you have set one, and it picks up the theme.</p>
     </div>
     <div class="why">
       <p><strong>It photographs the browser's own rendering.</strong> The grid is cloned, every
       computed style is inlined onto the clone, and the result is wrapped in an SVG
-      <code>foreignObject</code> and drawn to a canvas — so the picture is what the browser drew,
+      <code>foreignObject</code> and drawn to a canvas, so the picture is what the browser drew,
       not a second renderer's guess at it. That matters here more than usual: every decoration,
       sparkline and pill the cell layer produces comes out right without being reimplemented.</p>
       <p><strong>Virtualisation makes it cheap.</strong> Only the rows on screen exist in the DOM,
@@ -3884,7 +3884,7 @@ grid.on('presentation:captured', (e) =&gt; {
       A full-screen capture at <code>scale: 2</code> takes around a second.</p>
       <p><strong>Cross-origin images are refused before the work starts.</strong> They taint the
       canvas, and a tainted canvas fails at the very last step with a <code>SecurityError</code>
-      that names nothing — so the check runs first and the error names the offending URL. Serve the
+      that names nothing, so the check runs first and the error names the offending URL. Serve the
       image same-origin, inline it as a <code>data:</code> URL, or hide the column.</p>
       <p><strong>Two further limits</strong>, both inherent to the technique: web fonts need
       embedding to appear (Lattice's default <code>system-ui</code> stack is unaffected), and CSS
@@ -3909,7 +3909,7 @@ grid.annotate.use(null);                     <span class="cmt">// hand the grid
       content coordinates and redrawn with the scroll offset subtracted, so a circle drawn round a
       cell travels with that cell rather than hanging over whatever scrolled underneath it.</p>
       <p><strong>They are transient.</strong> Marks annotate a moment, so they are cleared when the
-      presentation ends. A capture taken while they are on screen includes them — the canvas bitmap
+      presentation ends. A capture taken while they are on screen includes them, the canvas bitmap
       is carried into the still deliberately, because <code>cloneNode</code> copies a canvas element
       and not one pixel of what was drawn on it.</p>
       <p><strong>No tool shortcuts are bound.</strong> The keys a presenter would want are already
@@ -3920,7 +3920,7 @@ grid.annotate.use(null);                     <span class="cmt">// hand the grid
     <h2 id="accessibility-guide">Accessibility</h2>
     <p class="lead-in">
       The grid is built to WCAG 2.2 level AA. What follows is what it does, what it does not do yet,
-      and the keyboard map in full &mdash; stated plainly, because a conformance claim that overstates
+      and the keyboard map in full: stated plainly, because a conformance claim that overstates
       is worth less than one that admits its edges.
     </p>
@@ -3986,37 +3986,37 @@ grid.annotate.use(null);                     <span class="cmt">// hand the grid
     <h3>Colour and contrast</h3>
     <p>No information is carried by hue alone. The <code>high-contrast</code> theme runs text at 21:1
       and borders at 6.1:1. In Windows High Contrast Mode the grid translates its state into borders
-      and system colours rather than fighting the palette &mdash; see
+      and system colours rather than fighting the palette: see
       <a href="#theming">theming</a> for what that means in detail.</p>
     <h3>How this is checked</h3>
     <p>The grid carries its own accessibility rules, and they run on every build against each
-      configuration that differs structurally &mdash; flat, grouped, tree, pinned, editing, paginated
-      and with a tool panel &mdash; rather than against one sample grid. The same rules are available
+      configuration that differs structurally: flat, grouped, tree, pinned, editing, paginated
+      and with a tool panel: rather than against one sample grid. The same rules are available
       live from the devtools panel, where they can also read colour and measure targets.</p>
     <p>Be clear about what that proves. These are our own rules covering what a data grid gets wrong,
       not a general-purpose engine, and automated checking of any kind catches a minority of real
-      problems. They are a regression net &mdash; they stop a fix being undone silently &mdash; and
+      problems. They are a regression net (they stop a fix being undone silently) and
       not evidence of conformance.</p>
     <h3>Bigger targets for touch</h3>
     <p class="lead-in">
       The grid meets the minimum target size on its own. That minimum is a conformance floor, not a
-      comfortable size for a finger &mdash; both mobile platforms recommend nearer 44 pixels.
+      comfortable size for a finger: both mobile platforms recommend nearer 44 pixels.
     </p>
     <div class="example">
       <pre><code>targetSize: 'large'</code></pre>
     </div>
     <p>This raises the hit areas and leaves the type where it is, which is the distinction that
       matters: a touch user wants a larger target, and a low-vision user wants larger text. Density
-      is the control for the second, and the two combine &mdash; a compact grid with large targets is
+      is the control for the second, and the two combine, a compact grid with large targets is
       a reasonable thing to want on a tablet.</p>
     <p>It applies by itself under a coarse pointer, since the person holding one is both who the
       criterion is for and the least likely to go looking for a setting. Pass
       <code>targetSize: 'default'</code> to opt out of that.</p>
     <div class="why">
       <p>Density alone does not do this. It scales the header, the rows and the type, and leaves the
-      affordances inside them exactly as they were &mdash; measured at every preset, the menu button
+      affordances inside them exactly as they were: measured at every preset, the menu button
       stays 24 pixels, the filter 16 and the resize grip 10. A spacious grid has the room going spare
       and controls no larger than a compact one, which is the gap this fills.</p>
     </div>
@@ -4026,7 +4026,7 @@ grid.annotate.use(null);                     <span class="cmt">// hand the grid
     <ul>
       <li><strong>Two-dimensional scrolling.</strong> A grid scrolls horizontally at narrow widths.
         WCAG 1.4.10 Reflow explicitly permits this for data tables, so it is conforming rather than a
-        gap &mdash; but it is worth knowing before you meet it.</li>
+        gap, but it is worth knowing before you meet it.</li>
       <li><strong>Pinned columns do not release at narrow widths.</strong> At around 320 pixels, two
         pinned columns of ordinary width can leave under 60 pixels for the scrolling middle. The grid
         stays operable and nothing is lost, but a layout that pins columns is worth reviewing if you
@@ -4034,7 +4034,7 @@ grid.annotate.use(null);                     <span class="cmt">// hand the grid
       <li><strong>The filter icon is a small target, deliberately.</strong> It is 16&nbsp;&times;&nbsp;16,
         below the 24-pixel minimum of WCAG 2.5.8, and conforms under that criterion's
         <em>equivalent</em> allowance: filtering is also a column-menu item, and the menu button
-        meets the size on its own. Worth knowing if you are pointing at it on a touch screen &mdash;
+        meets the size on its own. Worth knowing if you are pointing at it on a touch screen ,
         the menu is the larger route to the same thing.</li>
     </ul>
@@ -4067,9 +4067,9 @@ grid.set('density', 'compact');     <span class="cmt">// live</span></code></pre
       <p><strong>Virtualisation follows the token, not a separate number.</strong> Row positions
       are computed from the resolved <code>--lattice-row-height</code>, so a host that overrides
       that token by hand gets the virtualisation to agree. An explicit <code>rowHeight</code> in
-      config outranks both — a host that names a number means it.</p>
+      config outranks both, a host that names a number means it.</p>
       <p><strong>Height alone will not reproduce a modern app listing.</strong> Those designs pair
-      generous rows with two-line cells — a bold title over a grey sub-label — and an avatar or
+      generous rows with two-line cells (a bold title over a grey sub-label) and an avatar or
       thumbnail. <code>spacious</code> gives the room, an <a href="#image-guide">image column</a>
       gives the picture, and <a href="#twoline-guide">twoline</a> gives the second line.</p>
     </div>
@@ -4102,7 +4102,7 @@ grid.set('density', 'compact');     <span class="cmt">// live</span></code></pre
       including a <code>data:</code> URL claiming to be anything other than an image. Relative URLs
       pass, since they cannot name a scheme. A grid drawing URLs that arrived in a data feed is
       exactly where a bad one gets through. Note this differs from the <code>link</code> renderer,
-      which refuses <code>data:</code> outright — correct for an anchor, wrong for a picture.</p>
+      which refuses <code>data:</code> outright: correct for an anchor, wrong for a picture.</p>
       <p><strong>A missing or broken image never moves the column.</strong> The box is sized from
       the row height whether or not the picture loads, and a failed load leaves it empty rather
       than showing the browser's broken-image glyph, which is a different size in every engine.</p>
@@ -4149,7 +4149,7 @@ props: { secondary: 'user', format: (v) =&gt; v ? `User: ${v}` : '' }</code></pr
     <h2 id="redaction-guide">Redacting a column</h2>
     <p class="lead-in">
       For presenting and screen sharing: obscure the values in a column while everything that
-      makes the grid readable — the row count, the sort, the filters, the column layout — stays
+      makes the grid readable (the row count, the sort, the filters, the column layout) stays
       exactly as it was. Right-click a column heading and choose <strong>Redact column</strong>.
     </p>
     <div class="example">
@@ -4162,12 +4162,12 @@ grid.redaction.clear();          <span class="cmt">// when the call ends</span><
       <p><strong>This is not a security control, and the difference matters.</strong> The values
       are still in the model, still in the DOM, still on the clipboard and still in every export.
       Anyone looking at the page can read them from devtools, or by turning off a single CSS rule.
-      What redaction defeats is a camera and a screen recorder — which is the threat a presenter
+      What redaction defeats is a camera and a screen recorder, which is the threat a presenter
       actually has, and the only one it claims to answer. For a value that must never reach the
       browser, use <code>permissions</code> with <code>writeOnly</code>: there the value is not
       sent, so there is nothing to reveal.</p>
       <p><strong>Headings stay readable, totals do not.</strong> The column heading is left alone
-      deliberately — a redacted column still has to be identifiable, by the presenter who wants to
+      deliberately, a redacted column still has to be identifiable, by the presenter who wants to
       turn it back on and by the audience who need to know what they are not being shown. The
       pinned totals row <em>is</em> redacted, because the sum of a column is not a hint at its
       values: filter to one row and the total is the value.</p>
@@ -4181,7 +4181,7 @@ grid.redaction.clear();          <span class="cmt">// when the call ends</span><
     <h2 id="clipboard">Clipboard</h2>
     <p class="lead-in">
       Copy produces the tab-separated form Excel, Numbers and Sheets all read, so a range pastes as
-      cells rather than as one lump of text. Values go through each column's clipboard hook — a
+      cells rather than as one lump of text. Values go through each column's clipboard hook: a
       lookup copies its label, a date copies an unambiguous form.
     </p>
     <div class="example">
@@ -4203,7 +4203,7 @@ grid.edit.pasteInto(text);                        <span class="cmt">// Excel's t
     <p class="lead-in">
       Press <kbd>?</kbd> in the grid to see this list in the product. The overlay is generated from
       the same bindings the grid implements, so it cannot drift from them, and it shows
-      <kbd>Cmd</kbd> rather than <kbd>Ctrl</kbd> on a Mac — the grid reads either, so that is what
+      <kbd>Cmd</kbd> rather than <kbd>Ctrl</kbd> on a Mac, the grid reads either, so that is what
       you will actually press. <kbd>Escape</kbd> closes it and focus returns where it was. Set
       <code>shortcuts: false</code> if you want <kbd>?</kbd> for something else.
     </p>
@@ -4225,7 +4225,7 @@ grid.edit.pasteInto(text);                        <span class="cmt">// Excel's t
       </table>
     </div>
     <div class="why">
-      <p>None of these fire while you are typing into an input — a filter box, an open editor, the
+      <p>None of these fire while you are typing into an input, a filter box, an open editor, the
       view-name field. The grid checks where the keystroke came from before claiming it, which
       sounds obvious and is the sort of thing that is usually wrong.</p>
     </div>
@@ -4251,17 +4251,17 @@ grid.edit.pasteInto(text);                        <span class="cmt">// Excel's t
       who has built a filter has already learned this, and two vocabularies for one idea is how a
       product ends up explaining itself twice.</p>
       <p><strong>First match wins, by default.</strong> "Red if overdue, amber if due this week"
-      reads top to bottom and stops — the spreadsheet convention, and the one people expect.
+      reads top to bottom and stops, the spreadsheet convention, and the one people expect.
       <code>stopIfTrue: false</code> lets rules combine: weight from one, colour from another.</p>
       <p><strong>A blank cell satisfies no comparison.</strong> <code>Number(null)</code> is zero, so
       a naive implementation sweeps every empty cell into "less than 100" and formats half a column
       that has no data in it.</p>
-      <p><strong>Text still compares numerically.</strong> A rules panel produces strings — the box
-      the user typed into yields <code>"100"</code>, not <code>100</code> — and comparing those as
+      <p><strong>Text still compares numerically.</strong> A rules panel produces strings, the box
+      the user typed into yields <code>"100"</code>, not <code>100</code>, and comparing those as
       text puts <code>"9"</code> above <code>"100"</code>.</p>
       <p><strong>A scale's bounds are given, not derived.</strong> Deriving them means scanning the
       column per cell, and a scale that rescaled as rows were filtered would change a cell's colour
-      without its value changing — the opposite of what the colour is for.</p>
+      without its value changing, the opposite of what the colour is for.</p>
     </div>
     <h2 id="formatting-guide">Formatting an end user can change</h2>
@@ -4283,8 +4283,8 @@ grid.formatting.clear('margin');</code></pre>
     </div>
     <div class="why">
       <p><strong>Two scopes, one ordered list.</strong> A rule sits on a column id or on
-      <code>'*'</code> for every column. Evaluation joins them — grid-wide first, then the column's
-      own — so a column rule can override a grid-wide one, and <code>stopIfTrue</code> means the
+      <code>'*'</code> for every column. Evaluation joins them: grid-wide first, then the column's
+      own, so a column rule can override a grid-wide one, and <code>stopIfTrue</code> means the
       same thing across the join as it does within either half.</p>
       <p><strong>Saved views and undo came free.</strong> The rules are a section of
       <code>GridState</code>, and both saved views and the undo timeline are built on that. Nothing
@@ -4303,12 +4303,12 @@ grid.formatting.clear('margin');</code></pre>
       <pre><code>createGrid(el, { toolPanel: { side: 'right', panels: ['columns', 'filters', 'formatting'] } });</code></pre>
     </div>
     <div class="why">
-      <p>The panel is a form over that array and nothing more — every control is one call into
+      <p>The panel is a form over that array and nothing more: every control is one call into
       <code>grid.formatting</code>, which is what makes each gesture undoable without the panel
       knowing undo exists. It exposes ordering because ordering is meaning: dragging a rule up can
       change which of two colours a cell takes.</p>
       <p><strong>Not yet in the panel:</strong> icon sets and data bars. Both are column decorations
-      rather than cell styles — the <code>bar</code> and <code>icon</code> decorations already
+      rather than cell styles, the <code>bar</code> and <code>icon</code> decorations already
       render them, and driving those from the panel needs a runtime column-decoration API that
       persists and undoes alongside the rules. Building it as a second bar implementation inside
       the rule engine was the alternative, and the wrong one.</p>
@@ -4324,7 +4324,7 @@ grid.formatting.clear('margin');</code></pre>
 grid.filters.quick('crc',  { mode: 'fuzzy' });        <span class="cmt">// characters in order</span>
 grid.filters.quick('^CIR-[12]', { mode: 'regex' });
-grid.filters.quick('acme');       <span class="cmt">// mode persists — still 'regex' here</span>
+grid.filters.quick('acme');       <span class="cmt">// mode persists: still 'regex' here</span>
 grid.filters.quickState();        <span class="cmt">// { text, mode }</span></code></pre>
     </div>
     <div class="why">
@@ -4365,7 +4365,7 @@ grid.filters.quickState();        <span class="cmt">// { text, mode }</span></co
     </div>
     <div class="why">
       <p><strong>A cell is a few hundred pixels seen for a second</strong>, so there are no axes, no
-      gridlines and no legend. The chart carries one idea — a shape, a share, a comparison — and the
+      gridlines and no legend. The chart carries one idea (a shape, a share, a comparison) and the
       number beside it carries the precision. Hide the number with <code>label: false</code> when the
       column next to it already says the same thing.</p>
       <p><strong>Pin <code>min</code> and <code>max</code> when columns are meant to compare.</strong>
@@ -4373,12 +4373,12 @@ grid.filters.quickState();        <span class="cmt">// { text, mode }</span></co
       by an order of magnitude draw identically. Pinning the scale is what makes the column readable
       down its length rather than only across it.</p>
       <p><strong>A gap is not a zero.</strong> Entries that are not numbers break the line and omit
-      the bar, rather than being drawn at the baseline — joining across a missing reading would draw
+      the bar, rather than being drawn at the baseline: joining across a missing reading would draw
       a trend nobody measured, and drawing it at zero invents a dip.</p>
       <p><strong>Cost.</strong> Each chart is one SVG built once, with the paths' <code>d</code>
       attributes the only thing a repaint writes, and a bar chart is two paths rather than one
       element per bar. Rows recycle as you scroll, so this is what keeps a chart column the same
-      price as a text one. Nothing measures the DOM — the drawing happens in a fixed coordinate
+      price as a text one. Nothing measures the DOM, the drawing happens in a fixed coordinate
       space that CSS scales.</p>
       <p><strong>Accessibility.</strong> The chart is <code>aria-hidden</code> and the cell carries a
       summary: "12 points, 9 to 20, ending 18". A path cannot be read aloud, and a series announced
@@ -4409,14 +4409,14 @@ grid.filters.quickState();        <span class="cmt">// { text, mode }</span></co
       <em>user</em> typed into a cell. Handing it to the JavaScript engine would let anyone who can
       edit a cell read your cookies, call your API with your credentials, or post the grid's contents
       anywhere. It is a hand-written tokeniser and recursive-descent parser, and the only callable
-      things are the built-in functions — <code>constructor</code>, <code>globalThis</code> and
+      things are the built-in functions: <code>constructor</code>, <code>globalThis</code> and
       <code>constructor.constructor("return 1")()</code> all simply fail to resolve.</p>
       <p><strong>The result is stored, not the expression.</strong> A formula is a way of
       <em>entering</em> a value, exactly like <code>1,200</code> or <code>(50)</code> or
       <code>12%</code>. It commits as one undo step, fires one <code>cell:changed</code>, and passes
       through the column's own validation.</p>
       <p><strong>The result is stored, not the formula.</strong> The expression is evaluated once, at
-      the moment you commit it, and what lands in the cell is a value like any other — so it does not
+      the moment you commit it, and what lands in the cell is a value like any other, so it does not
       recalculate when a cell it referred to changes later. For a value that must stay in step with
       its inputs, use a computed column, which is re-evaluated whenever its dependencies move.</p>
     </div>
@@ -4436,14 +4436,14 @@ r.ok ? r.value : r.error;   <span class="cmt">// 42</span></code></pre>
     </div>
     <p class="lead-in">
       A formula that cannot be read rejects the edit and the cell keeps its old value, the same as any
-      other unparseable text. Failures are returned rather than thrown — this runs on the commit path,
+      other unparseable text. Failures are returned rather than thrown: this runs on the commit path,
       where an exception would abandon the commit half-done.
     </p>
     <div class="why">
       <p><strong>Bare arithmetic is deliberately not a formula.</strong> <code>2-1</code> is a
       plausible product code and <code>1/2</code> a plausible date. A reader that evaluated either on
       a guess would have to guess wrong sometimes, and the wrong answer is not a visible error but a
-      plausible number — <code>2*3</code> stored as <strong>23</strong> looks like data. Arithmetic
+      plausible number: <code>2*3</code> stored as <strong>23</strong> looks like data. Arithmetic
       without a leading <code>=</code> is refused outright, so the cell keeps what it had rather than
       taking a number nobody typed.</p>
     </div>
@@ -4474,7 +4474,7 @@ r.ok ? r.value : r.error;   <span class="cmt">// 42</span></code></pre>
     <div class="why">
       <p><strong>Handed the defaults, rather than replacing them.</strong> A builder that had to
       return every item in order to append one would be written once as a copy of the built-ins and
-      would then drift from them — the copy keeps the menu it was forked from, and stops gaining
+      would then drift from them, the copy keeps the menu it was forked from, and stops gaining
       whatever the grid adds later. Spreading <code>defaults</code> costs one line and never goes
       stale.</p>
       <p>Return the array you want shown: add, remove, reorder, or replace outright. An empty array
@@ -4485,7 +4485,7 @@ r.ok ? r.value : r.error;   <span class="cmt">// 42</span></code></pre>
     <p class="lead-in">
       <code>columnMenu</code> takes the same function form, for both routes into a column's menu:
       the header's 3-dot button and a right-click on the heading. Its <code>params</code> is
-      <code>{ colId, column, grid }</code>, and the same rules apply — spread the defaults, return
+      <code>{ colId, column, grid }</code>, and the same rules apply: spread the defaults, return
       an empty array to suppress, return nothing to leave them alone.
     </p>
     <div class="example">
@@ -4528,7 +4528,7 @@ r.ok ? r.value : r.error;   <span class="cmt">// 42</span></code></pre>
     </div>
     <p class="lead-in">
       <code>title</code> and <code>icon</code> may each be a function, re-read on every repaint, for
-      a control whose meaning changes — that is how maximise becomes restore. <code>enabled</code> is
+      a control whose meaning changes: that is how maximise becomes restore. <code>enabled</code> is
       a predicate rather than a flag, so a button that cannot do anything greys itself out instead of
       doing nothing when clicked.
     </p>
@@ -4554,7 +4554,7 @@ r.ok ? r.value : r.error;   <span class="cmt">// 42</span></code></pre>
     </div>
     <div class="why">
       <p><strong>An explicit <code>actions</code> array replaces the default rather than extending
-      it.</strong> That is what makes it useful — you choose the set and the order — but it also
+      it.</strong> That is what makes it useful (you choose the set and the order) but it also
       means a config written against an earlier version keeps exactly the buttons it named and
       silently misses anything added since. If you want whatever the current version offers, leave
       the key out.</p>
@@ -4589,19 +4589,19 @@ createGrid(el, { maximise: <span class="kw">false</span> });</code></pre>
     <div class="why">
       <p><strong>The element is moved, not just restyled.</strong> A <code>position: fixed</code>
       element is positioned against the nearest ancestor carrying a <code>transform</code>,
-      <code>filter</code>, <code>contain</code> or <code>will-change</code> — which is to say any
-      card, any animated panel, any sticky app shell — and against the viewport only when there is
+      <code>filter</code>, <code>contain</code> or <code>will-change</code>, which is to say any
+      card, any animated panel, any sticky app shell, and against the viewport only when there is
       no such ancestor. A class alone would therefore fill the window on one page and land in a
       300px box on the next, and would still be clipped by an <code>overflow: hidden</code> or
       buried by a stacking context. Reparenting to <code>&lt;body&gt;</code> removes every ancestor
       that could do any of that.</p>
       <p>Coming back is a hidden placeholder left in the element's place, not a remembered parent
-      and index — an index goes stale the moment your application inserts a sibling while the grid
+      and index, an index goes stale the moment your application inserts a sibling while the grid
       is away, and then silently reinserts in the wrong slot. The placeholder also holds the vacated
       space open at the size the grid had, so the page behind neither reflows nor loses its scroll
       position while you are looking at the grid.</p>
       <p>The geometry is written as inline styles and every displaced property is handed back
-      exactly as it was found, because the element being restyled is <em>yours</em> — most often one
+      exactly as it was found, because the element being restyled is <em>yours</em>: most often one
       with an inline <code>height</code> on it, which is the ordinary way a grid gets sized and
       which nothing but an inline style can beat. While maximised, the element carries
       <code>.lat-maximised</code> and <code>&lt;body&gt;</code> carries
@@ -4630,7 +4630,7 @@ grid.highlight.clear();</code></pre>
     </p>
     <h2 id="views-guide">Saved views</h2>
     <p class="lead-in">
-      A view is a named grid state — sort, filters, grouping, column order, widths, visibility.
+      A view is a named grid state: sort, filters, grouping, column order, widths, visibility.
       There are two kinds and the picker keeps them apart.
     </p>
     <div class="example">
@@ -4651,14 +4651,14 @@ grid.highlight.clear();</code></pre>
     </div>
     <p class="lead-in">
       Views in <code>saved</code> are <strong>defined views</strong>: part of the application,
-      listed under their own heading, and neither renamable nor deletable — refused by the model as
+      listed under their own heading, and neither renamable nor deletable: refused by the model as
       well as hidden in the interface. A view flagged <code>isDefault</code> is applied on load.
       Everything the user saves sits below, with rename, share, make-default and delete.
     </p>
     <div class="why">
       <p><strong>Applying a view is a destination, not a patch.</strong> A view's state names only
       the sections it cares about, so applying one resets to the grid's starting state first. Without
-      that, clicking "APAC capacity" after "Commercial" would inherit Commercial's hidden columns —
+      that, clicking "APAC capacity" after "Commercial" would inherit Commercial's hidden columns ,
       the same view giving a different grid depending on what preceded it, which is the one thing a
       named view must not do.</p>
     </div>
@@ -4673,7 +4673,7 @@ grid.highlight.clear();</code></pre>
       <table>
         <thead><tr><th>What changed</th><th>What a saved view does</th></tr></thead>
         <tbody>
-          <tr><td class="name">A column was added</td><td class="desc"><strong>It appears</strong>, in the state its definition declares, placed after every column the view names. A view is not a whitelist — it says nothing about columns it has never seen, and silence is not an instruction to hide.</td></tr>
+          <tr><td class="name">A column was added</td><td class="desc"><strong>It appears</strong>, in the state its definition declares, placed after every column the view names. A view is not a whitelist, it says nothing about columns it has never seen, and silence is not an instruction to hide.</td></tr>
           <tr><td class="name">A column was added, and should not appear yet</td><td class="desc">Declare it <code>layout: { hidden: true }</code>. The view does not mention it, so nothing overrides that, and it stays hidden until the user shows it.</td></tr>
           <tr><td class="name">A column was removed</td><td class="desc">The entries naming it are skipped and reported; the rest of the view applies. A sort or grouping on the missing column is dropped rather than left pointing at nothing.</td></tr>
           <tr><td class="name">A column was renamed</td><td class="desc">That is a removal and an addition. The old id is skipped, the new column appears at the end, and any width or pinning the user had set is lost with the old id.</td></tr>
@@ -4682,8 +4682,8 @@ grid.highlight.clear();</code></pre>
     </div>
     <div class="why">
-      <p><strong>Applying a view never throws and never refuses.</strong> It returns a report —
-      <code>{ applied, skipped }</code> — naming each thing it could not use and why. Refusing the
+      <p><strong>Applying a view never throws and never refuses.</strong> It returns a report ,
+      <code>{ applied, skipped }</code>: naming each thing it could not use and why. Refusing the
       whole view because one column has gone would lose a layout the user built deliberately, and
       throwing during a page load would lose the page. So a view degrades to as much of itself as
       still makes sense, and the host decides whether the user needs telling.</p>
@@ -4701,7 +4701,7 @@ grid.highlight.clear();</code></pre>
     <p class="lead-in">
       The consequence worth planning for is the first one: <strong>a column added in a new release
       is visible to everyone, including users with a saved view.</strong> That is usually what you
-      want — a new field nobody can see is a field nobody uses — but if a release adds several at
+      want (a new field nobody can see is a field nobody uses) but if a release adds several at
       once, every saved view gains them all at the right-hand end. Ship them hidden if that is not
       the introduction you want.
     </p>
@@ -4733,16 +4733,16 @@ grid.on('view:default', e =&gt; api.patch(`/views/${e.view.id}`, { isDefault: tr
     <div class="why">
       <p><strong>The other half of the same seam.</strong> <code>views.storage</code> above is where
-      a developer plugs in their own backend — a real server, reached over the network. Not every
+      a developer plugs in their own backend, a real server, reached over the network. Not every
       grid has one to plug in, and a picker offering "Save" that quietly does nothing until a backend
       exists is worse than not offering it. <code>views.local: true</code> is the no-backend answer:
       saved views live in this browser's own <code>localStorage</code>, under a default key shared by
-      every grid on the origin unless you pass one of your own —
-      <code>views: { local: { key: 'orders-grid-views' } }</code> — to keep two grids' views apart.
+      every grid on the origin unless you pass one of your own ,
+      <code>views: { local: { key: 'orders-grid-views' } }</code>: to keep two grids' views apart.
       Given alongside an explicit <code>storage</code>, the explicit adapter always wins and
-      <code>local</code> is silently — well, not silently: it warns once — ignored, so a page cannot
+      <code>local</code> is silently (well, not silently: it warns once) ignored, so a page cannot
       end up writing to both without meaning to. The adapter itself is exported as
-      <code>createLocalViewStorage(opts)</code>, for anyone who wants it directly — a custom key
+      <code>createLocalViewStorage(opts)</code>, for anyone who wants it directly, a custom key
       without the shorthand, or a different <code>Storage</code>-shaped backing such as
       <code>sessionStorage</code> for views scoped to one tab rather than persisted across visits.</p>
     </div>
@@ -4750,7 +4750,7 @@ grid.on('view:default', e =&gt; api.patch(`/views/${e.view.id}`, { isDefault: tr
     <h2 id="history-guide">Undo</h2>
     <p class="lead-in">
       Undo covers the whole grid, not only edits. Sorts, filters, column moves, grouping, an applied
-      view and a restore all record an entry — and each carries a label written for a button.
+      view and a restore all record an entry, and each carries a label written for a button.
     </p>
     <div class="example">
       <p class="example__label">Naming the action</p>
@@ -4759,7 +4759,7 @@ grid.history.undo();
 grid.history.list();         <span class="cmt">// the timeline, newest first</span></code></pre>
     </div>
     <div class="why">
-      <p>A button that says only "Undo" makes the user press it to find out what it does — and
+      <p>A button that says only "Undo" makes the user press it to find out what it does: and
       pressing it is the thing they were unsure about. "Undo sort by Region" is decided before the
       click rather than after.</p>
     </div>
@@ -4779,16 +4779,16 @@ grid.history.list();         <span class="cmt">// the timeline, newest first</sp
     <h2 id="permissions-guide">Column permissions</h2>
     <p class="lead-in">
-      Four levels, resolved per column from configuration or a callback. They are not a ladder —
+      Four levels, resolved per column from configuration or a callback. They are not a ladder ,
       reading and writing are independent, so they are the four corners of a 2×2.
     </p>
     <div class="table-wrap">
       <table>
         <thead><tr><th>Level</th><th>Visible</th><th>Readable</th><th>Editable</th><th>For</th></tr></thead>
         <tbody>
-          <tr><td class="sig">hidden</td><td>—</td><td>—</td><td>—</td><td class="desc">Absent from the grid, the tool panel, exports, the clipboard, saved state and the filter model.</td></tr>
-          <tr><td class="sig">read</td><td>yes</td><td>yes</td><td>—</td><td class="desc">No editor opens; paste, fill and clear skip it.</td></tr>
-          <tr><td class="sig">writeOnly</td><td>yes</td><td>—</td><td>yes</td><td class="desc">A secret. The cell shows a mask, the editor opens empty.</td></tr>
+          <tr><td class="sig">hidden</td><td>, </td><td>, </td><td>, </td><td class="desc">Absent from the grid, the tool panel, exports, the clipboard, saved state and the filter model.</td></tr>
+          <tr><td class="sig">read</td><td>yes</td><td>yes</td><td>, </td><td class="desc">No editor opens; paste, fill and clear skip it.</td></tr>
+          <tr><td class="sig">writeOnly</td><td>yes</td><td>, </td><td>yes</td><td class="desc">A secret. The cell shows a mask, the editor opens empty.</td></tr>
           <tr><td class="sig">write</td><td>yes</td><td>yes</td><td>yes</td><td class="desc">The default, so the feature is opt-in.</td></tr>
         </tbody>
       </table>
@@ -4811,12 +4811,12 @@ grid.permissions.setContext({ role: 'clerk' });        <span class="cmt">// re-r
     <div class="note note--warn">
       <p><strong>For three of the four this is a usability control, not a security boundary.</strong>
       Anything the grid can render it has already loaded, and devtools reaches it. Hiding a column
-      removes it from the interface, not from the process — which is worth a great deal for the way
+      removes it from the interface, not from the process, which is worth a great deal for the way
       data actually leaks, which is an export mailed onward or a shared view carrying a column a
       colleague should not see. It is worth nothing against someone determined.</p>
       <p><code>writeOnly</code> is the exception, and the reason it exists. Nothing in the grid needs
       the value, so your server can send <code>null</code> for that field and the column still
-      works — at which point the secret is genuinely not on the page. Enforce everything else
+      works: at which point the secret is genuinely not on the page. Enforce everything else
       server-side; <code>permittedColumns</code> and <code>permittedExport</code> are pure and
       dependency-free so the same policy object runs in Node against a request that arrived over
       the wire.</p>
@@ -4850,17 +4850,17 @@ grid.diff.before('CIR-100042', 'capacity');</code></pre>
     </div>
     <div class="why">
       <p><strong>The row is gone from the data and still in the snapshot.</strong> That is the only
-      place it exists, and it is what these rows are built from — so they carry the values they had
+      place it exists, and it is what these rows are built from, so they carry the values they had
       when the snapshot was taken, not any current ones.</p>
       <p><strong>One option answers both questions:</strong> whether to show it, and whether it
       counts. <code>'pinned'</code> puts it beneath the rows, struck through and dimmed, outside the
-      row set — so <code>rows.count()</code>, exports and selection all pass over it.
+      row set, so <code>rows.count()</code>, exports and selection all pass over it.
       <code>'data'</code> appends it to the set instead, and all three include it. Omitted, nothing
       is shown and the grid is the one you already had.</p>
       <p><strong>Neither sorts or filters it among the live rows.</strong> A removed row's values
       are yesterday's; ordering them among today's presents two data sets as one, and lets a filter
       written for current values decide the fate of historical ones. Neither permits an edit either
-      — a write aimed at a removed row is refused and returns <code>0</code>, rather than being
+     , a write aimed at a removed row is refused and returns <code>0</code>, rather than being
       counted as applied against a record that is not there.</p>
     </div>
@@ -4884,15 +4884,15 @@ grid.diff.before('CIR-100042', 'capacity');</code></pre>
     <p class="lead-in">
       That mounts a prompt bar. The user types "EMEA circuits over 500 gigs, biggest first"; the
       grid composes a message including its schema; your callback returns the model's reply; the
-      grid validates it and shows what it would do in plain English —
-      <em>"Filter Region is EMEA and Capacity is more than 500, sort Capacity descending"</em> —
+      grid validates it and shows what it would do in plain English ,
+      <em>"Filter Region is EMEA and Capacity is more than 500, sort Capacity descending"</em> ,
       with Apply and Discard.
     </p>
     <div class="why">
-      <p><strong>Nothing is executed on trust.</strong> The vocabulary is seven actions —
+      <p><strong>Nothing is executed on trust.</strong> The vocabulary is seven actions ,
       <code>setFilters</code>, <code>setSort</code>, <code>groupBy</code>,
       <code>showColumns</code>, <code>hideColumns</code>, <code>setQuick</code>,
-      <code>clear</code> — and a reply naming a column that does not exist is rejected with a
+      <code>clear</code>, and a reply naming a column that does not exist is rejected with a
       reason while the valid actions in the same reply are kept. A model cannot be talked into an
       operation the vocabulary does not contain, because there is nothing else to call.</p>
     </div>
@@ -4910,7 +4910,7 @@ grid.export.clipboard({ headers: true, rows: 'range' });
 grid.export.print();</code></pre>
     </div>
     <p class="lead-in">
-      Exports follow what the user is looking at — the current filter, sort and column order,
+      Exports follow what the user is looking at, the current filter, sort and column order,
       formatted values, and only the columns they may read.
     </p>
@@ -4938,7 +4938,7 @@ grid.state.apply(savedView.state);
     <h2 id="webcomponent-guide">Web component</h2>
     <p class="lead-in">
       <code>&lt;lattice-grid&gt;</code> is the grid as a custom element, shipped as a self-contained
-      module bundle. It exists for pages without a bundler — a Rails, Django or Laravel template
+      module bundle. It exists for pages without a bundler, a Rails, Django or Laravel template
       that wants a grid without adopting a front-end build.
     </p>
     <div class="example">
@@ -4951,7 +4951,7 @@ grid.state.apply(savedView.state);
   rows='[{"id":"A","city":"Leeds"},{"id":"B","city":"Cardiff"}]'&gt;&lt;/lattice-grid&gt;</code></pre>
     </div>
     <div class="why">
-      <p><strong>Load this or the main bundle, not both.</strong> The module is self-contained — it
+      <p><strong>Load this or the main bundle, not both.</strong> The module is self-contained: it
       carries the grid with it, so a page that also loads <code>lattice-grid.esm.js</code>
       downloads and evaluates the grid twice.</p>
     </div>
@@ -4971,8 +4971,8 @@ el.grid.sort.set([{ col: 'charge', dir: 'desc' }]);</code></pre>
     <div class="why">
       <p><strong>Assign before appending where you can.</strong> The element builds its grid once,
       at the end of the task in which it connects, so everything set in that task arrives as one
-      configuration rather than as a series of updates. Setting properties later still works — they
-      go through the live configuration path — but the grid is built empty first and repainted
+      configuration rather than as a series of updates. Setting properties later still works: they
+      go through the live configuration path, but the grid is built empty first and repainted
       after, which is a visible flash on a large set.</p>
       <p>Reading <code>.grid</code> forces the build immediately, so the property is never briefly
       null.</p>
@@ -4995,7 +4995,7 @@ el.grid.sort.set([{ col: 'charge', dir: 'desc' }]);</code></pre>
       <p><strong>Light DOM, deliberately.</strong> The element renders into itself rather than a
       shadow root, because the grid's generated decoration rules are injected into
       <code>document.head</code> and the theme stylesheet is a <code>&lt;link&gt;</code> the page
-      owns — neither crosses a shadow boundary. A shadowed grid would be structurally correct and
+      owns: neither crosses a shadow boundary. A shadowed grid would be structurally correct and
       completely unstyled, and subtly so: the <code>--lattice-*</code> tokens <em>do</em> inherit
       through a shadow root, so the colours would arrive while every pill, bar and heat cell stayed
       bare. Light DOM keeps every documented theming route working unchanged.</p>
@@ -5013,7 +5013,7 @@ el.grid.sort.set([{ col: 'charge', dir: 'desc' }]);</code></pre>
           <tr><td class="name">ready</td><td class="type">{}</td><td class="desc">First render is done. Fires on a future turn, so you can subscribe on the line after <code>createGrid</code>.</td></tr>
           <tr><td class="name">cell:changed</td><td class="type">{ row, key, colId, value, oldValue, undo }</td><td class="desc">Persisting an edit. <code>undo</code> distinguishes a rollback from a fresh change.</td></tr>
           <tr><td class="name">selection:changed</td><td class="type">{ keys }</td><td class="desc">Enabling a bulk action.</td></tr>
-          <tr><td class="name">range:changed</td><td class="type">{ ranges }</td><td class="desc">A status bar showing the sum of what is selected — see <code>selection.summary()</code>.</td></tr>
+          <tr><td class="name">range:changed</td><td class="type">{ ranges }</td><td class="desc">A status bar showing the sum of what is selected: see <code>selection.summary()</code>.</td></tr>
           <tr><td class="name">sort:changed / filter:changed</td><td class="type">{ sort } / { filters }</td><td class="desc">Reflecting the view in the URL.</td></tr>
           <tr><td class="name">history:changed</td><td class="type">{ canUndo, canRedo, undo, redo }</td><td class="desc">Driving your own undo button. Emitted <em>after</em> the entry is pushed, so the label is right.</td></tr>
           <tr><td class="name">history:applied</td><td class="type">{ direction, step }</td><td class="desc">An action was undone or redone, with which and what. <code>history:changed</code> also fires when a new action is pushed, so it cannot distinguish the two.</td></tr>
@@ -5032,8 +5032,8 @@ el.grid.sort.set([{ col: 'charge', dir: 'desc' }]);</code></pre>
       watermark; that is the whole of what it does.
     </p>
     <p class="lead-in">
-      Free to develop against, licensed to deploy. A grid on <strong>localhost</strong> — or any
-      loopback host — needs no key at all. On any other domain an unlicensed grid still renders
+      Free to develop against, licensed to deploy. A grid on <strong>localhost</strong>, or any
+      loopback host: needs no key at all. On any other domain an unlicensed grid still renders
       everything and carries a small trial watermark linking to latticegrid.dev.
     </p>
     <div class="table-wrap">
@@ -5052,24 +5052,24 @@ el.grid.sort.set([{ col: 'charge', dir: 'desc' }]);</code></pre>
 grid.licence.state();   <span class="cmt">// 'licensed' | 'localhost' | 'trial'</span></code></pre>
     </div>
     <p class="lead-in">
-      Call it once, before creating a grid. Setting a key later still works — the watermark comes
-      off and <code>licence:changed</code> fires — but the first frames of the grid will carry it.
+      Call it once, before creating a grid. Setting a key later still works, the watermark comes
+      off and <code>licence:changed</code> fires, but the first frames of the grid will carry it.
     </p>
     <p class="lead-in">
       Keys come from <a href="https://www.latticegrid.dev">latticegrid.dev</a> and are issued per
       deployment rather than per developer or per seat: name the domains the grid will run on and
       one key covers every developer, every build and every user on them. A key names the domains
-      it covers as you would expect — <code>*.acme.com</code> matches <code>app.acme.com</code>,
+      it covers as you would expect: <code>*.acme.com</code> matches <code>app.acme.com</code>,
       <code>a.b.acme.com</code> and <code>acme.com</code> itself.
     </p>
     <p class="lead-in">
       Checking a key needs no network. There is no licence server, no call home, and nothing that
-      can fail at three in the morning — a key carries its own answer and the grid reads it
+      can fail at three in the morning, a key carries its own answer and the grid reads it
       locally, so a grid on an air-gapped network behaves exactly like one on the open internet.
     </p>
     <div class="why">
       <p><strong>Nothing ever refuses to render, and nothing is ever withheld.</strong> An expired
-      key, a wrong domain, a key that will not read — all of them log one warning and show the
+      key, a wrong domain, a key that will not read: all of them log one warning and show the
       watermark. Every feature keeps working. The failure to avoid is a customer's production
       screen going blank because a licence lapsed over a weekend, and a grid that quietly drops a
       feature is the same failure wearing a disguise.</p>
@@ -5127,7 +5127,7 @@ grid.licence.state();   <span class="cmt">// 'licensed' | 'localhost' | 'trial'<
     <footer>
       <p>
         Lattice Grid 1.7.1 · Copyright © 2026 TOCLOCO Inc. All rights reserved.
-        Written against the shipped source. Where this guide and the code disagree, the code wins —
+        Written against the shipped source. Where this guide and the code disagree, the code wins ,
         please <a href="https://www.latticegrid.dev">tell us</a>.
       </p>
     </footer>