The Table That Rendered As Prose
A minimal markdown converter turned every table into paragraphs full of pipe characters. Nobody noticed until content started using tables.
A hand-written markdown renderer had no table support, so every table became a paragraph of pipe characters. It went unnoticed for as long as no published article used one. The defect was in the renderer from day one; the content simply had not exercised it yet.
Symptom
Three articles were published containing comparison tables. On the rendered page each table appeared as a run of paragraphs filled with pipe characters and dashes — unreadable on a phone, and meaningless to a screen reader.
The renderer had never supported tables. It had simply never been asked.
Root cause
The site uses a hand-written markdown converter, chosen deliberately: no dependencies, no build chain, about 80 lines. It handles headings, lists, code blocks, quotes, links and emphasis.
For table syntax it had a fallback — wrap the line in a paragraph with a class and move on. That fallback was written as a placeholder and behaved correctly for what it was: it did not crash, and it preserved the text.
The defect was latent for exactly as long as the content avoided tables. The first 10 migrated articles used almost none. The moment three new artifacts arrived with comparison tables in them, a day-one gap became a visible one.
Cost
Small in absolute terms — three articles, caught before any external reader arrived. Worth recording anyway, because of what it says about the shape of the risk.
A minimal renderer's coverage is defined by the content it has already seen, not by the markdown specification. Every unused feature is an unexploded assumption, and the moment of detonation is chosen by whoever writes the next article.
| Buffer | State | Action | rendered as: a paragraph beginning with a pipe.
Fix
Real table rendering, in about 30 lines: collect consecutive table lines, detect the separator row, emit a proper <table> with a header, wrap it in a container with horizontal scroll.
Deliberately not an ASCII grid, despite the terminal aesthetic. An ASCII table cannot be read by a screen reader, cannot be copied into a spreadsheet, and does not wrap on a narrow screen. The identity of the site is carried by the chrome around the content, not by making data hostile.
Prevention
The useful question is not "does the renderer handle tables" but "which markdown features has this renderer actually been exercised on?"
For a deliberately minimal tool the answer should be written down next to it as a short supported-syntax list, so an author knows what is safe rather than discovering it after publishing. Anything not on the list should either be implemented or should fail the build — a silent passthrough is the worst of the three options, because it produces output that looks like a rendering decision rather than a missing feature.