Comments are the asynchronous half of reviewing a page. They live in the document, anchored to the sentence or the block they are about, so a question travels with the paragraph it questions instead of arriving in a separate message that says “third paragraph, second sentence”. They are never published, and nobody reading your site will ever know they existed.
Leaving a comment
Hover a block and a small white pill appears at its right edge, holding three controls. The top one is Add comment.
What the comment attaches to depends on what you did before you clicked:
| What you do first | What the comment anchors to |
|---|---|
| Select some text, then click Add comment | Exactly that selection |
| Click Add comment with nothing selected | The whole block you were hovering |
Either way the anchor is part of the content, not a coordinate: edit the paragraph around it and the comment follows. The pill’s third control opens the AI writing assistant on the same target, and the whole pill — along with the move and drag affordances in the left gutter — is cataloged in block types and block settings.
The Comments rail
The right rail’s second tab holds every thread on the page, and every open suggestion, in one list. Clicking a card scrolls to its anchor and highlights it in the canvas; clicking the highlighted content in the canvas selects its card. With nothing on the page yet it reads “No comments or suggestions” over a reminder that is worth taking literally: “Your comments will be seen by anyone who can comment or view this document.”
Suggestion cards share this rail because they are the same kind of object from the reviewer’s point of view: something raised against a specific piece of content that somebody has to deal with. They are read differently, though, and suggesting mode and tracked changes covers the vocabulary on their cards and what Accept and Reject actually do.
Replying
A card is a thread. Reply appends to it; replies show their author and time in order under the original.
You can edit and delete your own comment, and your own replies, from the kebab menu on the card. Anyone with edit rights on the page can delete a comment — the same principle as an editable document. There is no version history on a comment: an edit replaces the text.
Reactions
The nine-emoji palette does two jobs, and they are worth separating because they look identical and behave differently.
An emoji comment is a comment whose body is an emoji. It comes from the middle button of the hover pill — Add emoji comment — and it anchors to your selection or the block exactly as a written comment does, raising its own card in the rail. Use it to mark a passage without composing a sentence about it. Emoji comments cannot be edited (there is nothing to edit), only deleted.
An emoji reaction goes on an existing card: a comment, a reply, or a suggestion. It shows a count, and hovering the count lists who reacted. Use it to agree with a comment instead of adding a reply that says “agreed”.
Both use the same nine, and each has a fixed meaning shown as its tooltip:
| Emoji | Meaning |
|---|---|
| 👍 | Yes / Agree |
| 👎 | No / Disagree |
| ❓ | Please elaborate |
| 👀 | Watching this / Needs attention |
| 🎉 | Nice / Celebrate |
| ✅ | Resolved / Looks good |
| ❤️ | Love this! |
| 🚀 | Ship it! / High-impact |
| 😂 | Hilarious! |
Note that ✅ Resolved / Looks good is an opinion, not an action — it does not resolve anything. The control that does is below.
Resolving and reopening
Resolve a thread when it has been dealt with: the blue tick on the card. The card leaves the working list and moves into a Resolved section at the bottom of the rail, stamped with the time it was resolved, and its anchor highlight comes off the canvas.
Resolved is not deleted. A resolved thread keeps its replies and its reactions, and its kebab menu offers two things: Re-open, which puts it back in the working list because it was not actually handled, and Delete, which removes it for good. Reactions are disabled on a resolved card — it is a record, not a conversation.
Suggestion cards land in the same Resolved section once they are accepted or rejected, but they cannot be re-opened; only comment threads can.
What comments are and are not
Three things are worth stating plainly, because each of them is a reasonable thing to assume wrongly.
They are part of the document, not a separate list. A comment is stored with the content it is anchored to, which is why it appears instantly for everyone with the page open, why it survives a publish and a revise, and why it moves when the text around it moves. Autosave, collaboration and locking covers that shared-document machinery; revisions, versions and reverting covers what a revert restores, which includes the document’s comments as they stood.
Overlapping comments
Leed does not allow two comment anchors to cover the same text. When you try to comment on a range that overlaps an existing thread, a Comment Overlap dialog appears rather than the two silently nesting:
Comments cannot overlap. You may expand the comment selection area or cancel.
Expand the existing comment widens the thread that is already there to cover your new selection and adds you to that conversation — usually the right answer, because a second thread over the same sentence splits the discussion. Cancel leaves everything alone; select a range that does not overlap and try again.
If the block already holds more than one comment there is nothing sensible to expand, and the dialog says so — “There are multiple existing comments in the block and comments may not overlap.” — with Cancel as the only option. Resolve one of the existing threads, or comment on a different part of the block.