Release 0.4.0


Breaking changes

The way valid parent-child relations for node types are specified was changed. Instead of relying on strings, node kinds are now objects that specify arbitrary sub-kind relations. The static kinds property on node types replaced by a non-static kind property holding such a kind object, and the contains property is now expected to hold a kind object instead of a string.

The keybindings for make-paragraph and make-heading were changed. To make the current textblock a paragraph, you now press Ctrl/Cmd-0, and to make it a heading, you press Ctrl/Cmd-N, where N is the level of the heading.

Bug fixes

Copy-pasting between ProseMirror instances is now more robust (the question of whether the selection cuts through nodes at the start and end of the fragment is preserved).

Selection management on mobile platforms should now be improved (no longer unusable, probably still quite buggy).

Fix a problem where reading a change from the DOM was confused by trailing whitespace in a text block.

Fix a bug in scrolling things into view that would break scrolling of anything except the whole document.

Don’t render menu dropdown elements unless they actuall have content.

Fix bug that would reset the selection when a selectionChange event handler tried to access it.

The selection classes are now properly exported from the edit module.

New features

Drop events can now be intercepted.

The beforeTransform event is now fired before a transform is applied.

Menu command icon specs can now provide a dom property to provide a piece of DOM structure as their icon.

DOM parser specs can now include a selector property to only run the parser on nodes that match the selector.


In our schema some node types (Heading, BlockQuote) can only be on the top level. Paragraph can be on the top level or under BlockQuote. It worked with 0.3.0; this change doesn’t make it work with 0.4.0. What would be the equivalent?

Looks like

export const NodeKindTop = new NodeKind('ed_toplevel')
const NodeKindTopOrBlock = new NodeKind('ed_toplevel_or_block', NodeKindTop)
NodeKindTopOrBlock.supers[] = true

works, but isn’t so pretty.


Why aren’t you just passing NodeKind.block as another superkind of NodeKindTopOrBlock? That’ll have exactly the same effect as your kludge on line 3.


Though my previous statement is technically correct, the resulting kind still won’t do what its name suggests (and neither did your code) – it’ll create a kind that is a sub-kind of top and block, whereas you probably want one that’s a super-kind of those. I’ve so far solved this by creating a new block kind, making it a sub-kind of top, and subclassing all block node types to use that instead of the built-in block kind. This is a bit of a pain, and I’m currently experimenting with a system where you can also create new kinds by specifying their sub-kinds.


Does this do what you described? It seems to work as expected now:

Only issue I see is that in a new paragraph in a blockquote I’m seeing the tooltip for Heading. It’s allowed in the schema BlockQuote contains, but not in Heading kind. I can’t apply it from the tooltip, only see it.

How can I allow Paragraph and Lists to be top level or under BlockQuote, but Heading only top level?


Your code looks good. This’ll be easier in the next version (you won’t have to replace the built-in block type anymore).

I filed issue 219 for the command showing up in the wrong context. To work around that, you could define your own select method for the heading:make command until that is fixed.