DEV Community: ThomasNowHere

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

Rich text editors are one of the hardest UI components to make accessible. A contenteditable element, custom toolbars, floating menus, dropdown panels, emoji pickers, table controls, autocomplete suggestions, popovers. Each one needs proper ARIA semantics, keyboard navigation, and focus management. Most of them are built with imperative DOM manipulation, not framework templates.

I built Domternal, a ProseMirror-based rich text editor toolkit with Angular and React wrappers. The core editing was keyboard-accessible from the start, because ProseMirror handles that. But everything around it (toolbars, menus, dropdowns, pickers, table controls) was mouse-only. No focus indicators. No ARIA roles. No keyboard navigation in dropdowns. The emoji picker was completely unreachable with a keyboard.

This is what it took to fix all of it. Changes touched 8 packages, 24 files, backed by 159 E2E tests.

1. Editor semantics

ProseMirror renders a contenteditable div. By default, it has no ARIA attributes. A screen reader user lands on it and hears something like "editable text" with no context: what kind of input is this? Is it a single-line field or a multiline editor? Does it have a label?

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' }),
}),

Now a screen reader announces: "Rich text editor, editable text". The user immediately knows what they're interacting with.

The aria-readonly attribute is dynamic. When someone calls editor.setEditable(false), the attribute appears and screen readers announce the state change. When set back to true, it's removed. No need to re-read the entire 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 only triggers when the browser detects keyboard navigation, not mouse clicks. This is what you want: a visible ring when someone is Tabbing through the UI, invisible when they're clicking.

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 (like heading level or font size), the menu pattern takes over. The dropdown container gets role="menu", 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, a screen reader just sees a bunch of unlabeled buttons floating in the DOM.

I added role="toolbar" and aria-label="Text formatting" on the container. Each toggle button (bold, italic, underline) gets aria-pressed synced with the editor state. When the selected text is bold, aria-pressed="true" tells screen readers "Bold, toggle button, pressed". When it's not, "Bold, toggle button, not pressed". 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. Without keyboard navigation, it's completely unusable without a mouse. You can't Tab through 500+ emoji one by one.

Tab semantics and search

The category selector at the top uses role="tablist" with role="tab" and aria-selected on each category button. The search input has aria-label="Search emoji" because the placeholder alone is not sufficient: placeholders disappear when you start typing, and some screen readers don't announce them.

Grid keyboard navigation

Every emoji swatch has tabindex="-1", removing it from the Tab order. Instead, arrow keys handle navigation on the grid container. The grid has 8 columns, so:

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. This is intentional for a 2D grid, where wrapping would be disorienting.

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 ("Row options", "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

Every text input across the editor has an explicit aria-label. These seem small, but without them, a screen reader user hears "edit text" with no indication of what the input is for.

Input	Label	What a screen reader says
Link popover URL input	`"URL"`	"URL, edit text"
Image popover URL input	`"Image URL"`	"Image URL, edit text"
Emoji picker search	`"Search emoji"`	"Search emoji, edit text"
Task item checkbox	`"Task status"`	"Task status, checkbox, not checked"

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, so screen readers announce which option is active: "Thumbs up, option 3 of 5".

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 all animations and transitions when this preference is set. This covers fade-in animations on floating elements (emoji picker, suggestion dropdowns, toolbar panels, table controls), the gapcursor blink animation, and all hover/focus transition effects on every interactive element.

@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, opt-out with selectionDecoration: false) collapses the ProseMirror selection to a cursor on blur. Toolbar buttons correctly show as disabled, no stale formatting can happen, and screen readers don't announce a stale selection range.

Testing

Accessibility without tests is just accessibility until the next refactor. I wrote 159 E2E tests (83 Angular + 76 React) covering every change. Each category runs against both framework demo apps via Playwright:

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" + tabindex="-1" on items
Emoji picker ARIA: aria-label on search input, role="tablist" on container, role="tab" + 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 (no 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" + aria-label on container, role="option" on items
Mention suggestion: role="listbox" + aria-label on container
:focus-visible indicators: keyboard focus shows outline, mouse click does not
prefers-reduced-motion: animations disabled (animationDuration: 0s), transitions disabled (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)`	Nice to have but not required for WCAG 2.1 AA. On the roadmap.
Image alt text enforcement	Content authoring policy, not editor responsibility. The `alt` attribute is fully supported.
`aria-live` regions	The editor provides data (character count, word count). The consuming app can add `role="status"` where needed.
Screen reader testing	Manual testing with VoiceOver/NVDA. Requires a separate testing pass, not a code change.

The result

Before v0.5.0, the editor worked for mouse users. Keyboard users could type in the content area, but toolbars, menus, dropdowns, pickers, and table controls were all mouse-only.

After v0.5.0:

Every interactive element has a visible focus indicator on keyboard navigation (not on mouse click)
Every toolbar, menu, and picker is fully navigable with arrow keys
Every input, button, and toggle has an accessible name
Every dropdown uses the correct WAI-ARIA menu pattern
Every suggestion list uses the correct listbox pattern
Motion-sensitive users see no animations or transitions
The editor's read-only state is communicated to assistive technology
159 E2E tests verify all of it across both Angular and React

Accessibility is not a feature you install. It's how the editor works by default.

Domternal is an open-source ProseMirror-based rich text editor with native Angular and React wrappers. 57 extensions, 140+ commands, ~38 KB gzipped, fully tree-shakeable, MIT licensed.

GitHub: github.com/domternal/domternal

Docs: domternal.dev

StackBlitz: Angular | React | Vanilla TS

Angular Deserves Better Than React Editor Wrappers. So I Built One.

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

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

You find a library. It's a wrapper around a React-first editor. You install it, import some module, and it kind of works. Then you need tables. That's a paid feature. You need it to work with OnPush change detection. It doesn't. You try ::ng-deep to fix the styling. It works until it doesn't. You check the GitHub issues and the Angular wrapper hasn't been updated in months.

I've been through this cycle on every Angular project I've worked on. After years of dealing with it, I finally built the thing I kept wishing existed.

What I built

Domternal is a headless rich text editor with native Angular components. Not a thin wrapper around a React-first editor. A purpose-built editor engine on top of ProseMirror, with native Angular components from the ground up. Signals, OnPush, standalone architecture, and reactive forms out of the box.

It ships as 10 npm packages under the @domternal scope. The core is framework-agnostic and fully headless, so it works without Angular too. React and Vue wrappers are planned.

Why the existing options didn't work

I looked at everything out there. Here's what I found:

Community wrappers (ngx-tiptap, ngx-quill) are thin bindings around libraries built for other frameworks. They don't use Angular's change detection properly, they require ViewEncapsulation.None hacks for styling, and features that depend on framework-specific renderers simply don't work in Angular.

Existing Angular editors (like ngx-editor) are solid ProseMirror-based options for simpler use cases, but they weren't designed for the level of extensibility and Angular integration I needed: Signals-driven reactivity, auto-rendering toolbars, and a large extension ecosystem.

Commercial editors (CKEditor, TinyMCE, Kendo UI) either wrap framework-agnostic JavaScript with Angular bindings, or require expensive licenses and buying entire UI suites just to get a text editor. The pricing adds up fast, especially for small teams and startups.

Meanwhile, React developers have TipTap (35K+ stars), Plate, BlockNote, Lexical, and Remirror, all free, well-maintained, and community-driven. Angular developers have been making do with workarounds for years.

What makes Domternal different

5 Angular components: editor, toolbar, bubble menu, floating menu (in progress), and emoji picker. All built with Signals, OnPush, and standalone components. No NgModules, no ::ng-deep, no fighting the framework.

Tables are free. Cell merge/split, column resize, cell styling, cell toolbar: 18 table commands total, all MIT licensed. These are features that other editors commonly put behind paid tiers.

The toolbar auto-renders based on your extensions. You add an extension, the corresponding toolbar button appears. No manual wiring, no configuration files. It just works.

57 extensions across 10 packages: headings, lists, code blocks with syntax highlighting, images (paste/drop upload), emoji with picker and suggestions, accordion/details, text color, font size, and more.

Lightweight and tree-shakeable. The core engine is ~38 KB gzipped on its own (47 extensions, toolbar, bubble menu, and floating menu included), ~108 KB with ProseMirror. Additional extensions like tables, images, and emoji are separate packages. Import only what you need and your bundler drops the rest. See the full bundle size breakdown.

4,200+ tests: 2,675 unit tests and 1,550 E2E tests across 34 Playwright specs. An editor without tests is an editor you can't trust.

100% TypeScript, zero any. Every type is explicit. Every extension is fully typed. Every command has proper type inference.

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

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 on StackBlitz 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 only what you need for full control and zero bloat. Use StarterKit instead for a batteries-included setup with headings, lists, code blocks, history, and more.

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

The numbers

	Domternal
Angular components	5 (editor, toolbar, bubble menu, floating menu (in progress), emoji picker)
Extensions	57 across 10 packages
Nodes	23
Marks	9
Commands	140+
Tests	4,200+ (2,675 unit + 1,550 E2E)
Core engine size	~38 KB gzipped (47 built-in extensions + toolbar + bubble menu + floating menu)
Core package size	~108 KB gzipped (engine + ProseMirror)
Tree-shaking	Import only what you need, unused code is eliminated at build time
TypeScript coverage	100%, zero `any`
Table commands	18 (merge, split, resize, styling, all free)
License	MIT

Try it now

Website: domternal.dev

Docs: domternal.dev/v1/getting-started

Packages & Bundle Size: domternal.dev/v1/packages

GitHub: github.com/domternal/domternal

StackBlitz (Angular): stackblitz.com/edit/domternal-angular-full-example

StackBlitz (Vanilla TS): stackblitz.com/edit/domternal-vanilla-full-example

What's next

The core is headless and framework-agnostic, so React and Vue wrappers are on the roadmap. Post-MVP extensions like embeds (YouTube/video/audio), math (LaTeX/KaTeX), drag handles, and find & replace are planned based on community demand.

This is v0.2.0. The editor is stable, tested, and ready to use. I'm still working on polishing the documentation and cleaning up some rough edges. Once that's done, I'll release v1.0.0. In the meantime, I'd genuinely appreciate any feedback on the API design, docs, 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

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

Angular Deserves Better Than React Editor Wrappers. So I Built One.

What I built

Why the existing options didn't work

What makes Domternal different

Quick setup

No framework? No problem.

The numbers

Try it now

What's next

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