Inline comments — the kind anchored to a specific span of text in an article — used to be a rich-text-only feature in FinalDoc. If your project was in markdown mode, you could see existing comments in the side panel, but you couldn't add new ones via selection, and the highlights didn't render.
That gap is closed. Today's update brings four improvements:
- Inline comments work in markdown mode — select text, click the floating Comment button, type your comment, save
- Reply threading on inline comments — click Reply on any thread to start a nested conversation
- Cross-mode highlights — comments created in rich-text mode show up as yellow highlights in the markdown preview pane, and vice versa
- Text-based anchoring — comments survive switching editor modes and later edits, because they're anchored to the snippet of text, not to character offsets
Inline comments in markdown
The flow now mirrors rich-text exactly:
Select text in the markdown source
Pick at least 3 characters. The same selection you'd use for any other action.
Click the floating Comment button
A small purple "Comment" pill appears next to your selection — anchored above the highlighted text via the same mirror-div positioning we use for the markdown formatting toolbar.
The Inline panel opens with your form pre-filled
Selected text is shown in the form header. Type your comment. Press Enter or click the green check.
If you're more of a static-button person, the "Inline" pill in the editor's stats bar (next to Discuss and Task) also opens the panel and pre-fills the form when you have text selected.
Reply threading
Inline comments are now real threads, not just independent comments on the same span.
Click Reply under any top-level inline comment to add a reply. Replies render nested under their parent with a thinner border, an arrow indicator, and no quoted-text header (replies inherit their parent's anchor).
Replies are intentionally one level deep — you can't reply to a reply. To branch a discussion, post a new top-level comment on the same span. Resolution is per-thread: clicking Resolve on the parent collapses the whole conversation.
Why anchor by text, not by offset
Previously, inline comments stored two things: start and end character offsets in the article's text content, and the actual selected snippet. Highlights were rendered using the offsets.
That worked fine until either of two things happened:
- You switched editor modes. Rich-text HTML and markdown source produce different text content.
"Welcome"at offset 0 in rich-text became offset 3 in markdown (because"## Welcome"has the heading marks first). The comment ended up highlighting the wrong place — or worse, an empty range. - You edited the article. Insert a sentence near the top, and every comment after it now has stale offsets. Same wrong-position problem.
The new approach: search for the snippet, use offsets only as a tiebreaker. When rendering a comment's highlight, FinalDoc searches the current document for the comment's stored selectionText. If found, highlight there. If the snippet appears multiple times, pick the match closest to the original offset. If the snippet doesn't exist anymore (because the text was edited away), the comment becomes "orphaned" — still visible in the side panel, just no longer anchored to a span.
This is how Google Docs and Notion handle the same problem. It's robust against editor mode switches and normal article editing.
Cross-mode highlights
Open an article in markdown mode's split view. The source pane on the left stays plain text — markdown is meant to be readable as source. But the preview pane on the right now wraps each commented span in a yellow highlight, just like the rich-text editor.
Click any highlight in the preview to scroll the side panel to the matching comment. Hover to see the resolved/unresolved state. The same highlight rendering powers both editor modes from a single shared module.
The static panel button
The Inline button in the stats bar also got smarter. Previously, clicking it just opened the panel. Now, if you have text selected when you click it, the panel opens with your selection pre-filled in the add-comment form. Same data flow as the floating Comment pill — just a different entry point.
Try it
This is live for all plans starting today. Open any article (rich-text or markdown), select some text, and you'll see the floating Comment button. Add a comment, click Reply to thread, switch editor modes — comments and highlights follow you.
For full coverage including the Discuss tab, @mentions, and the audit log, see our existing comments article or check the docs at docs.finaldoc.io.