ceb0dac: New Decorations API

Finally the decorations API is here! Even though Decorations itself are nothing new in ProseMirror, the new API makes it much easier to use them in Tiptap without leaving your extensions.

Decorations change how the document looks without changing the document itself. Highlighting search results, marking spelling mistakes, showing collaborator cursors, putting a drag handle next to every block.

Until now you had to write a ProseMirror plugin by hand for this, keep the decoration set in plugin state, and map it forward on every transaction. Extensions can now declare decorations directly with a new addDecorations() hook.

addDecorations() {
  return {
    create: ({ state }) =>
      // findMatches can be any function that returns an array of { from, to } ranges
      findMatches(state.doc).map(match =>
        Decoration.Inline(match.from, match.to, { class: 'highlight' }),
      ),
  }
}

There are three kinds. Decoration.Inline() styles a range of text. Decoration.Node() puts attributes on a block's DOM element. Decoration.Widget() renders your own element at a single position.

Every extension that declares decorations is collected into one plugin, so several extensions can decorate the same document without fighting over it.

Doing less work on every keystroke

By default decorations are rebuilt whenever the document changes. That is fine for small documents and wasteful for large ones, so there are two ways to narrow it down.

shouldUpdate() skips transactions you do not care about. If your decorations only depend on headings, ignore everything else.

update: 'changedRanges' together with createInRange() only rescans the blocks that actually changed. On a long document this is the difference between scanning the whole thing on every keystroke and scanning one paragraph.

For decorations driven by data outside the editor, like comments loaded from a server, use update: 'manual' and refresh them yourself with editor.commands.updateDecorations().

React and Vue components as widgets

ReactWidgetRenderer and VueWidgetRenderer render a real component into a widget decoration, inside your existing app context. Providers, context and stores work as usual.

Widgets take a key. Reuse the same key and the component instance stays mounted while the document changes around it, so local state such as an open menu, a counter or a half-typed input survives editing. Use a stable id from your own data, not a position or a list index, otherwise the component remounts and loses that state.

Widgets also accept the ProseMirror options side, relaxedSide, stopEvent and ignoreSelection.

Documentation

• Decorations
• Decorations with React
• Decorations with Vue
• API Documentation

ceb0dac: ListKeymap now registers a Tab shortcut that sinks a top-level textblock into the previous list's last item. Pressing Tab at the start of a paragraph right after a bullet/ordered/task list moves the paragraph inside the last list item. The handler does nothing when the cursor is already inside a list item (sinkListItem keeps working), when there is no list before the paragraph, when the caret is mid-textblock, or when the selection is not a text selection (for example a gap cursor).

@tiptap/core also exposes a new getPreviousBlockSibling($pos) helper that returns the block-level sibling before the cursor's textblock, or null at the first child of the block parent.

ceb0dac: ListKeymap now registers a Tab shortcut that sinks a top-level textblock into the previous list's last item. Pressing Tab at the start of a paragraph right after a bullet/ordered/task list moves the paragraph inside the last list item. The handler does nothing when the cursor is already inside a list item (sinkListItem keeps working), when there is no list before the paragraph, when the caret is mid-textblock, or when the selection is not a text selection (for example a gap cursor).

@tiptap/core also exposes a new getPreviousBlockSibling($pos) helper that returns the block-level sibling before the cursor's textblock, or null at the first child of the block parent.

ceb0dac: New Decorations API

Finally the decorations API is here! Even though Decorations itself are nothing new in ProseMirror, the new API makes it much easier to use them in Tiptap without leaving your extensions.

Decorations change how the document looks without changing the document itself. Highlighting search results, marking spelling mistakes, showing collaborator cursors, putting a drag handle next to every block.

Until now you had to write a ProseMirror plugin by hand for this, keep the decoration set in plugin state, and map it forward on every transaction. Extensions can now declare decorations directly with a new addDecorations() hook.

addDecorations() {
  return {
    create: ({ state }) =>
      // findMatches can be any function that returns an array of { from, to } ranges
      findMatches(state.doc).map(match =>
        Decoration.Inline(match.from, match.to, { class: 'highlight' }),
      ),
  }
}

There are three kinds. Decoration.Inline() styles a range of text. Decoration.Node() puts attributes on a block's DOM element. Decoration.Widget() renders your own element at a single position.

Every extension that declares decorations is collected into one plugin, so several extensions can decorate the same document without fighting over it.

Doing less work on every keystroke

By default decorations are rebuilt whenever the document changes. That is fine for small documents and wasteful for large ones, so there are two ways to narrow it down.

shouldUpdate() skips transactions you do not care about. If your decorations only depend on headings, ignore everything else.

update: 'changedRanges' together with createInRange() only rescans the blocks that actually changed. On a long document this is the difference between scanning the whole thing on every keystroke and scanning one paragraph.

For decorations driven by data outside the editor, like comments loaded from a server, use update: 'manual' and refresh them yourself with editor.commands.updateDecorations().

React and Vue components as widgets

ReactWidgetRenderer and VueWidgetRenderer render a real component into a widget decoration, inside your existing app context. Providers, context and stores work as usual.

Widgets take a key. Reuse the same key and the component instance stays mounted while the document changes around it, so local state such as an open menu, a counter or a half-typed input survives editing. Use a stable id from your own data, not a position or a list index, otherwise the component remounts and loses that state.

Widgets also accept the ProseMirror options side, relaxedSide, stopEvent and ignoreSelection.

Documentation

• Decorations
• Decorations with React
• Decorations with Vue
• API Documentation

ceb0dac: New Decorations API

Finally the decorations API is here! Even though Decorations itself are nothing new in ProseMirror, the new API makes it much easier to use them in Tiptap without leaving your extensions.

Decorations change how the document looks without changing the document itself. Highlighting search results, marking spelling mistakes, showing collaborator cursors, putting a drag handle next to every block.

Until now you had to write a ProseMirror plugin by hand for this, keep the decoration set in plugin state, and map it forward on every transaction. Extensions can now declare decorations directly with a new addDecorations() hook.

addDecorations() {
  return {
    create: ({ state }) =>
      // findMatches can be any function that returns an array of { from, to } ranges
      findMatches(state.doc).map(match =>
        Decoration.Inline(match.from, match.to, { class: 'highlight' }),
      ),
  }
}

There are three kinds. Decoration.Inline() styles a range of text. Decoration.Node() puts attributes on a block's DOM element. Decoration.Widget() renders your own element at a single position.

Every extension that declares decorations is collected into one plugin, so several extensions can decorate the same document without fighting over it.

Doing less work on every keystroke

By default decorations are rebuilt whenever the document changes. That is fine for small documents and wasteful for large ones, so there are two ways to narrow it down.

shouldUpdate() skips transactions you do not care about. If your decorations only depend on headings, ignore everything else.

update: 'changedRanges' together with createInRange() only rescans the blocks that actually changed. On a long document this is the difference between scanning the whole thing on every keystroke and scanning one paragraph.

For decorations driven by data outside the editor, like comments loaded from a server, use update: 'manual' and refresh them yourself with editor.commands.updateDecorations().

React and Vue components as widgets

ReactWidgetRenderer and VueWidgetRenderer render a real component into a widget decoration, inside your existing app context. Providers, context and stores work as usual.

Widgets take a key. Reuse the same key and the component instance stays mounted while the document changes around it, so local state such as an open menu, a counter or a half-typed input survives editing. Use a stable id from your own data, not a position or a list index, otherwise the component remounts and loses that state.

Widgets also accept the ProseMirror options side, relaxedSide, stopEvent and ignoreSelection.

Documentation

• Decorations
• Decorations with React
• Decorations with Vue
• API Documentation

ceb0dac: New Decorations API

Finally the decorations API is here! Even though Decorations itself are nothing new in ProseMirror, the new API makes it much easier to use them in Tiptap without leaving your extensions.

Decorations change how the document looks without changing the document itself. Highlighting search results, marking spelling mistakes, showing collaborator cursors, putting a drag handle next to every block.

Until now you had to write a ProseMirror plugin by hand for this, keep the decoration set in plugin state, and map it forward on every transaction. Extensions can now declare decorations directly with a new addDecorations() hook.

addDecorations() {
  return {
    create: ({ state }) =>
      // findMatches can be any function that returns an array of { from, to } ranges
      findMatches(state.doc).map(match =>
        Decoration.Inline(match.from, match.to, { class: 'highlight' }),
      ),
  }
}

There are three kinds. Decoration.Inline() styles a range of text. Decoration.Node() puts attributes on a block's DOM element. Decoration.Widget() renders your own element at a single position.

Every extension that declares decorations is collected into one plugin, so several extensions can decorate the same document without fighting over it.

Doing less work on every keystroke

By default decorations are rebuilt whenever the document changes. That is fine for small documents and wasteful for large ones, so there are two ways to narrow it down.

shouldUpdate() skips transactions you do not care about. If your decorations only depend on headings, ignore everything else.

update: 'changedRanges' together with createInRange() only rescans the blocks that actually changed. On a long document this is the difference between scanning the whole thing on every keystroke and scanning one paragraph.

For decorations driven by data outside the editor, like comments loaded from a server, use update: 'manual' and refresh them yourself with editor.commands.updateDecorations().

React and Vue components as widgets

ReactWidgetRenderer and VueWidgetRenderer render a real component into a widget decoration, inside your existing app context. Providers, context and stores work as usual.

Widgets take a key. Reuse the same key and the component instance stays mounted while the document changes around it, so local state such as an open menu, a counter or a half-typed input survives editing. Use a stable id from your own data, not a position or a list index, otherwise the component remounts and loses that state.

Widgets also accept the ProseMirror options side, relaxedSide, stopEvent and ignoreSelection.

Documentation

• Decorations
• Decorations with React
• Decorations with Vue
• API Documentation

• @tiptap/pm@3.29.0

• @tiptap/extension-text-style@3.28.0
• @tiptap/pm@3.28.0

• @tiptap/pm@3.28.0

• @tiptap/pm@3.28.0

• @tiptap/pm@3.28.0

• @tiptap/pm@3.28.0

• @tiptap/extension-collaboration@3.28.0
• @tiptap/core@3.28.0
• @tiptap/extension-node-range@3.28.0
• @tiptap/pm@3.28.0

• @tiptap/pm@3.27.4

• @tiptap/pm@3.27.4

• @tiptap/pm@3.27.4

• @tiptap/pm@3.27.4

94de762: Fix markdown parsing bugs where block elements right after an ordered list item (with no blank line in between) were wrongly treated as lazy continuation of the list item, instead of terminating the list the way other markdown parsers do:

• Thematic breaks (---, ***, ___, * * *) were swallowed into the list item as literal paragraph text — along with every line after them. They now terminate the list and become a horizontal rule.
• Fenced code blocks (``` and ~~~) were nested inside the list item. They now terminate the list and become a top-level code block.
• Unindented bullet markers (- item) were nested inside the ordered list item. They now terminate the ordered list and start a new top-level bullet list. Indented bullets still nest inside the item as before.

An indented ***/___ inside item content is now also parsed as a horizontal rule inside the item instead of literal text. A --- line directly below item paragraph text keeps its current behavior because it is a setext heading underline per CommonMark, not a thematic break.

94de762: Fix indented ordered list items (e.g. one leading space before the marker, as happens when a top-level ordered list is itself nested inside another list) losing inline formatting during markdown parsing. The custom ordered-list markdown tokenizer built its nested structure with a hardcoded base indentation of 0, so an item whose actual indentation was non-zero never matched, causing the tokenizer to silently produce zero items and bail out — falling back to a path that left the item's content as literal, unparsed text instead of running it through inline tokenization (bold, italic, etc. were lost). The base indentation is now taken from the first collected item instead of being hardcoded.

Updated dependencies [94de762]

• @tiptap/core@3.27.3
• @tiptap/pm@3.27.3