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
kind property holding such a kind object, and the
contains property is now expected to hold a kind object instead of a
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
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
Drop events can now be intercepted.
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
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?
export const NodeKindTop = new NodeKind('ed_toplevel')
const NodeKindTopOrBlock = new NodeKind('ed_toplevel_or_block', NodeKindTop)
NodeKindTopOrBlock.supers[NodeKind.block.id] = 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: https://github.com/the-grid/ed/blob/3488c1e86aef8b1160138880975637bb6c378318/src/schema/index.js#L8-L42
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.