Mia KwanAuthorDesign
Rich Editor
A rich editor is a text surface where formatting belongs to the text itself rather than being typed as markup: bold, headings, lists and quotes live in the document, and the toolbar reports what is under the cursor. Orvain's Rich Editor family holds six, a document page with its toolbar pinned above, a comment thread whose composer sits under the replies, a page whose formatting pill follows the selection, and three toolbars on their own: one pill carrying everything, a large-control row for touch, and a segmented pair that splits type settings from formatting.
Buttons are the small half of this component. The work is in the round trip: the toolbar has to re-read the selection on every cursor move, and a control that takes focus when pressed collapses the selection it was meant to act on, so the controls have to refuse focus rather than claim it. Paste is the other half. Text arriving from elsewhere carries styles your document has no rules for, and an editor without a paste filter slowly fills with fonts nobody chose.
Document editor
Best for
Docs, knowledge bases, long-form writing: a page with its toolbar on top
Anatomy
Toolbar on a grey band: text style, size, colour, B I U S, lists, checklist, align, mention, link, callout, ⋮ · headings, key caps, mention chips with a profile card · checklist · tip callout · pull quote · bottom bar with who is here, Saved, words and read time
People in this document: Cara, Noah and you
Saved0 words1 min readComment thread
Best for
Reviews and discussions where the reply matters most: read the thread, answer with full formatting
Anatomy
Header with title, count, people and ⋯ · comments with avatar, verified seal, presence, Author pill, role tag, time and mention chips · composer with a grey tray: B I U S, colour, lists, link, code, @ mentions, emoji, attach, Send · ⌘↵ hint and count
Design review
2 commentsCara BrookDesign
Floating toolbar
Best for
Distraction-free writing: formatting appears where you select, not at the top
Anatomy
Editable page with a pull quote · dark pill over the selection with a pointer, flips below when there is no room · Text ▾ (turn into) · B I U S, inline code · link, colour · Comment · / block menu on an empty line · footer with hints (⌥F10 to reach the bar) and N selected · N words
Select text to format/for blocks⌥F10to reach the bar0 words
Basic toolbar
Best for
The full formatting row as a pill: pin it above any editor
Anatomy
White pill above a short document it drives · font ▾ (each in its face) · size ▾ · colour (current colour in a ring, 12 dots, Default first) · B I U S · bulleted, numbered, checklist · align ▾ (shows the current alignment; a row of four) · mention, link (⌘K address box), callout · ⋮ · folds into ⋮ by priority as it narrows, never scrolls
Large toolbar
Best for
Touch and focus modes: big controls grouped in capsules above the task they drive
Anatomy
White pill of four grey capsules with 44px round buttons, on = white with a lift · font ▾ + size ▾ · colour orb (current colour, 12 dots, Default first) · B I U S · assignee avatar with presence dot (assign to, unassign) + attach (adds a file chip) · task with file chips and Assigned to … · whole groups wrap to a second row, nothing folds
Assigned to Cara Brook
Segmented toolbar
Best for
Two pills (type settings on the left, formatting on the right) for wide editors
Anatomy
Two white pills above a short document they drive · type pill: font ▾ · size ▾ · colour ▾ (current colour in a ring, 12 dots, Default first) · formatting pill: B I U S · bulleted, numbered, checklist · align ▾ (shows the current alignment) · mention, link (⌘K address box), callout · ⋮ · one toolbar, arrows across both pills · the pills wrap whole (type pill above) and the formatting pill folds into ⋮ by priority
01
Using Rich Editor
Reach for it when
- Long-form content read as a page: documentation, articles, release notes.
- Replies where a quote or an @mention changes what the sentence means.
- Authors who will never learn markup and should not have to.
- A writing surface meant to stay clean until the writer selects something.
Reach for something else when
- Text engineers will review in a diff. Markdown in a plain field stays readable in version control; rich output does not.
- A single line with no formatting, such as a title. Use a text input and keep its validation, placeholder and autofill.
- Content that must render identically in email or PDF. Restrict authors to a small named set of styles, or build it from a template.
02
Where it shows up
01
Knowledge base article
An internal handbook page where the author needs headings for structure, a checklist for the procedure and a quote for the caveat. Whatever a reader later searches for has to survive being pasted in from somewhere else.
02
Review thread
Comments on a document, where each reply can bold the term under discussion, quote the line it answers and tag whoever owns it. The composer stays inline under the thread rather than opening a modal.
03
Issue description
A task body written once and read many times: a summary, bulleted steps to reproduce, a link to the build. The formatting row sits underneath so the field opens on the text, not on its controls.
04
CMS body field
A marketing surface where a non-technical editor writes into a field the layout owns. The editor offers the marks the template renders and nothing more, so the page cannot be broken from inside the CMS.
03
Questions
When should I use a rich editor instead of a Markdown field?
Use rich editing when the author's job is writing rather than engineering, and when what they see while typing has to match what publishes. Use Markdown when the text is reviewed as source, versioned alongside code, or written by people who already know the syntax. The tell is the audience: content maintained by engineers ages better as plain text.
How should a rich editor handle pasted content?
Convert it into your own document model instead of accepting the incoming HTML as it arrives. Keep the marks your schema names (bold, links, headings, lists) and drop everything else, including inline fonts, colours and sizes inherited from whatever application the text came from. Offer a paste-as-plain-text shortcut too, because often the author wants only the words.
The Orvain DispatchPremium components,
Premium components,
free in your inbox.
Join the Orvain Dispatch and get production-ready components, free to keep: React and Vue code plus the Figma frame, yours to ship.
Just components, never spam. You can unsubscribe anytime.
Orvain MCPRich Editor
A rich editor is a text surface where formatting belongs to the text itself rather than being typed as markup: bold, headings, lists and quotes live in the document, and the toolbar reports what is under the cursor. Orvain's Rich Editor family holds six, a document page with its toolbar pinned above, a comment thread whose composer sits under the replies, a page whose formatting pill follows the selection, and three toolbars on their own: one pill carrying everything, a large-control row for touch, and a segmented pair that splits type settings from formatting.
Buttons are the small half of this component. The work is in the round trip: the toolbar has to re-read the selection on every cursor move, and a control that takes focus when pressed collapses the selection it was meant to act on, so the controls have to refuse focus rather than claim it. Paste is the other half. Text arriving from elsewhere carries styles your document has no rules for, and an editor without a paste filter slowly fills with fonts nobody chose.
Document editor
Best for
Docs, knowledge bases, long-form writing: a page with its toolbar on top
Anatomy
Toolbar on a grey band: text style, size, colour, B I U S, lists, checklist, align, mention, link, callout, ⋮ · headings, key caps, mention chips with a profile card · checklist · tip callout · pull quote · bottom bar with who is here, Saved, words and read time
People in this document: Cara, Noah and you
Saved0 words1 min readComment thread
Best for
Reviews and discussions where the reply matters most: read the thread, answer with full formatting
Anatomy
Header with title, count, people and ⋯ · comments with avatar, verified seal, presence, Author pill, role tag, time and mention chips · composer with a grey tray: B I U S, colour, lists, link, code, @ mentions, emoji, attach, Send · ⌘↵ hint and count
Design review
2 commentsMia KwanAuthorDesign
Cara BrookDesign
Floating toolbar
Best for
Distraction-free writing: formatting appears where you select, not at the top
Anatomy
Editable page with a pull quote · dark pill over the selection with a pointer, flips below when there is no room · Text ▾ (turn into) · B I U S, inline code · link, colour · Comment · / block menu on an empty line · footer with hints (⌥F10 to reach the bar) and N selected · N words
Select text to format/for blocks⌥F10to reach the bar0 words
Basic toolbar
Best for
The full formatting row as a pill: pin it above any editor
Anatomy
White pill above a short document it drives · font ▾ (each in its face) · size ▾ · colour (current colour in a ring, 12 dots, Default first) · B I U S · bulleted, numbered, checklist · align ▾ (shows the current alignment; a row of four) · mention, link (⌘K address box), callout · ⋮ · folds into ⋮ by priority as it narrows, never scrolls
Large toolbar
Best for
Touch and focus modes: big controls grouped in capsules above the task they drive
Anatomy
White pill of four grey capsules with 44px round buttons, on = white with a lift · font ▾ + size ▾ · colour orb (current colour, 12 dots, Default first) · B I U S · assignee avatar with presence dot (assign to, unassign) + attach (adds a file chip) · task with file chips and Assigned to … · whole groups wrap to a second row, nothing folds
Assigned to Cara Brook
Segmented toolbar
Best for
Two pills (type settings on the left, formatting on the right) for wide editors
Anatomy
Two white pills above a short document they drive · type pill: font ▾ · size ▾ · colour ▾ (current colour in a ring, 12 dots, Default first) · formatting pill: B I U S · bulleted, numbered, checklist · align ▾ (shows the current alignment) · mention, link (⌘K address box), callout · ⋮ · one toolbar, arrows across both pills · the pills wrap whole (type pill above) and the formatting pill folds into ⋮ by priority
01
Using Rich Editor
Reach for it when
- Long-form content read as a page: documentation, articles, release notes.
- Replies where a quote or an @mention changes what the sentence means.
- Authors who will never learn markup and should not have to.
- A writing surface meant to stay clean until the writer selects something.
Reach for something else when
- Text engineers will review in a diff. Markdown in a plain field stays readable in version control; rich output does not.
- A single line with no formatting, such as a title. Use a text input and keep its validation, placeholder and autofill.
- Content that must render identically in email or PDF. Restrict authors to a small named set of styles, or build it from a template.
02
Where it shows up
01
Knowledge base article
An internal handbook page where the author needs headings for structure, a checklist for the procedure and a quote for the caveat. Whatever a reader later searches for has to survive being pasted in from somewhere else.
02
Review thread
Comments on a document, where each reply can bold the term under discussion, quote the line it answers and tag whoever owns it. The composer stays inline under the thread rather than opening a modal.
03
Issue description
A task body written once and read many times: a summary, bulleted steps to reproduce, a link to the build. The formatting row sits underneath so the field opens on the text, not on its controls.
04
CMS body field
A marketing surface where a non-technical editor writes into a field the layout owns. The editor offers the marks the template renders and nothing more, so the page cannot be broken from inside the CMS.
03
Questions
When should I use a rich editor instead of a Markdown field?
Use rich editing when the author's job is writing rather than engineering, and when what they see while typing has to match what publishes. Use Markdown when the text is reviewed as source, versioned alongside code, or written by people who already know the syntax. The tell is the audience: content maintained by engineers ages better as plain text.
How should a rich editor handle pasted content?
Convert it into your own document model instead of accepting the incoming HTML as it arrives. Keep the marks your schema names (bold, links, headings, lists) and drop everything else, including inline fonts, colours and sizes inherited from whatever application the text came from. Offer a paste-as-plain-text shortcut too, because often the author wants only the words.
Related blocks
All blocksThe Orvain Dispatch
Premium components, free in your inbox.
Join the Orvain Dispatch and get production-ready components, free to keep: React and Vue code plus the Figma frame, yours to ship.
Just components, never spam. You can unsubscribe anytime.
