Google Docs for HTML
When Google Docs launched, the surprise wasn't that it let you write documents in a browser. It was that it gave documents a comment layer — threaded, anchored to specific text, resolvable, persistent. Twenty years later, that comment layer is the reason most teams still default to Google Docs for collaborative work.
Comma is the same idea, applied to HTML.
The asymmetry that turned into a habit
Most modern artifacts are HTML by the time the team sees them:
- A dashboard export is HTML.
- A notebook render is HTML.
- A Claude or ChatGPT output, increasingly, is HTML.
- An eval report is HTML.
- A PR preview is HTML.
- A site is HTML.
And yet none of these get the comment-layer treatment Google Docs taught us to expect. To collaborate on an HTML artifact, teams either:
- Rebuild it inside Google Docs or Notion (losing the rendering)
- Screenshot it into Slack (losing the detail and the canonical artifact)
- Build a custom commenting widget on top (and become a comment-widget maintainer)
- Skip the comment layer entirely and have the conversation in DMs
The asymmetry isn't because HTML doesn't deserve a comment layer. It's because nobody built one that was sharp enough to be worth using as a default.
What "Google Docs for HTML" actually looks like
Six properties — the same ones that made Docs work, translated to HTML:
| Google Docs gave you... | Comma gives you... |
|---|---|
| A document at a stable URL | An HTML report at a stable URL |
| Anchored comments on text selections | Anchored comments on text selections inside the rendered HTML |
| Comments that survive edits | Comments that re-anchor across revisions of the report |
| Suggesting / resolving / replying | Threading, resolve, reopen, @ mentions |
| Link-based sharing with role-based access | Link-based sharing with role-based access |
| Comments that work even for invitees without an account | Anyone with the link can comment (Free: 3 per report) |
The difference is the surface. Google Docs renders a document its own way. Comma renders the HTML you generated, exactly as you generated it, inside an opaque-origin sandbox iframe — and overlays the comment layer outside the iframe so nothing touches the rendering.
What stays the same as Docs
The whole interaction model is what teams already know:
- Select text. Pin a comment.
- @ a teammate. They get notified.
- Reply on the thread.
- Resolve when addressed.
- Reopen if it comes back.
If your team already comments on Google Docs, they already know how to comment on a Comma report. There is no new pattern to teach.
What's different (and why)
Three deliberate differences from Google Docs:
1. Comma doesn't edit the document
Google Docs is a document editor. You write inside it. Comma is a document viewer + comment layer. The HTML comes from somewhere else — your dashboard, your notebook, your agent. Comma doesn't rewrite it; it renders it and adds a comment surface on top.
This is intentional. The artifact has already been generated; the job is the conversation about it. Editing isn't the bottleneck — collaboration is.
2. Revisions, not edit history
Google Docs has an edit history showing who typed what. Comma has a revision history — every time the underlying skill re-runs (or you paste a new version), Comma stores the new HTML as the next revision. Comments anchor across revisions. The model is "the report refreshed," not "someone edited a paragraph."
3. The agent is a first-class collaborator
Through Comma's MCP server, a Claude or Cursor agent can post reports, leave anchored comments, reply to threads, and mark them resolved — using the same primitives a human would, under one scoped token. Google Docs isn't built for this; Comma is.
Why HTML and not "documents"
The honest answer: because the artifacts that need a comment layer most right now are HTML, and the tools that exist for HTML are bad.
- Generated HTML is everywhere. Modern stack outputs HTML at every step.
- Rebuilding it as a "real document" loses the rendering. Charts, scripts, custom layout — they don't paste cleanly.
- The substitutes (Slack screenshots, email attachments, dashboard links) don't have a comment layer at all.
Comma starts at the HTML and leaves it alone. The comment layer is the new surface; the rendering stays sacred.
How teams use it
A few shapes that come up:
Analytics team sharing a weekly digest
Generate the HTML from the warehouse. Paste into Comma. PM and eng leads leave anchored comments on the rows that surprise them. Next week, the underlying skill re-runs as a routine; the new revision lands at the same URL; last week's resolved threads stay attached in history.
AI dev team reviewing eval results
The eval harness emits HTML. A daily routine posts the new revision. The
team leaves comments on regressions. The agent reads the comments via
list_comments on its next turn and adjusts.
Engineering team reviewing PR previews
A CI job posts the HTML preview of a feature to a Comma report. Designers and PMs leave anchored comments on the actual rendered UI — not on screenshots, not on Figma, on the real thing.
Anyone sharing a one-off report
Someone runs a one-off Python script that produces an HTML summary. Drag-drop into Comma. Share the link with the two people who care. They comment. Done. No infrastructure.
The intentional scope
Comma is not:
- A document editor. Use Google Docs.
- A dashboard builder. Use Looker / Mode / Hex.
- A notebook environment. Use Hex / Deepnote / Observable.
- A design tool. Use Figma.
- A wiki. Use Notion.
Comma is what those tools don't have: a comment layer for the HTML they produce.
Try it
Free tier is enough to feel the surface end-to-end: three commenters per report, full anchored commenting, monthly routines, full MCP access.