Building a sortable data-journalism page in Astro: 33K FARS records, sparklines, and the bugs that nearly broke it

Marvin Bregiosa — Mon, 01 Jun 2026 07:27:03 +0000

I just shipped a data-journalism page comparing truck-involved fatalities across 19 major US cities (2018–2024). It lives on AccidentLawyerReview, an independent public-data directory I run.

The story it tells is more interesting than the tech stack - of 17 US cities that formally adopted Vision Zero, only 10 actually cut truck deaths. Eight got worse. New York, the very first major Vision Zero adopter, saw truck fatalities rise 13% over the period. But that's content; this post is about the build.

The whole thing is Astro 6 + vanilla JS + Python. No React, no D3, no charting library. Roughly two days of work, including the bugs. Here's what worked, what bit me, and what code is worth lifting.

1. The data - NHTSA FARS, joined locally

The Fatality Analysis Reporting System (FARS) is a federal census of every fatal traffic crash in the US. It ships as a zip of CSVs, ~30 MB per year, downloadable directly from NHTSA's static S3:

https://static.nhtsa.gov/nhtsa/downloads/FARS/2024/National/FARS2024NationalCSV.zip
https://static.nhtsa.gov/nhtsa/downloads/FARS/2023/National/FARS2023NationalCSV.zip
...

For seven years that's about 230 MB. Inside each zip, the relevant tables are accident.csv (one row per fatal crash) and vehicle.csv (one row per vehicle in those crashes).

The join I needed:

For each year, find every fatal crash where at least one vehicle is a medium/heavy truck (FARS body-type codes 60–69), then sum FATALS per city per year.

Body-type codes 60–69 cover the full medium/heavy truck range — step vans, single-unit straight trucks, truck-tractors (the cab of a semi), and unknown medium/heavy types. They exclude passenger pickups under 10,000 lb, which is what you want for actual truck-crash analysis.

Parser gotcha 1: BOM bytes in some years

I wrote a vanilla csv.DictReader loop and immediately got KeyError: 'STATE' on 2021–2024 files. The header looked fine in a text editor, but when read as latin-1 the first three bytes were \xef\xbb\xbf — the UTF-8 BOM, getting decoded as the chars ï»¿. So the first field name was ï»¿STATE, not STATE.

The fix is one of: open with utf-8-sig (which strips BOM), or strip the bytes manually. I went with the manual strip because 2018 files have non-UTF-8 bytes elsewhere (latin-1 forever):

def _reader(path):
    f = open(path, encoding='latin-1')
    reader = csv.DictReader(f)
    if reader.fieldnames:
        first = reader.fieldnames[0]
        if first.startswith('ï»¿'):
            reader.fieldnames[0] = first[3:]
    return f, reader

Parser gotcha 2: folder structure varies

Older years extract straight to FARS2018/, newer ones to FARS2024/FARS2024NationalCSV/. Trivial but worth a map:

PATHS = {
    2018: 'FARS2018',
    2019: 'FARS2019',
    2020: 'FARS2020/FARS2020NationalCSV',
    2021: 'FARS2021/FARS2021NationalCSV',
    2022: 'FARS2022/FARS2022NationalCSV',
    2023: 'FARS2023/FARS2023NationalCSV',
    2024: 'FARS2024/FARS2024NationalCSV',
}

The join

For each year, two passes:

truck_cases = set()
f, r = _reader(base / 'vehicle.csv')
for row in r:
    bt = int(row.get('BODY_TYP') or 0)
    if 60 <= bt <= 69:
        truck_cases.add((int(row['STATE']), int(row['ST_CASE'])))

by_city = defaultdict(int)
f, r = _reader(base / 'accident.csv')
for row in r:
    state = int(row['STATE'])
    st_case = int(row['ST_CASE'])
    fatals = int(row['FATALS'])
    city = int(row.get('CITY', 0) or 0)
    if (state, st_case) in truck_cases:
        by_city[(state, city)] += fatals

Output: a JSON blob with per-city series for the 19 target cities, baseline vs recent average, and the percentage change. About 33,898 fatal truck-involved crashes across all states 2018–2024, distilled to a 12 KB JSON. (The full script, JSON, and a filtered row-level CSV are all linked at the bottom of the published page under CC BY 4.0.)

2. The page — Astro 6, no framework

The report card is a single .astro file. The frontmatter imports the JSON, sorts cities into "improved" and "worse" arrays, derives some headline stats. Everything else is just JSX-ish templating with a <style> block. No client-side data fetching — Astro pre-renders the table at build time, browser gets static HTML.

The two interactive features that needed JS:

Sortable columns

Click any column header to sort the table. I wanted plain DOM manipulation, no library. The pattern: every sortable <th> declares its sort type (num or text) and a default direction. Every <td> carries a data-v attribute with the comparable value (because the visible text often differs — "—" for nulls, "+13.1%" strings, etc.).

<th class="sort" data-sort="num" data-default-dir="desc">Change</th>
...
<td data-v="-50.0">-50.0%</td>

The handler:

function wireSortableTable(table) {
  const headers = Array.from(table.querySelectorAll('th.sort'));
  const tbody = table.querySelector('tbody');
  headers.forEach((th) => {
    const colIdx = th.cellIndex;  // <-- THIS LINE took an hour to find
    th.addEventListener('click', () => {
      const sortType = th.dataset.sort || 'text';
      const currentDir = th.dataset.active;
      const defaultDir = th.dataset.defaultDir || 'asc';
      const nextDir = currentDir === 'asc' ? 'desc'
                    : currentDir === 'desc' ? 'asc'
                    : defaultDir;
      headers.forEach((h) => h.removeAttribute('data-active'));
      th.setAttribute('data-active', nextDir);

      const rows = Array.from(tbody.querySelectorAll('tr'));
      const sortRows = rows.filter((r) => !r.classList.contains('totals-row'));
      const pinnedRows = rows.filter((r) => r.classList.contains('totals-row'));

      sortRows.sort((a, b) => {
        const aRaw = a.children[colIdx]?.dataset.v ?? '';
        const bRaw = b.children[colIdx]?.dataset.v ?? '';
        const cmp = sortType === 'num'
          ? parseFloat(aRaw) - parseFloat(bRaw)
          : aRaw.localeCompare(bRaw);
        return nextDir === 'asc' ? cmp : -cmp;
      });
      sortRows.forEach((r) => tbody.appendChild(r));
      pinnedRows.forEach((r) => tbody.appendChild(r));
    });
  });
}
document.querySelectorAll('table.sortable').forEach(wireSortableTable);

The bug I burned an hour on: I originally wrote headers.forEach((th, colIdx) => ...). That gives you the index of th within the sortable headers list, not within the actual <tr>. The year-by-year table has a non-sortable "Trend" column between "City" and "2018", so every numeric column was off by one. Sorting "2018" actually sorted by the (empty) data-v on the Trend cell, which silently did nothing.

The fix is one character: th.cellIndex — the DOM-native property that gives the real position in the row, regardless of which siblings are sortable.

Inline sparklines, no library

The year-by-year table has a "Trend" column showing each city's 7-year shape next to the raw counts. Pure SVG, generated at build time:

{cities.map((c) => {
  const seriesArr = years.map((y) => c.series[y]);
  const mn = Math.min(...seriesArr);
  const mx = Math.max(...seriesArr);
  const range = Math.max(mx - mn, 1);  // avoid div-by-zero on flat lines
  const w = 80, h = 20;
  const pts = seriesArr.map((v, i) => {
    const x = (i / (seriesArr.length - 1)) * w;
    const y = h - ((v - mn) / range) * h;
    return `${x.toFixed(1)},${y.toFixed(1)}`;
  }).join(' ');
  const mean = seriesArr.reduce((s, n) => s + n, 0) / seriesArr.length;
  const last = seriesArr[seriesArr.length - 1];
  const dotColor = last > mean ? '#b91c1c' : '#047857';
  const lastY = h - ((last - mn) / range) * h;
  return (
    <svg viewBox={`0 0 ${w} ${h}`} width={w} height={h}>
      <polyline points={pts} fill="none" stroke="#9ca3af" stroke-width="1.4"
                stroke-linejoin="round" stroke-linecap="round" />
      <circle cx={w} cy={lastY.toFixed(1)} r="2.6" fill={dotColor} />
    </svg>
  );
})}

20 lines, no dependencies, looks clean, prints at any resolution. The dot at the end of the line uses red if 2024 closed above the 7-year mean, green if below — a one-glance "is this getting worse?" signal next to the numbers.

3. Three bugs that ate hours

Bug 1: Astro JSX parser inserted phantom `<strong>` tags

My first ranking table had a totals row at the bottom:

<tr class="totals-row">
  <td><strong>National (all states)</strong></td>
  {years.map((y) => <td class="num"><strong>{nationalSeries[y]}</strong></td>)}
  <td class="num"><strong>{totalReduce}</strong></td>
</tr>

In the served HTML, the closing </table></div></section> was followed by three empty phantom <strong></strong> tags, the third of which never closed. So the next two sections of the article — "Important caveats" and "Methodology" — were silently wrapped in an open <strong> tag. Every body paragraph in those sections inherited font-weight: bolder from the unclosed <strong> ancestor.

The user complaint that surfaced this: "all the text in the bottom of the page is bold." I spent way too long messing with color-scheme, font-smoothing, and Chrome dark-mode flags before I thought to actually look at the DOM tree.

When I finally ran a headless Playwright check on the computed font-weight of .caveats li, it came back 700. With nothing in my CSS setting that. Chromium DevTools showed the matched rules, and there it was — INHERITED SEL: b, strong { font-weight: bolder }. The <li> was inheriting from a <strong> ancestor that shouldn't have existed.

Workaround: pull the JSX expression Object.values(nationalSeries).reduce(...) out of the cell and compute it in the frontmatter as a plain variable. Don't put .map() returning JSX with <strong> adjacent to other <strong> rows. The pattern seems to trigger Astro's parser into emitting stray closing-tag artifacts. I haven't golfed the exact reproducer down — if you hit similar weight-inheritance ghosts on a page with map-rendered JSX tables, the first thing to do is inspect the raw HTML for unbalanced or empty inline-formatting tags around the boundary.

Bug 2: Chrome auto-dark + halation = "everything looks bold"

Same complaint, slightly different cause once the phantom-strong was fixed: on cream backgrounds (#fafaf9) with dark text (#1a1a1a), Chrome's auto-dark mode (the one behind chrome://flags/#enable-force-dark) sometimes kicks in even when system theme is light. The inverted version renders white text on dark bg, which always reads heavier than the original due to halation. The fix is the rare-in-the-wild only light:

html {
  color-scheme: only light;
}

<meta name="color-scheme" content="only light">
<meta name="darkreader-lock">  <!-- for the Dark Reader extension -->

color-scheme: light alone isn't enough if the user has the experimental flag enabled — the only qualifier is stricter and Chrome respects it.

Bug 3: Inter at 400 reads as semi-bold to many users

Even after fixing both above, a user reported the body text "still looks bold." I checked the computed weight — it was a clean 400. The text was just rendered with Inter Regular, which has a slightly thicker stem than SF Pro or Segoe at the same weight, and on warm/off-white backgrounds reads visually heavier.

Two fixes that helped:

body {
  font-weight: 300;
  -webkit-font-smoothing: antialiased;  /* lighter than Chrome's default subpixel */
}
b, strong {
  font-weight: 700;  /* explicit, because Tailwind 4 preflight sets `bolder`
                       which from a 300 base resolves to 400, not bold enough */
}

I also moved the font stack to put -apple-system ahead of Inter so macOS users get SF Pro by default. Inter stays as a fallback for users without a good native sans.

4. The whole stack, summarized

Piece	Tool	Why
Data pull	`urllib` + zips from `static.nhtsa.gov`	NHTSA hosts directly, no API rate limits
Data parse	Python `csv.DictReader`	7 years × ~50K rows is fine
Output	One JSON blob, one filtered CSV	Both downloadable from the page
Page	Astro 6, pre-rendered	No framework, no SSR, ships as static HTML
Interactivity	~50 lines vanilla JS for sort	No library, no hydration cost
Charts	Inline SVG polylines	20 lines, looks crisp at any DPI
Hosting	Cloudflare Pages	Free, fast, native to where the site lives

The whole research page weighs about 46 KB of HTML + the 12 KB JSON + 2 KB of CSS. No bundled JS framework runtime. Lighthouse mobile 99/100.

Takeaways

Datasets you host as CSV + JSON + the script that produced them is a hugely under-used pattern for indie data work. Journalists trust it, Google's Dataset Search indexes it, and you don't owe anyone an API. The schema.org Dataset markup with multiple Distribution entries gets you into Dataset Search's catalogue right next to NHTSA's own.
th.cellIndex exists. Stop manually counting columns in your sort handlers.
If users complain about font weight and you've already checked CSS, look at the DOM tree. Phantom inline-formatting tags from a template engine are silent killers.
color-scheme: only light - keep it in your global stylesheet if your brand is light-mode-by-design. The only qualifier survives Chrome's experimental force-dark flag.
A 2-day data-journalism build with public-data sourcing + downloadable methodology + downloadable raw is far stronger reporter-bait than another listicle. This one is generating real pickups from local press in 19 cities.

If you want to see it all in action - sortable tables, sparklines, downloads — the page is here: Vision Zero Report Card 2026. All source data and scripts are linked at the bottom under CC BY 4.0. If you build something with it, drop a link - I'd love to see what other angles people pull from the same dataset.

DEV Community: Marvin Bregiosa