HTML is for reading, not for source

In May 2026, Anthropic's Thariq Shihipar (@trq212) posted a thread called The Unreasonable Effectiveness of HTML. 5.4M views, 9.4k likes. The core argument: Markdown has become the default format for agents talking to humans, but it isn't enough — HTML is the endgame.

His case lands almost point for point on the thesis Plain was founded on — information density, readability, shareability, interactivity. Reading the thread, all we felt was the quiet thrill of being independently validated by a colleague.

But there's one passage in the thread we disagree with

In the FAQ, trq212 lists two pain points of HTML himself:

How do I view the HTML file? I tend to just open it in a browser locally, or upload to S3 if you want a shareable link.

What about version control? This is honestly one of the biggest downsides of HTML. HTML diffs are noisy and hard to review compared to Markdown.

He admits these two things are real pain points of HTML-as-source — and still argues that agents should emit HTML files directly. This is where we part ways.

Our thesis: HTML is for reading, not for source

Plain splits these two concerns into two layers:

• The source is text (Markdown / CSV / a bit of frontmatter). Diff it in git, edit it with AI, review it with a colleague. One change is one line of diff — reviewers never wade through 240 lines of noise.
• The render is HTML. Open it in a browser, send it as a link — it works on a client's Mac, an AI colleague, a PM's iPad. Want a .pptx? One-click marp export. Want a PDF? Print from the browser.

This path is harder to walk than "agents emit HTML files directly" — we have to write our own marp themes, build the two-way mapping for visual editing, build @ref cross-document sync, build an inspect mode that lets users edit both the source and the render. But it buys one important thing: your content stays editable forever, can always be rolled back, can always be re-understood by AI.

Why "source is text" is non-negotiable

Imagine you've made a deck and the client sends back one line: "change the retention number on slide 3 to 62%."

• If the source is .pptx: open PowerPoint, find slide 3, edit the text, the font size breaks, reflow, export, email it.
• If the source is HTML: edit it with AI — but the AI sees 240 lines of div + style + inline svg, and has to "understand" your design. When it's done you look at the diff: still 240 lines changed, and you have no idea which line is the real edit and which is formatting noise.
• If the source is Markdown (Plain's approach): 58% → 62%. One line of diff. One second to review. The rendered HTML is new on the next refresh — because the render was always a derivative of the source.

Why "render is HTML" is also non-negotiable

And the other way around — what if you only had source and no HTML render?

That's been the fate of Markdown tooling for the last 20 years — an internal format for programmers. Clients can't open it, AI can't see the hierarchy, and no one wants to treat it as a deliverable.

So we hold the line: text is the source, HTML is the face. What git sees and AI edits is the source; what the client, the boss, the hiring manager sees is the face.

What this looks like, concretely

Go to /showcase and open any deck — what you see is HTML (open-and-read in the browser). But click Open in Plain and what you get is a Markdown source — diff-friendly, AI-editable, version-revertible. Change one thing, and the render is new on the next pass.

That's the whole meaning of "HTML is for reading, not for source."

Plain is the Office workbench for the AI era. The source is text, the render is HTML, the delivery is a link. — read the full Manifesto.