Can I leave a comment on an HTML report?

Yes — if the report lives inside a tool that supports anchored comments. Most don't. Comma renders the HTML inside a sandboxed iframe and overlays a comment layer outside it, so reviewers can select a paragraph or a table cell and pin a thread to that exact selection.

How does the comment stay attached when the HTML refreshes?

Anchored comments persist across revisions of the same report. Comma tracks the selected text and reattaches the thread to the same content in the next revision — even when the surrounding HTML has changed.

Can an AI agent leave comments?

Yes. Comma's MCP server exposes `add_comment`, `reply_to_comment`, and `set_comment_status` as typed tools. An agent in Claude Code or Cursor can pin a comment, reply to an existing thread, or mark a thread resolved — all under one scoped token.

Does the commenter need an account?

No. Comma is link-first. Anyone with the share link gets their own identity and can leave anchored comments. Free tier supports up to three commenters per report.

How to leave anchored comments on an HTML report

You can comment on a Google Doc. You can comment on a Figma file. You can comment on a PR. For some reason, you can't easily comment on an HTML report.

That's a real gap. This page is the answer to it.

What "anchored" means

A comment is anchored when it pins to a specific selection inside the artifact — not to "the report," but to "the second paragraph" or "the row with the 8% drop." Click the comment in the sidebar, the surface scrolls to the anchor. Edit the surrounding content, the comment stays attached to the same selection.

It's the model Google Docs uses. Comma applies it to HTML.

Why this is hard for HTML

HTML is rendered. By the time the team sees it, it's a tree of DOM nodes inside a browser — there's no obvious "comment surface." Two structural problems make anchoring HTML comments hard:

The HTML may contain scripts and custom layout. If you inject a comment widget into the document, you can break the rendering.
The HTML often changes between revisions. A row shifts position; a chart is regenerated; a paragraph is rewritten. A naïve "anchor by DOM path" approach breaks immediately.

Most tools that claim "comment on HTML" either solve only one of these, or solve both badly. Comma solves both deliberately.

How Comma does it

Two structural decisions:

1. Comments live outside the iframe

The report HTML renders inside an opaque-origin sandbox iframe. The comment layer renders in the parent page, around the iframe. Comments are overlaid visually on top of the rendering, but no comment code touches the HTML itself.

This means:

Rendering is faithful. Scripts, styles, and layout in the source HTML run exactly as written.
The sandbox is sandboxed. The HTML can't reach into the user's Comma account or read comment data; comment code can't break the rendering.

2. Anchors are text-based, not DOM-based

A comment anchor is a text selection — the exact characters the reviewer highlighted. When the HTML refreshes (via a routine or a manual update), Comma reattaches the comment by finding the same text in the new revision. Surrounding HTML can change; the comment finds its home.

This means:

Comments persist across refreshes. Last week's open thread on the funnel table is still there next week, attached to the same row.
Comments survive light edits. The comment doesn't snap off because a sibling div was reordered.
Comments degrade gracefully. If the anchored text disappears entirely in a future revision, the comment marks itself as "anchor lost" rather than silently floating into the wrong place.

What you can comment on

Anchored comments work on anything that has text:

A paragraph in an executive summary. Highlight the sentence, pin the thread.
A table cell. Click into the cell, leave a comment about the number.
A chart caption. Highlight the caption text, ask the question.
A code block. Anchor to a specific line.
A header. Useful for "this whole section needs work."

What doesn't work yet: anchoring to a chart's visual element directly (the pixels). Those comments need to anchor to the surrounding caption or table.

How an agent leaves comments

Comma's MCP server exposes the comment primitives as typed tools. From Claude Code or Cursor:

add_comment(
  report_id: "rpt_…",
  anchor_text: "Q3 conversion dropped 8% week-over-week",
  body: "The drop coincides with the pricing test rollout — see PR #482",
)

reply_to_comment(
  thread_id: "thr_…",
  body: "Confirmed — rolled back the test, expecting recovery by Friday",
)

set_comment_status(
  thread_id: "thr_…",
  status: "resolved",
)

The agent's comments are first-class — humans see them like any other reviewer's, including which comma_sk_… token authored them.

How the loop closes

The Google-Docs-shaped review pattern, applied to HTML:

You publish. Either by hand (paste, upload) or via an agent (create_report over MCP).
Reviewers comment. Anchored to the specific text they care about.
You (or the agent) read the comments. Via the UI, the REST API, or list_comments over MCP.
You respond. Edit the HTML (and post a new revision) or reply to the thread directly.
Threads resolve. Marked resolved when addressed. Resolved threads stay attached in revision history.

For an agent-driven loop, this is the cycle that closes the feedback gap most teams give up on.

What about resolving / @ mentions / notifications

All standard:

Resolve / reopen. Per-thread, by anyone with comment access.
@ mentions. Type @ to surface teammates from the workspace. Mentions trigger an email.
Notifications. New comments, replies, and resolutions email participants. Configurable in Settings → Notifications.

Try it

Free tier supports up to three commenters per report. Paste any HTML, send the link to a teammate, ask them to leave one comment.

Create your first report →