One dropdown at the right-hand end of the toolbar changes what your typing means. In Editing mode a keystroke changes the document. In Suggesting mode the same keystroke records a proposal that somebody — quite possibly you, ten minutes later — accepts or rejects. Nothing else about the editor changes: same toolbar, same shortcuts, same blocks.
The three modes
| Mode | What your typing does | When it is forced on you |
|---|---|---|
| Editing | Changes the document directly | — |
| Suggesting | Records every change as a proposal with an Accept / Reject card | — |
| Viewing | Nothing — the document is read-only | A published page; a page you have no edit rights to; the few seconds a publish is running |
The mode is yours, not the page’s. It lives in your browser, so two people in the same document can be in different modes at the same time — one drafting, one suggesting — and neither sees the other’s setting. Switching modes is instant and changes nothing that is already written.
One thing to expect when you pick Viewing deliberately: the toolbar disappears entirely, because a read-only document has nothing to format. The mode selector moves up to the first row of the document header, beside the Publish button, and you switch back from there.
stateDiagram-v2
direction LR
state "Editing" as Edit
state "Suggesting" as Suggest
state "Viewing (read-only)" as View
[*] --> Edit
Edit --> Suggest: you choose Suggesting
Suggest --> Edit: you choose Editing
Edit --> View: you choose Viewing
Suggest --> View: you choose Viewing
View --> Edit: you choose Editing
Edit --> View: page is published
Suggest --> View: page is published
Edit --> View: you have no edit rights
Suggest --> View: you have no edit rights
note right of View
Read-only is a destination you can be
PUT INTO, not just a mode you choose.
When it is forced, the dropdown is
disabled and shows why.
end note
When the dropdown is locked
The mode selector is disabled — not hidden — in two situations, and hovering it tells you which one you are in.
- A published page. The tooltip reads “Locked: Readonly”. A published revision is a permanent record of what readers saw, so it is never edited in place. Click Revise to start a new revision and the dropdown unlocks. Revisions, versions and reverting explains why the lock exists and what Revise costs you.
- No edit rights. The tooltip reads “View Only: No edit permissions”. You can read the page and follow the discussion; you cannot type, suggest or comment. Which roles land here is set out in roles and permissions.
If you chose Viewing yourself and you do have edit rights, the dropdown stays enabled — you are not trapped there.
What a suggestion looks like in the canvas
Insertions and deletions are marked inline, in the color assigned to whoever made them: added text is recolored, removed text is struck through and still visible. Nothing moves out of the flow, so the paragraph reads as both the old and the new version at once, which is the point.
A formatting change gets its own treatment — a dotted underline rather than the plain insertion color — because it is not new text at all. That distinction matters at the moment you press Reject: rejecting a formatting suggestion takes the bold off and keeps the words.
Every suggestion also raises a card in the Comments tab of the right rail, alongside comment threads. Clicking a card scrolls to and highlights its anchor in the canvas; clicking the marked text selects its card.
Reading the card
A card carries the author’s avatar and name, the time it was made, a short description of the change, any emoji reactions, and the two buttons that matter: Accept and Reject.
The description is the part worth learning, because it is how Leed tells you about changes that have no text to show you. For ordinary typing it quotes the text: Add: "the new wording" or Delete: "the old wording". For everything else it uses a short vocabulary of verb phrases that describe the change in words.
The full card vocabulary
| Card reads | What changed | What Reject does |
|---|---|---|
Add: "text" | Text was typed into an existing block | Removes the added text |
Delete: "text" | Text was removed from an existing block | Puts the text back |
Add: Code Block — "…" | A whole code block, alert or collapsible was added, with a preview of its content | Removes the block |
Add: Table · Add: Image · Add: Iframe · Add: Form · Add: Horizontal Rule · Add: YouTube Video · Add: Video · Add: Audio · Add: Icon · Add: Math · Add: Tab Group | A block with no useful text preview was added — the label stands alone | Removes the block |
Add format: bold (also italic, strikethrough, code, link, highlight, subscript, superscript, keystroke) | A mark was applied to text that already existed | Removes the mark and keeps the text |
Remove format: italic | A mark was cleared from existing text | Puts the mark back and keeps the text |
Wrap in blockquote | A block was wrapped in a container | Lifts the wrapper, leaving the contents in place |
Change to heading 2 · Change to paragraph · Change to code block | A block’s type was changed | Changes it back |
Split: paragraph | One block was split into two | Re-joins them |
Join: paragraph | Two blocks were merged | Splits them apart again |
Move: paragraph | A block was dragged, or moved with the up/down handles | Leaves the block where it started |
Edit image · Edit alert · Edit collapsible block | A block’s settings changed without its type changing — an image resize, an alert’s type, a collapsible’s default state | Restores the previous settings |
Mermaid diagrams and math blocks read as Mermaid Diagram and Math Block rather than Code Block, because that is what they are to you even though they share a node type.
Everything Suggesting can track
It is not only typing. Suggesting mode records — and rejection reverses — all of the following:
- Typing and deleting text
- Applying or clearing an inline mark on text that already existed
- Adding or deleting a whole block, including images, iframes, forms and other blocks that hold no text
- Wrapping a block in a blockquote or another container
- Changing a block’s type, including to and from headings and code blocks
- Splitting one block into two with
[[Enter]], and joining two with[[Backspace]] - Moving a block, by drag or with the up/down handles in the left hover gutter
- Changing a block’s settings through its gear dialog
The move case is the one that most often surprises people. Dragging a block in Suggesting mode does not actually move it: you get a struck-through copy where it started and a marked copy where you dropped it, under one suggestion. Accept lands the move; Reject leaves the block exactly where it was.
Accepting and rejecting
Accept applies the change and the marks disappear. Reject reverses it precisely — and “precisely” is doing real work in that sentence. Rejecting a formatting suggestion removes the mark and keeps the text rather than deleting the text that was bolded. Rejecting a wrap lifts the wrapper and keeps its contents. Rejecting a move leaves the original in place instead of deleting it. Every kind of change in the table above has an inverse, and Reject applies that inverse rather than a blanket delete.
Either way the card does not vanish. It moves down into a Resolved section at the bottom of the rail, stamped accepted or rejected with the time, where it stays until somebody deletes it from the card’s kebab menu. Resolved suggestions cannot be re-opened — that option exists for comment threads, not for suggestions.
Suggestions and everyone else
Suggestions live in the shared document, not in your browser. Everyone with the page open sees a suggestion the moment you make it, and anyone who can edit the page can accept or reject it — including the person who proposed it. Autosave, collaboration and locking covers how that sharing works underneath.
The suggestion markup never reaches your readers. When the page is serialized for your site, the marks are dropped and nothing is emitted for them — no strikethrough, no colors, no author names. What is emitted is the text.
How publishing works covers the rest of that pipeline, and fidelity and unsupported syntax covers what else changes between the editor and the file committed to your site.
Where suggestions come from besides people
Two more things land in this rail, and that is deliberate.
The editor’s own drafting widget puts its output here: press [[Ctrl]]+[[J]], describe what you want, and the result arrives as a tracked addition rather than replacing your text — see AI help in the editor. So does an edit made by your own AI client connected over MCP, which applies its changes as anchored suggestions attributed to it, live, while you keep typing; authoring pages over MCP covers that path.
That is the whole design: a machine can propose, and a human still decides. One limitation worth knowing if you drive Leed from an AI client — a block with no text in it at all, such as an image on its own line, cannot be tracked as a suggestion through the MCP op-set path, and an op-set touching one is rejected outright. In the editor itself, image and iframe blocks are trackable.
A review workflow that actually exists
Be clear-eyed about what Leed offers here, because the vocabulary invites an assumption it does not meet: there is no enforced approval step on a page. No status blocks a publish pending sign-off, no control marks a page approved, and no queue routes a page to a reviewer.
What exists is better than nothing and worth using deliberately:
- The reviewer opens the page and switches to Suggesting. Everything they write is a proposal.
- They leave comments for the things that are questions rather than edits.
- The owner works down the rail, accepting and rejecting, replying where a comment needs an answer.
- The owner publishes — which is its own privilege, so the ability to review is separate from the ability to ship.
That last point is the real control. Give reviewers write access and keep publish access narrow, and the “approval” is the fact that only certain people can press the button. Publishing and scheduling a page covers what that button does, and roles and permissions covers who has it.