DEV Community: ThomasNowHere

Adding Markdown to the Editor: Paste, Export, and What Gets Lost

ThomasNowHere — Fri, 10 Jul 2026 19:50:55 +0000

A surprising amount of the text people paste into a rich text editor is Markdown. It comes from ChatGPT answers, GitHub READMEs, Obsidian notes, Slack drafts. The structure is right there in the text: ## headings, - [ ] task lists, pipe tables. And most editors paste it as what it technically is, a wall of plain text with funny punctuation, leaving the user to rebuild by hand the structure they can already see.

@domternal/extension-markdown, new in 0.12.0, closes that gap in both directions. Markdown-looking pastes convert to real blocks, two commands and a headless API cover programmatic import, and the serializer turns any document back into GitHub-flavored Markdown, telling you exactly what could not survive the trip. Here's how it works, including the parts that are deliberately conservative.

A paste that knows when to do nothing

The dangerous part of Markdown paste isn't the conversion, it's the false positive. Nobody wants an editor that mangles a regular sentence because it happened to contain an asterisk. So the paste handler is built around refusal, and converts only when all of these hold:

The clipboard has no HTML flavor. A paste from Google Docs, a web page, or VS Code carries text/html, and ProseMirror's own HTML paste preserves more fidelity than any Markdown reparse could. Those pastes are never touched. This also means you can't demo the feature by copying rendered Markdown from a web page: it has to be plain text, which is exactly the point.
The text actually looks like Markdown. At least one block marker (#, >, a list marker, 1., a code fence, $$, a checkbox, a pipe-table row, a thematic break) or inline span (**bold**, `code`, ~~strike~~, a link or image) has to be present. Plain prose passes through untouched, and a bare URL is left alone so the Link extension's paste handling can turn it into a link, as before.
The selection isn't inside a code block. Pasting Markdown into a code block keeps it literal, because inside a code block, Markdown source is the content.

If the parser itself fails for any reason, the handler falls back to the default plain-text paste rather than letting anything escape. And when a paste does convert, one more detail matters: a single-paragraph paste like has **bold** inline inserts as inline content and merges into the text at the cursor, while multi-block Markdown replaces the selection as blocks. Either way it's one transaction, so undo restores the exact pre-paste document in a single step.

" width="800" height="450">

If you'd rather not have any of this, it's one option: Markdown.configure({ paste: false }).

Import as an API

The same parser backs two commands, for the cases where the Markdown comes from your code instead of the clipboard:

editor.commands.insertMarkdown('## Hello\n\n- [x] done\n- [ ] open');
editor.commands.setMarkdownContent('# Fresh document');

insertMarkdown parses and inserts at the selection with the same single-paragraph-merges-inline behavior as paste. setMarkdownContent replaces the whole document and passes its options through to setContent, so { emitUpdate: false } works the way you'd expect when you're loading content and don't want to trigger save logic.

An export that tells you what it lost

Serializing a rich document to Markdown is inherently lossy. An editor document can carry text alignment, colors, underline, merged table cells; Markdown can express none of those. There are two common ways to handle that, and I didn't like either: throw and refuse to export, or silently drop the formatting and let the user discover the damage later.

Domternal's serializer takes a third path. It always produces the best Markdown it can, keeps the content readable, and reports every fidelity loss through a warnings channel:

import { getMarkdown, downloadMarkdown } from '@domternal/extension-markdown';

const { markdown, warnings } = getMarkdown(editor);
// warnings: [{ code: 'unsupported-mark', message: 'Mark type "underline" ...', nodeType: 'underline' }]

downloadMarkdown(editor, 'notes.md'); // triggers a .md download, returns the same result

There are four warning codes: unsupported-node and unsupported-mark for content with no Markdown mapping, lossy-attribute for things like alignment or image resize dimensions, and lossy-structure for content that had to be flattened, like a toggle block becoming a bold summary paragraph followed by its content, or a mention becoming plain @label text. Warnings are deduplicated, so a document with forty underlined spans reports the underline loss once.

What you do with them is a product decision: show a toast, list them in an export dialog, or ignore them. The point is that the information exists, so "export to Markdown" never has to mean "find out next week what your document quietly dropped".

" width="760" height="428">

The GFM surface, and the round-trip promise

The serializer and parser cover the full Notion-style schema: headings, bullet and ordered lists (with start), GFM task lists, blockquotes, fenced code with a language (the fence grows when the code itself contains backticks), pipe tables with column alignment, images with alt and title, links and autolinks, bold, italic, strikethrough, inline code, hard breaks, horizontal rules, LaTeX math, and emoji.

For that supported subset, round trips are exact and covered by tests: serialize(parse(markdown)) reproduces the input, and parse(serialize(doc)) rebuilds an equal document. Exactness is what makes the feature trustworthy; "mostly the same after a round trip" is how documents rot.

My favorite small detail is the math currency guard. $...$ is the standard inline LaTeX delimiter, but it's also how people write prices. The inline rule refuses whitespace just inside the dollars and a digit right after the closing one, so price $5 and $10 total stays text while $e^{i\pi}+1=0$ becomes an equation. Escaping runs in the other direction too: text that merely looks like Markdown (|, $, <, entity-like & sequences) is escaped on export so it round-trips exactly, which also keeps the output well-behaved on renderers that allow raw HTML.

Headless, and schema-adaptive

Parsing and serialization don't need an editor instance:

import { parseMarkdown, serializeMarkdown } from '@domternal/extension-markdown';

const doc = parseMarkdown('# Title\n\nBody.', schema);
const { markdown, warnings } = serializeMarkdown(doc);

That runs in Node scripts, tests, or on a server, against any schema. And the parser adapts to whatever schema you give it: the handler set is derived from what the schema actually contains, so Markdown features without a counterpart degrade to readable text instead of failing. Paste a table into an editor without the Table extension and you get the rows as plain text, not an exception. ~~strike~~ without the Strike mark keeps its literal tildes.

Custom content plugs into the same machinery. A node serializer is a function that writes Markdown, a mark spec declares its delimiters:

Markdown.configure({
  specs: {
    nodes: {
      callout(state, node) {
        state.wrapBlock('> ', null, node, () => state.renderContent(node));
      },
    },
    marks: {
      kbd: { open: '`', close: '`', escape: false },
    },
  },
});

Without a mapping, a custom node flattens to its content with a warning. A custom node never breaks the export.

Setting it up

One package, no configuration required:

pnpm add @domternal/extension-markdown

import { Editor, StarterKit } from '@domternal/core';
import { Markdown, getMarkdown } from '@domternal/extension-markdown';

const editor = new Editor({
  element: document.querySelector('#editor'),
  extensions: [StarterKit, Markdown],
});

The same setup works through the React, Vue, Angular, and vanilla wrappers, and it composes with the Notion mode stack: the paste handler and SmartPaste divide the work cleanly, since SmartPaste ignores plain-text pastes and the Markdown heuristic rejects what isn't Markdown. There's a live playground on the docs page where you can round-trip a document both ways without installing anything.

Shipping in 0.12.0

@domternal/extension-markdown is new in 0.12.0, MIT licensed like everything else. The same release taught plugin views to dispatch transactions during editor construction and gave the framework wrappers a history: false option, groundwork for editors that bring their own undo. The full list is in the changelog.

Markdown documentation - options, commands, the warnings reference, headless usage, and the live playground
Live examples - the homepage editors now convert Markdown pastes too
GitHub - MIT licensed, issues and stars welcome

If you wire the warnings channel into an export UI, or feed the parser Markdown from somewhere I haven't thought of, I'd genuinely like to see it. Lossy conversions are only honest when someone is checking the loss report.

Building a Comment Box Found Four Bugs in My Editor

ThomasNowHere — Mon, 15 Jun 2026 08:47:34 +0000

I recently wrote the third tutorial for Domternal, my MIT-licensed ProseMirror editor: a comment box with @mentions in Vue. The core package alone runs 2,441 unit tests. There are four demo apps, one per supported framework, each with its own Playwright suite. I felt pretty good about coverage.

The comment box found four real bugs in one afternoon.

None of them were exotic. Every one had been sitting in shipped releases, invisible, because every test and every demo I had ever written shared one assumption the comment box didn't: that the editor is a big, tall document. A one-line composer is a different shape of consumer, and a different shape is exactly what coverage numbers can't measure. Here's what it caught.

Bug 1: The placeholder that wasn't there

The composer starts empty, so the first thing you should see is the placeholder prompt. Instead: nothing. Click into the editor: still nothing, because a click only dispatches a transaction when the selection actually changes, and in an empty document there is nowhere else for it to go. Type one character and delete it: there it is.

The placeholder is a ProseMirror decoration (presentational markup the editor layers over the document, recomputed from editor state rather than stored in it), and the plugin computing it had a guard that looked completely reasonable:

decorations: ({ doc, selection }) => {
  const editor = this.editor;
  if (!editor?.view) return DecorationSet.empty;
  const isEditable = editor.view.editable;
  // ...

The catch is when ProseMirror first asks for decorations: during the EditorView constructor, while it draws the initial document. At that moment editor.view is still unassigned, because the assignment only happens after the constructor returns. So the very first draw gets an empty decoration set, and since decorations are only recomputed on a state update, the placeholder stays invisible until the first transaction. The one-line repro that confirmed it:

editor.view.dispatch(editor.state.tr); // a no-op transaction, placeholder appears

Why did no test or demo ever catch this? Every demo seeds the editor with content, and every placeholder test called the decoration function manually, after construction, when the view exists. The fix was to make editor.isEditable safe before the view exists (it falls back to the configured option) and drop the view check from the plugin, plus a regression test that asserts [data-placeholder] is in the DOM immediately after new Editor(...), before anything else happens.

Bug 2: The popup that got clipped

Type @ in the composer and the mention popup opens, except it gets sliced off at the editor's bottom edge: two rows visible, the third cut mid-letter.

Domternal positions all floating UI (suggestion popups, bubble menus, popovers) position: absolute inside the editor wrapper. That's a deliberate architecture choice: during scrolling the popup moves with the content for free, on the compositor, with no JavaScript repositioning and no jitter. The theme also set overflow: hidden on that same wrapper, for rounded corners.

In a full-page document those two choices never meet: the popup opens next to the caret, well inside the box. In a composer the box is 80 pixels tall and the full six-person popup needs 190. Even filtered down to three people it measured 64 pixels past the editor's bottom edge. Clipped.

The fix moves the clipping one element down, onto the editor's content wrapper, so the document still crops at the rounded corners but floating UI can escape the box:

.dm-editor {
  /* overflow: hidden is gone from the wrapper itself */
}
.dm-editor > div:has(> .ProseMirror) {
  overflow: hidden;
  border-radius: inherit;
}

On released versions the tutorial documents the one-line workaround (overflow: visible on the composer's editor), which becomes a harmless no-op once this ships in 0.9.0.

Bug 3: The mouse that wouldn't let go

This one I only found because I record the tutorial demos with a scripted, human-like cursor. The script typed @ma, pressed ArrowDown to highlight the second person, and pressed Enter. The video showed the highlight never moving and Enter inserting the wrong person.

The same steps in a plain Playwright test passed. The difference between the two runs took a while to find: in the recording, the real mouse pointer was resting where it had last clicked, and the popup happened to open underneath it.

The suggestion list re-renders on every change, including the re-render that ArrowDown itself triggers. Rebuilding the item buttons under a stationary pointer makes the browser fire a synthetic mouseenter on whichever new element ends up under the cursor, with zero physical mouse movement. The renderer treated mouseenter as "the user is hovering this item" and moved the selection right back. Keyboard presses ArrowDown, re-render happens, phantom hover undoes it. Every time.

The fix is small and a classic of autocomplete UIs: select on mousemove instead of mouseenter. Real hovering always produces mousemove events; a DOM swap under a motionless pointer never does. The regression tests now assert that a synthetic mouseenter alone does not move the selection.

Bug 4: The calc() that ate my padding

The composer needed smaller padding than a document, and the theme exposes a custom property for exactly that. The theme used it like this:

.dm-editor .ProseMirror {
  padding: var(--dm-editor-padding);
  padding-top: calc(var(--dm-editor-padding) + var(--dm-editor-padding-top-extra, 0px));
}

Works beautifully until someone sets the variable to a two-value shorthand:

--dm-editor-padding: 4rem 4.8rem;

The padding line is fine. The padding-top line substitutes to calc(4rem 4.8rem + 0px), which is invalid. And here's the cruel part of the CSS spec: a declaration that becomes invalid at computed-value time doesn't fall back to the earlier padding declaration in the cascade. It computes to the property's default. padding-top: 0. Silently. No console warning, nothing in DevTools except a value you didn't set.

The punchline: all four of Domternal's own demo apps set exactly that two-value shorthand. Every demo had been rendering with zero top padding and nobody noticed, because a 4.8rem side padding makes a missing 4.5rem top padding look like a slightly snug design choice rather than a bug.

The fix adds a dedicated single-value variable with a fallback chain, so existing single-value users keep their behavior and shorthand users get a working knob:

padding-top: calc(var(--dm-editor-padding-top, var(--dm-editor-padding)) + var(--dm-editor-padding-top-extra, 0px));

What actually caught them

Not one of these four bugs was caught by adding more tests to the shapes I already had, because tests encode the consumer you imagined while writing them. All my imagined consumers were documents: tall, content-seeded, mouse-and-keyboard in the usual places. Every core test that existed at the time kept passing before, during, and after all four bugs.

What caught them was a new shape: an editor that is one line tall, starts empty, hijacks Enter, and gets driven by a recorded cursor that behaves like a human hand instead of a test runner. Placeholder-on-first-paint only matters when the editor starts empty. Popup clipping only matters when the editor is shorter than the popup. The hover bug only appears when a real pointer rests where a popup opens. The padding bug was visible all along, but only a composer made it look broken instead of stylistic.

The placeholder and hover fixes now ship with regression tests that fail on the old code, and the theme changes were run through the suggestion and Notion e2e suites of all four demo apps, so the shapes stay covered. But the general lesson stands: if your library has only ever been used the way you use it, you don't know how it behaves. Write the tutorial. Build the weird little composer. Your test suite will thank you, right after it embarrasses you.

All four fixes land in Domternal 0.9.0, the next release. If you want the comment box that started all this, the full walkthrough is in the Vue tutorial, and the editor itself is MIT-licensed on GitHub.

domternal / domternal

Modern, extensible rich text editor toolkit built on ProseMirror. Classic and Notion-style editors out of the box. Or go headless and assemble from 65+ tree-shakeable extensions. First-class wrappers for Angular, React, Vue, and Vanilla.

Domternal

A rich text editor toolkit built on ProseMirror, with a headless core and first-class Angular, React, Vue, and Vanilla components. Take the core alone and drive the DOM yourself, add the toolbar and theme for a finished editor, or mount the components for your framework. Notion-style block editing, drag handle, slash menu and floating outline included, and every package is tree-shakeable.

Website · Getting Started · Packages & Bundle Size

Live examples - full editors for Angular, React, Vue, and Vanilla, editable in the browser

Features

Headless core - use with any framework or vanilla JS/TS
Angular components - editor, toolbar, bubble menu, floating menu, emoji picker, notion color picker (Angular 17.1+, signals, OnPush, zoneless-ready)
React components - composable Domternal component, toolbar, bubble menu, floating menu, emoji picker, notion color picker, custom node views (React 18+)
Vue components - composable Domternal component, useEditor/useEditorState…

View on GitHub

Notion-Style Block Editor for Any Framework

ThomasNowHere — Thu, 04 Jun 2026 18:58:34 +0000

The "Notion experience" is a set of block-level interactions on top of a structured document: hover a block for a drag handle, grab it to reorder with a live drop line, press / for an insert menu, or "Turn into" to convert a heading into a to-do list. The hard part is shipping all of that headless, so the same block editor works in every framework instead of being locked to one.

Domternal takes a different route: the entire block layer is plain ProseMirror plugins, not framework components. The slash menu, hover handle, drag-to-reorder, "Turn into", block and inline colors, to-do nesting, toggles, and a scroll-spy table of contents are all headless and MIT licensed. They behave identically whether you mount the editor through the React, Angular, Vue, or Vanilla wrapper. And because each one is a separate extension, you load only the pieces you actually want.

What "block editing" actually is

Notion's magic isn't one feature. It's a handful of small interactions that all agree on the same idea: every paragraph, heading, list, and quote is a block you can summon, transform, recolor, and move without ever touching the keyboard's arrow keys if you don't want to.

In Domternal that's a few extensions working together. @domternal/extension-block-menu carries most of the interaction layer: the slash menu, the hover handle, drag-to-reorder, the block context menu ("Turn into", Duplicate, Copy link), keyboard reordering, and a smart paste that keeps block structure intact instead of flattening it to plain text. @domternal/extension-toc adds the scroll-spy outline and an inline /toc block, @domternal/extension-details adds collapsible toggles, and a few core pieces fill in the rest: BlockColor, the inline NotionColorPicker, UniqueID for stable block ids, and the to-do list nodes.

They're all just extensions. They register ProseMirror plugins and contribute items through the same addFloatingMenuItems() hook the core uses. Nothing in them knows or cares which framework renders the page.

The slash menu

Type / at the start of a line and a filtered popup of insertable blocks appears under the cursor. Keep typing to filter: /head narrows to the headings, /todo jumps to the to-do list. Arrow keys move the selection, Enter inserts, and the /query text you typed is deleted before the block lands so you never have to clean up after it.

import { SlashCommand } from '@domternal/extension-block-menu';

SlashCommand.configure({
  char: '/',                 // the trigger character, '/' by default
  invalidNodes: ['codeBlock'], // don't hijack '/' inside code
});

The list of items isn't hard-coded into the slash menu. It's collected from whatever extensions you loaded, so the menu grows automatically as you add features. Each item can declare a hideWhenInside rule too, which is how "Bullet list" politely disappears from the menu when your cursor is already inside one.

One detail that's pure Notion: the menu only opens when you actually type /. Pasting text that contains a slash, inserting it programmatically, undo/redo, or clicking next to a / that's already sitting there will not reopen it, so a dismissed slash just becomes plain text. Opening the menu also broadcasts a single "dismiss everything else" signal, so you never end up with two floating menus fighting over the same corner.

The block handle: hover, grab, add

Hover the left gutter next to any block and a handle fades in. It has two buttons: a six-dot grip and a plus.

The plus inserts an empty paragraph below and opens the insert menu, so adding a block is one click. The grip does two jobs depending on how you use it: click it to open the block's context menu, or drag it to move the block.

import { BlockHandle } from '@domternal/extension-block-menu';

BlockHandle.configure({
  nested: true,   // list items and task items get their own handles, Notion-style
  hideDelay: 200, // grace period so the handle doesn't vanish as you reach for it
});

That nested: true is worth a sentence. With it off, only top-level blocks are draggable. With it on, individual list items and task items resolve their own handles, so you can grab one bullet out of a list and drop it somewhere else, exactly like Notion.

The block context menu: Turn into, Duplicate, Copy link

Click the grip instead of dragging it and the block context menu opens. It's the BlockContextMenu extension, and it carries the actions you reach for most: Delete, Duplicate, Copy link, a Colors submenu, and a "Turn into" section.

Turn into converts the current block to another type. The defaults cover the blocks people actually convert between: Paragraph, Heading 1, Heading 2, Heading 3, Bullet list, Ordered list, To-do list, Quote, and Code block.

The menu is smart about what it offers. It hides the block type you're already in (converting a paragraph into a paragraph is a no-op), it hides list and quote targets when an ancestor is already that type, and it won't offer Quote inside a list item because the schema doesn't allow a blockquote there. You only ever see conversions that will actually work.

Duplicate copies the block with its content, marks, and attributes intact, and regenerates the block's unique id on the copy so deep links never collide. Delete removes it, and if you delete the last block in the document it drops in a fresh empty paragraph so the editor never ends up in an invalid empty state. Small things, but they're the difference between "feels finished" and "feels like a demo".

import { BlockContextMenu } from '@domternal/extension-block-menu';

BlockContextMenu.configure({
  copyLinkEnabled: true, // show "Copy link" (needs UniqueID for stable block ids)
  // turnIntoTargets: [...] to customize the "Turn into" list
});

Copy link writes a #block-id URL to your clipboard. It shows up only when UniqueID is loaded and the block actually has an id, and it pairs with the table of contents, which reads the URL hash on load and scrolls straight to that block. That's the full Notion "copy link to block" round-trip, headless.

Drag-to-reorder, and the drop line that gets nesting right

This is the part that took the most care. When you drag a block, a line follows the cursor to show where it will land. A flat reorder is easy. The interesting case is lists.

In Notion, where you drop horizontally decides the outcome. Drop a block lined up with the list and it becomes a sibling item. Drag it to the right, past the marker, and it becomes a nested child. Domternal mirrors that: the drop indicator is a solid line for a sibling drop and switches to a dashed, indented line once you cross a horizontal threshold into nested-child territory.

BlockHandle.configure({
  nested: true,
  nestThreshold: 28, // px from the list item's left edge before a drop nests
  autoScroll: true,  // scroll the page when you drag near the top or bottom edge
});

nestThreshold is the x-distance you have to cross before the drop commits to nesting. Set it to 0 and every drop stays a sibling. There's also an auto-scroll loop so dragging a block to the far end of a long document scrolls the page for you, with the speed ramping up the closer you get to the edge instead of lurching.

A drop in the gutter, or in the gap between two blocks, still lands on the nearest block instead of quietly doing nothing. And because the drop indicator and the actual drop are computed by the same function, the line never lies about where the block will end up.

Prefer the keyboard? KeyboardReorder moves the current block with Mod-Shift-ArrowUp and Mod-Shift-ArrowDown, reusing the exact same move logic as the drag path so the two never disagree.

A small detail that makes it feel right: Enter shouldn't open a menu

Early on, the insert menu popped up on every empty line. It sounds helpful. It isn't. In Notion, a blank line is just a blank line with a faint "Press '/' for commands" hint, and the menu only shows when you ask for it.

So the floating menu has an opt-in for exactly that behavior:

import { FloatingMenu } from '@domternal/extension-block-menu';

FloatingMenu.configure({
  requireExplicitTrigger: true, // menu only opens via the + button or by typing '/'
});

With that flag on, pressing Enter gives you a clean empty paragraph and nothing else. The menu is there the instant you click the plus or type a slash, and invisible the rest of the time. It's a tiny change that's the difference between "feels like Notion" and "feels like an editor pretending to be Notion".

Blocks that hold other blocks: to-dos and toggles

Some blocks aren't just one line: they hold other blocks. A list item or a to-do item is a label line plus a children zone underneath it: press Enter at the end of the label for a sibling, or add blocks below and they nest under that single bullet or checkbox, exactly like Notion's indented sub-content. The same paragraph block* model backs bullet lists, ordered lists, and to-do lists, so nesting behaves identically across all three. To-dos get the shortcuts you'd expect: [ ] and [x] start an unchecked or checked item, Mod-Enter ticks the current one, and Mod-Shift-9 toggles a to-do list.

The toggle is the other one: Notion's little triangle that collapses a block and everything tucked under it. It ships as @domternal/extension-details, built on the native <details> and <summary> elements so it's accessible and degrades to plain HTML, and it shows up in the slash menu as "Toggle block".

import { Details } from '@domternal/extension-details';

Details.configure({
  persist: true, // remember the open/closed state in the document
});

Toggles cooperate with the rest of the block layer too: convert into and out of them from the context menu, drag them around with their contents, and when you follow a table-of-contents link to a heading inside a collapsed toggle, the toggle opens itself so the heading is actually visible.

Color, inline and per-block

Notion has two kinds of color: a whole-block tint and an inline color on a run of text. Domternal ships both.

BlockColor tints an entire block's text or background from a fixed nine-color palette - gray, brown, orange, yellow, green, blue, purple, pink, red - wired into the block context menu's Colors section as text and background swatch rows plus a clear button.

import { BlockColor } from '@domternal/core';

editor.chain().focus().setBlockBgColor('blue').run();
editor.chain().focus().unsetBlockColors().run(); // clear text + background

For inline color there's NotionColorPicker, the swatch panel that drops into the selection (bubble) menu with nine text colors and nine backgrounds. The key design choice is that both store named tokens (data-text-color="red"), not raw hex. The theme maps each token to a CSS custom property with separate light and dark values, so the same saved document renders correct, readable colors in both themes without you storing theme-specific markup. And because color is "last action wins", tinting a whole block strips any conflicting inline color underneath it, so you never get unreadable text sitting on a colored block.

The scroll-spy outline

Long documents need a table of contents, and Notion's is the good kind: a column of ticks pinned to the side that expands into full headings on hover, with the tick for the section you're reading highlighted as you scroll.

@domternal/extension-toc is three extensions you opt into separately:

import {
  TableOfContents,    // collects headings, owns the active-id state
  FloatingTocOutline, // the hover-to-expand outline pinned to the side
  TableOfContentsBlock, // an inline /toc block you can drop in the doc
} from '@domternal/extension-toc';

The scroll-spy is the part I'm happiest with. It tracks the active heading with an IntersectionObserver, falls back to a throttled scroll calculation for the edges, and crucially it can follow a container's scroll, not just the window. That matters because a real app usually scrolls the editor inside a panel, not the whole page. Pass the scroll container and the outline tracks against it:

FloatingTocOutline.configure({
  anchor: 'editor',          // stick to the editor container, or 'viewport' for full-page
  activeScrollParent: panel, // the element that actually scrolls
});

Clicking a tick smooth-scrolls to that heading and updates the URL hash, and it ignores scroll updates for a moment afterward so the highlight lands where you clicked instead of flickering on the way there. Heading IDs come from the core UniqueID extension, so the outline reads stable ids it doesn't have to generate itself.

Those are two separate surfaces, by the way. FloatingTocOutline is the side rail; TableOfContentsBlock is an inline /toc block you drop into the document body from the slash menu, rendering the same live outline inline and sharing the rail's active-heading state (with a friendly placeholder until the document has headings). Both route through the same scrollToHeading, and because it writes the URL hash, a link you copied to a block will, on next load, scroll the reader straight to it.

Putting it together

A full Notion-style setup is just a list of extensions:

pnpm add @domternal/core @domternal/extension-block-menu @domternal/extension-toc @domternal/extension-details @domternal/theme

import {
  Editor, StarterKit, UniqueID, BlockColor,
} from '@domternal/core';
import {
  FloatingMenu, BlockHandle, BlockContextMenu,
  SlashCommand, KeyboardReorder, SmartPaste,
} from '@domternal/extension-block-menu';
import {
  TableOfContents, FloatingTocOutline, TableOfContentsBlock,
} from '@domternal/extension-toc';
import { Details } from '@domternal/extension-details';

const editor = new Editor({
  element: document.querySelector('#editor')!,
  extensions: [
    StarterKit,                                     // paragraphs, headings, lists, to-dos, history
    UniqueID,                                       // stable block ids for TOC + copy-link
    FloatingMenu.configure({ requireExplicitTrigger: true }),
    BlockHandle.configure({ nested: true }),
    BlockContextMenu,
    SlashCommand,
    KeyboardReorder,
    SmartPaste,
    BlockColor,
    Details,
    TableOfContents,
    FloatingTocOutline,
    TableOfContentsBlock,
  ],
  content: "<p>Press '/' for commands</p>",
});

That's the headless core. If you're in a framework, you wrap the same editor in @domternal/react, @domternal/angular, @domternal/vue, or @domternal/vanilla. The block layer doesn't change. The slash menu, the handles, the drop line, the block colors, the outline: all identical, because none of it lives in the framework layer.

And it stays small. Domternal's own code is about 44 KB gzipped (around 117 KB with ProseMirror itself), and because each feature is a separate extension your bundler strips whatever you don't import. Want the slash menu but not toggles? Leave Details out and it's gone from the bundle entirely.

Why a headless, framework-agnostic block editor

Three reasons, the same three that started the project. It's composable: every piece is its own extension, so you assemble the exact editor you want and your bundler drops the rest. It's framework-agnostic: the block layer is plain ProseMirror, so it behaves the same in React, Angular, Vue, and Vanilla, with no "the drag handle only works in React" footnote. It's MIT: block editing, drag-to-reorder, the outline, the color picker, and toggles are all free, with nothing behind a paid tier.

Try it

Notion Mode guide: domternal.dev/v1/guides/notion-mode

Website: domternal.dev

Getting started: domternal.dev/v1/getting-started

Packages & bundle size: domternal.dev/v1/packages

GitHub: github.com/domternal/domternal

The live editor on the homepage runs the full block setup, slash menu and handles included, so you can grab a paragraph and drag it around right now.

What's next

The block layer is broad and tested, but there's always more Notion to chase. The big one is arbitrary nesting. Today any block can be reordered, and list, to-do, and toggle blocks hold children, but you can't yet nest an arbitrary paragraph under another paragraph the way Notion does. The plan is to ship that as an opt-in package so the default editor keeps emitting clean semantic HTML and stays lightweight, and you only take on nesting's complexity when you actually want it. Columns and a synced-block style reference are the other obvious targets.

If you put this in front of a real document and something feels even slightly off compared to the editor you're used to, that's exactly the feedback I want.

What's the one block interaction you can't live without? Tell me in the comments and I'll see if it's already an extension away.

Making Domternal Accessible. What WCAG 2.1 AA Actually Looks Like in a Rich Text Editor.

ThomasNowHere — Tue, 14 Apr 2026 16:03:25 +0000

Updated September 5, 2026: this article documents the accessibility work shipped in Domternal v0.5.0. Domternal is now framework-agnostic, with first-party Angular, React, Vue 3 and Vanilla integration packages. The historical implementation and its 159 automated checks remain unchanged; current product facts and accessibility limitations have been clarified.

Rich text editors combine a contenteditable surface with toolbars, floating menus, dropdown panels, emoji pickers, table controls, autocomplete suggestions and popovers. Each part needs intentional semantics, keyboard behavior and focus management. In Domternal, that work crosses the editing core, framework integrations and theme rather than living in one component.

I built Domternal, a ProseMirror-based rich text editor toolkit with first-party Angular, React, Vue 3 and Vanilla integration packages. ProseMirror supplied part of the editor's basic keyboard behavior, but it did not automatically make the surrounding UI accessible. Before this pass, several menus, pickers and table controls lacked focus indicators, complete semantics or intentional keyboard paths. The emoji picker did not yet provide arrow-key grid handling.

This article describes the accessibility work included in Domternal v0.5.0. The work crossed 8 packages, and its validation set contained 159 automated E2E checks: 83 Angular and 76 React. Those checks verify DOM attributes, focus, keyboard and CSS behavior; they are not a manual screen-reader audit or a claim of formal WCAG conformance.

1. Editor semantics

ProseMirror renders a contenteditable div. By default, it has no ARIA attributes, so the accessibility tree exposes only a generic editable surface with no product-specific name, multiline state or read-only state.

I added four attributes to the editor element:

attributes: () => ({
  role: 'textbox',
  'aria-multiline': 'true',
  'aria-label': this.options.ariaLabel ?? 'Rich text editor',
  ...((this.options.editable ?? true) ? {} : { 'aria-readonly': 'true' }),
}),

This exposes a named multiline textbox in the accessibility tree. Exact speech and interaction behavior vary by browser, operating system, screen reader and user settings.

The aria-readonly attribute is dynamic. When someone calls editor.setEditable(false), the attribute appears; when the editor becomes editable again, it is removed. This makes the state available to assistive technology without recreating the editor element.

2. Focus indicators: `:focus-visible`, not `:focus`

This is a common mistake. Many editors use :focus for styling, which shows focus rings on mouse clicks too. You click a toolbar button and it gets an ugly blue ring. That's not helpful, it's visual noise.

:focus-visible follows browser heuristics and matches when the user agent determines that a focus indicator should be shown. For ordinary toolbar buttons, that typically preserves a visible ring during keyboard navigation without leaving the same ring after a pointer click.

I added :focus-visible indicators to 16 interactive element types across 9 SCSS files. The standard pattern:

&:focus-visible {
  outline: 2px solid var(--dm-accent, #2563eb);
  outline-offset: 1px;
}

This covers toolbar buttons, dropdown items, emoji picker tabs, emoji swatches, suggestion items, table handles, table cell toolbar buttons, table dropdown buttons, table alignment items, image popover buttons, link popover buttons, details toggle buttons, and mention suggestion items.

One exception: color swatches are circular, so a rectangular outline doesn't follow their shape. I used box-shadow instead to create a double ring that matches the swatch border radius:

.dm-color-swatch {
  &:focus-visible {
    box-shadow: 0 0 0 2px var(--dm-toolbar-bg, #f8f9fa),
                0 0 0 3px var(--dm-accent, #2563eb);
  }
}

The inner ring matches the toolbar background so it doesn't bleed into the swatch color, and the outer ring is the accent color.

3. Toolbar keyboard navigation

A toolbar without keyboard navigation is just a row of buttons you can Tab through one by one. That's technically keyboard-accessible, but it's a terrible experience when you have 20+ buttons. You'd press Tab 15 times just to reach "Insert Table".

The WAI-ARIA toolbar pattern solves this: one Tab stop for the entire toolbar, then Arrow keys to navigate between buttons.

Roving tabindex

The toolbar uses the roving tabindex pattern. Only the currently focused button has tabindex="0". All others have tabindex="-1". Pressing Tab moves focus out of the toolbar entirely. ArrowLeft/ArrowRight move between buttons. Home and End jump to the first and last button.

Dropdown navigation

When a toolbar button opens a dropdown, such as heading level or font size, the menu pattern takes over. The dropdown container gets role="menu", and each item gets role="menuitem".

ArrowDown from the trigger opens the dropdown and focuses the first item. ArrowDown/ArrowUp inside the dropdown cycles through items with wrapping, meaning ArrowDown on the last item goes back to the first. Escape closes the dropdown and returns focus to the trigger button.

4. Bubble menu ARIA

The bubble menu is the floating toolbar that appears when you select text. Without ARIA, its controls lack the group and state semantics assistive technology needs to identify the menu as a formatting toolbar.

I added role="toolbar" and aria-label="Text formatting" on the container. Each toggle button, such as bold, italic and underline, gets aria-pressed synced with the editor state, allowing assistive technology to expose whether the control is active. Separators between button groups use role="separator".

Both Angular and React implementations keep this in sync:

// React
<button aria-pressed={editor.isActive(item.name)} aria-label={item.label}>

// Angular
<button [attr.aria-pressed]="isItemActive(item)" [attr.aria-label]="item.label">

5. Emoji picker: 2D grid navigation

The emoji picker is a grid of hundreds of small buttons. Moving through that many controls one Tab press at a time is impractical, so the picker needs an intentional two-dimensional keyboard path.

Tab semantics and search

The category selector at the top exposes role="tablist", role="tab" and aria-selected on its category buttons. The search input has aria-label="Search emoji" because the placeholder alone is not a persistent accessible name. These roles and states were part of the v0.5.0 foundation; this pass did not claim the complete WAI-ARIA tabs keyboard interaction.

Grid keyboard navigation

Every emoji swatch has tabindex="-1", removing it from the Tab order. Once focus is placed on a swatch, the v0.5.0 handler moves through the 8-column grid as follows:

ArrowRight/ArrowLeft move horizontally, one emoji at a time
ArrowDown/ArrowUp jump by 8 to move vertically, one row at a time
Enter or Space selects the focused emoji

Navigation is bounded, not cyclic. ArrowLeft on the first emoji stays there. ArrowDown on the last row stays on the last row. The automated checks exercise this handler after placing focus on a swatch. They do not establish a complete keyboard handoff from the search or category controls into the grid, so this section should not be read as a claim of complete picker keyboard usability.

6. Table controls

Tables have the most complex UI in the editor: a cell toolbar with formatting buttons, row/column dropdowns with insert/delete/merge actions, a color palette for cell backgrounds, and an alignment picker. Each one needed the correct ARIA pattern.

The cell toolbar gets role="toolbar" with aria-label="Cell formatting". Row/column dropdowns use role="menu" with contextual labels such as "Row options" and "Column options". Every action button inside is role="menuitem". The color palette and alignment picker follow the same pattern. Separators between horizontal and vertical alignment options use role="separator".

7. Input labels

The text inputs covered by this pass have an explicit aria-label, so their purpose is available in the accessibility tree instead of relying on placeholder text.

Input	Label	State exposed to assistive technology
Link popover URL input	`"URL"`	Named URL text input
Image popover URL input	`"Image URL"`	Named image URL text input
Emoji picker search	`"Search emoji"`	Named search text input
Task item checkbox	`"Task status"`	Named checkbox with checked state

The floating menu also gets a default role="toolbar" and aria-label="Floating menu" if the user hasn't set one.

8. Autocomplete suggestions

Both the emoji :shortcode: autocomplete and the @mention autocomplete render suggestion dropdowns. These use the listbox pattern:

container.setAttribute('role', 'listbox');
container.setAttribute('aria-label', 'Emoji suggestions');

// Each suggestion item
btn.setAttribute('role', 'option');
btn.setAttribute('aria-selected', String(i === selectedIndex));

aria-selected tracks the currently highlighted item as you navigate with arrow keys, making the active option available to assistive technology.

9. Reduced motion

Some users have vestibular disorders or motion sensitivity. The prefers-reduced-motion media query lets them opt out of animations and transitions at the OS level.

I disabled the animations and transitions covered by this pass when this preference is set. This includes fade-in animations on floating elements, such as the emoji picker, suggestion dropdowns, toolbar panels and table controls, the gapcursor blink animation, and the theme's covered hover and focus transitions.

@media (prefers-reduced-motion: reduce) {
  .dm-emoji-picker,
  .dm-emoji-suggestion,
  .dm-toolbar-dropdown-panel,
  .dm-table-controls-dropdown,
  .dm-table-cell-toolbar {
    animation: none;
  }

  .dm-toolbar-button,
  .dm-emoji-swatch,
  .dm-color-swatch,
  /* ... and 20+ more selectors */ {
    transition: none;
  }
}

A CSS cascade lesson I learned the hard way: I initially placed this block in _base.scss, which is imported first in the stylesheet. But the toolbar's transition: background-color 0.15s in _toolbar.scss, imported later, overrode the transition: none. The fix was moving the entire prefers-reduced-motion block to the very end of index.scss, after all other imports, so it wins the cascade.

10. Selection collapse on blur

This is an accessibility and UX fix that's easy to overlook. When you select text in the editor and click outside, the browser's native selection highlight stays visible. This creates "ghost selections": the toolbar shows Bold and Italic as enabled for text that's no longer actively selected. If a user clicks Bold now, it would format text they didn't intend to format.

The SelectionDecoration extension, included in StarterKit and optional with selectionDecoration: false, collapses the ProseMirror selection to a cursor on blur. This keeps the visible selection and toolbar state aligned with editor focus. Assistive-technology behavior varies by browser and screen reader and is not established by these automated checks.

Testing

Accessibility behavior can regress during a refactor. I wrote 159 E2E checks: 83 Angular and 76 React, for the implemented DOM, focus, keyboard and CSS behavior. Each category runs against both framework demo apps via Playwright. These automated checks do not replace manual testing with assistive technologies:

Editor ARIA: role="textbox", aria-multiline, aria-label, contenteditable, absence of aria-readonly when editable
Dynamic aria-readonly: attribute appears when setEditable(false) is called, disappears when set back to true
Bubble menu ARIA: role="toolbar", aria-label, aria-pressed on toggle buttons synced with bold/italic state, role="separator"
Toolbar dropdown keyboard navigation: ArrowDown opens dropdown and focuses first item, ArrowDown/ArrowUp cycle through items, ArrowUp wraps from first to last, Escape closes and returns focus to trigger, role="menu" on panel, role="menuitem" and tabindex="-1" on items
Emoji picker ARIA: aria-label on search input, role="tablist" on container, role="tab" and aria-selected on category buttons, aria-label on each swatch, tabindex="-1" on all swatches
Emoji grid keyboard navigation: ArrowRight/Left/Down/Up movement, boundary behavior without wrapping, Enter and Space to select, same behavior in search results
Task checkbox: aria-label="Task status" on both checked and unchecked states
Link popover: aria-label on URL input, Apply and Remove buttons
Image popover: aria-label on URL input, Insert and Browse buttons
Table cell toolbar: role="toolbar" with aria-label when visible
Emoji suggestion: role="listbox" and aria-label on container, role="option" on items
Mention suggestion: role="listbox" and aria-label on container
:focus-visible indicators: keyboard focus shows outline, mouse click does not
prefers-reduced-motion: animations disabled with animationDuration: 0s, transitions disabled with transitionDuration: 0s

The prefers-reduced-motion tests use page.emulateMedia({ reducedMotion: 'reduce' }) to simulate the OS preference. The focus-visible tests verify both directions:

test('toolbar button shows outline on keyboard focus', async ({ page }) => {
  await page.keyboard.press('Tab');
  const btn = page.locator('.dm-toolbar-button').first();
  const outline = await btn.evaluate(el => getComputedStyle(el).outlineStyle);
  expect(outline).not.toBe('none');
});

test('toolbar button does not show outline on mouse click', async ({ page }) => {
  const btn = page.locator('.dm-toolbar-button').first();
  await btn.click();
  const outline = await btn.evaluate(el => getComputedStyle(el).outlineStyle);
  expect(outline).toBe('none');
});

What I skipped and why

Item	Reason
Skip navigation link	The editor is an embedded component, not a page. Skip links are for page-level navigation.
`@media (forced-colors)`	Outside this implementation pass.
Image alt text enforcement	Outside this implementation pass. The schema supports the `alt` attribute; the host application decides whether its authoring policy requires one.
`aria-live` regions	Outside this implementation pass. The editor provides data such as character and word counts, and the consuming app can expose selected updates through `role="status"` where appropriate.
Screen reader testing	Not part of these automated checks. VoiceOver, NVDA and other assistive technologies require a separate manual testing pass.

The result

Before v0.5.0, keyboard users could type in the content area, but several surrounding toolbars, menus, dropdowns, pickers and table controls lacked the intentional keyboard paths added in this pass.

After v0.5.0:

The interactive elements covered by this pass have a visible focus indicator on keyboard navigation, not on mouse click
The toolbar and dropdown paths are covered, and the emoji handler is verified once focus is placed on a swatch
The covered inputs, buttons and toggles expose accessible names
The covered dropdowns use the implemented WAI-ARIA menu pattern
The covered suggestion lists use the implemented listbox pattern
The covered theme surfaces suppress their documented animations and transitions when reduced motion is requested
The editor's read-only state is communicated to assistive technology
159 E2E checks verify the listed automated behavior across Angular and React; they do not establish screen-reader interoperability or WCAG conformance

Accessibility is not a one-time checkbox. It has to be part of how an editor is built, tested and reviewed.

Domternal Free is a framework-agnostic, MIT-licensed ProseMirror rich text editor with first-party Angular, React, Vue 3 and Vanilla integration packages. The current release includes 17 MIT packages, with 70+ extensions across core and 10 extension packages. For the maintained package inventory, command and test totals, and bundle measurements, see the package guide.

GitHub: github.com/domternal/domternal

Docs: domternal.dev

Live playground: domternal.dev/playground

Accessible authored content: Alt text and ARIA in editor content

I Built a First-Class Rich Text Editor for Angular

ThomasNowHere — Mon, 23 Mar 2026 21:10:36 +0000

Updated September 5, 2026: this article began as a Domternal v0.2.0 build log. Domternal is now framework-agnostic, with first-party Angular, React, Vue 3 and Vanilla JavaScript integrations. The Angular motivation remains the same, while obsolete package counts, bundle figures and roadmap claims have been updated. The v1 package table and Angular guide are the maintained sources for current details.

If you've ever tried to add a rich text editor to an Angular app, you know how it goes.

Many options can put an editor on the page quickly. The harder part begins when the editor has to behave like a real Angular dependency: predictable OnPush updates, standalone components, reactive forms, typed events, theme customization and UI that stays in sync with the editing state.

I kept reaching the same point in Angular projects: the editing engine worked, but the surrounding integration still needed application-specific glue. After years of rebuilding that layer, I decided to build the editor integration I wanted to use.

What I built

Domternal is a framework-agnostic rich text editor toolkit built on ProseMirror. Its core owns the document model, extensions and commands without depending on a component framework. The Angular package adds first-party components built with Signals, OnPush, standalone APIs and reactive forms support.

Domternal now ships as 17 MIT-licensed npm packages under the @domternal scope. First-party Angular, React, Vue 3 and Vanilla JavaScript integrations all use the same core. Angular is a first-class integration, not the only framework Domternal supports.

The Angular experience I wanted

The problem was not that every alternative was bad. Different editors optimize for different constraints. Some begin with a framework-neutral JavaScript engine and add Angular bindings. Others rely on community-maintained wrappers, while commercial suites package features and licensing in different ways.

I needed a particular combination:

standalone Angular components with Signals and OnPush
ControlValueAccessor support for ngModel and reactive forms
extension-driven toolbars and menus that track editor state automatically
normal theme customization without application-specific editor overrides
a typed ProseMirror foundation that also works outside Angular
a complete Free editor that remains independently available under MIT

That combination became Domternal. The Free edition is a complete MIT-licensed editor, not a time-limited trial. Domternal Pro is a separate commercial, self-hosted layer for collaboration, comments, version history, columns, AI-assisted workflows and document export.

If you are evaluating alternatives today, the maintained Tiptap vs Domternal comparison and CKEditor vs Domternal comparison separate editor capabilities, framework integrations, hosting models and licensing without treating unlike plans as equivalent.

What makes Domternal different

6 Angular components: editor, toolbar, bubble menu, floating menu, emoji picker and Notion color picker. All use Signals, OnPush and standalone components. No NgModules are required.

Tables are free. Cell merge/split, column resize, cell styling and the cell toolbar are included in Domternal Free, with 18 table commands published under MIT.

The toolbar is extension-driven. Extensions that contribute toolbar items are discovered automatically, so their controls appear with active and disabled states without repeated button wiring in the application.

70+ extensions across core and 10 extension packages: headings, lists, code blocks with syntax highlighting, images, emoji, details, text color, font size, math, Markdown, block controls and more. Core, the four integrations, the theme and those extension packages make 17 current MIT packages in total.

JavaScript exports are tree-shakeable. The full Domternal-owned core entry is about 51 KiB minified and gzipped before ProseMirror and helper dependencies, while the current complete core bundle is about 132 KiB with those runtime dependencies. Additional extensions such as tables, images and emoji are separate packages. Actual output depends on your imports, configuration and bundler; the theme is delivered as a complete CSS stylesheet. See the maintained bundle size breakdown.

17,000+ automated test executions across unit coverage and a browser matrix for Angular, React, Vue and Vanilla. The exact current breakdown belongs in the repository and maintained documentation rather than in this historical article.

Light and dark themes with 150+ CSS custom properties. Applications can change color, spacing and typography without forking the editor styles.

TypeScript APIs. Public extensions and commands expose typed APIs and command inference without making this article a permanent claim about every internal implementation detail.

Schema conflict detection: if you accidentally register two extensions with the same name, which can happen when using StarterKit alongside individual extensions, Domternal throws a clear error instead of silently letting the last one win.

Free and Pro today

Everything described above belongs to Domternal Free unless explicitly stated otherwise. All 17 currently published packages under the @domternal scope are MIT licensed.

Domternal Pro is a separate, optional set of commercially licensed packages under the @domternal-pro scope. It adds real-time collaboration, comments, version history, columns, AI-assisted workflows and local Word/PDF export. The Pro packages run with infrastructure selected by the application and do not require a Domternal-hosted editing service.

Quick setup

Here's a minimal Angular example:

pnpm add @domternal/core @domternal/angular @domternal/theme

import { Component, signal } from '@angular/core';
import {
  DomternalEditorComponent,
  DomternalToolbarComponent,
} from '@domternal/angular';
import { Editor, StarterKit } from '@domternal/core';

@Component({
  selector: 'app-editor',
  imports: [DomternalEditorComponent, DomternalToolbarComponent],
  template: `
    @if (editor(); as ed) {
      <domternal-toolbar [editor]="ed" />
    }
    <domternal-editor
      [extensions]="extensions"
      [content]="content"
      (editorCreated)="editor.set($event)"
    />
  `
})
export class EditorComponent {
  editor = signal<Editor | null>(null);
  extensions = [StarterKit];
  content = '<p>Hello world</p>';
}

Add the theme import to your styles and you're done:

@use '@domternal/theme';

See the full Angular example with all extensions, toolbar and bubble menu, or read the Getting Started guide.

No framework? No problem.

The core is fully headless and works without any framework:

pnpm add @domternal/core

import {
  Editor, Document, Text, Paragraph,
  Bold, Italic, Underline,
} from '@domternal/core';

const editor = new Editor({
  element: document.getElementById('editor')!,
  extensions: [Document, Text, Paragraph, Bold, Italic, Underline],
  content: '<p>Hello <strong>Bold</strong>, <em>Italic</em> and <u>Underline</u>!</p>',
});

Import the extensions you need for direct control, or use StarterKit for a batteries-included setup with headings, lists, code blocks, history and more. Your final JavaScript output depends on the imports and bundler configuration you choose.

See the full Vanilla TS example with toolbar, bubble menu and all extensions, or read the Getting Started guide.

Domternal Free today

	Domternal Free
Framework integrations	Angular, React, Vue 3 and Vanilla JavaScript
Angular components	6: editor, toolbar, bubble menu, floating menu, emoji picker and Notion color picker
Current MIT packages	17
Extensions	70+ across core and 10 extension packages
Nodes	27
Marks	9
Commands	130+ chainable commands
Tests	17,000+ automated test executions across maintained suites
Domternal-owned core surface	~51 KiB minified and gzipped before dependencies
Full core with current dependencies	~132 KiB minified and gzipped
Tree-shaking	Actual output depends on imports, configuration and bundler behavior
TypeScript	Typed public extension and command APIs
Table commands	18
License	MIT

Try it now

Website: domternal.dev

Angular guide: domternal.dev/v1/guides/angular

Getting started: domternal.dev/v1/getting-started

Packages and bundle size: domternal.dev/v1/packages

GitHub: github.com/domternal/domternal

Live playground: domternal.dev/playground

Since the original v0.2.0 article

React and Vue integrations, math, drag handles, block controls and other features that were once described as future work now exist in the maintained v1 documentation. Future requests can inform product planning, but neither this historical post nor a request is a delivery commitment.

The complete Free editor remains MIT licensed. The optional Domternal Pro packages now add collaboration, comments, version history, columns, AI-assisted workflows and Word/PDF export for teams that need those workflows while retaining control of their application infrastructure.

The current release status, supported packages and installation instructions are published in the v1 documentation. I would still appreciate feedback on the API design, documentation or anything that could be better.

What's been your biggest pain point with rich text editing in Angular? I'd love to hear about it in the comments.

DEV Community: ThomasNowHere

Adding Markdown to the Editor: Paste, Export, and What Gets Lost

A paste that knows when to do nothing

Import as an API

An export that tells you what it lost

The GFM surface, and the round-trip promise

Headless, and schema-adaptive

Setting it up

Shipping in 0.12.0

Building a Comment Box Found Four Bugs in My Editor

Bug 1: The placeholder that wasn't there

Bug 2: The popup that got clipped

Bug 3: The mouse that wouldn't let go

Bug 4: The calc() that ate my padding

What actually caught them

domternal / domternal

Modern, extensible rich text editor toolkit built on ProseMirror. Classic and Notion-style editors out of the box. Or go headless and assemble from 65+ tree-shakeable extensions. First-class wrappers for Angular, React, Vue, and Vanilla.

Domternal

Features

Notion-Style Block Editor for Any Framework

What "block editing" actually is

The slash menu

The block handle: hover, grab, add

The block context menu: Turn into, Duplicate, Copy link

Drag-to-reorder, and the drop line that gets nesting right

A small detail that makes it feel right: Enter shouldn't open a menu

Blocks that hold other blocks: to-dos and toggles

Color, inline and per-block

The scroll-spy outline

Putting it together

Why a headless, framework-agnostic block editor

Try it

What's next

Making Domternal Accessible. What WCAG 2.1 AA Actually Looks Like in a Rich Text Editor.

1. Editor semantics

2. Focus indicators: :focus-visible, not :focus

3. Toolbar keyboard navigation

Roving tabindex

Dropdown navigation

4. Bubble menu ARIA

5. Emoji picker: 2D grid navigation

Tab semantics and search

Grid keyboard navigation

6. Table controls

7. Input labels

8. Autocomplete suggestions

9. Reduced motion

10. Selection collapse on blur

Testing

What I skipped and why

The result

I Built a First-Class Rich Text Editor for Angular

What I built

The Angular experience I wanted

What makes Domternal different

Free and Pro today

Quick setup

No framework? No problem.

Domternal Free today

Try it now

Since the original v0.2.0 article

2. Focus indicators: `:focus-visible`, not `:focus`