Blocknote as the next rich editor for XWiki

Development
1

Hello all,

In this post I’d like to discuss the adoption of Blocknote as the next rich editor of XWiki, as a replacement for CKEditor 4.

This discussion will focus on the most relevant point to be mindful of this post’s length, but a design page exists with more details.

So first, let me start with a view of the web editor landscape (a first version of this study was done earlier; I updated it today with some more libraries and re-evaluated the existing ones).

Dismissed options

  • ProseMirror: too low level for our needs, more of a framework to build editors (i.e., we would rather not redevelop ourselves all the UI elements of an editor).
  • Editor.js, Novel, Quill, BlockSuite, Remirror, ContentTools, Pell: very low activity in the past years.
  • TinyMCE, CKEditor 5: Incompatible license (GPL2).
  • Gutenberg: In the process of moving from GPL to MPL since 2021, we can consider the license as incompatible.
  • Tiptap: Based on ProseMirror, for our experiments on Cristal, we decided to move away from it since the interesting UI elements were progressively becoming paid extensions.
  • Milkdown: Focused on Markdown support only, so not relevant for XWiki’s needs.
  • Slate: documented as beta by its maintainers
  • Draft.js (Facebook): Archived
  • Plate: Decently active, MIT, but maintained by a single developer
  • Trix: no documented support for real-time, very minimalistic documentation
  • Lexical: compatible license, backed by meta, but at the same level of abstraction as ProseMirror. Low-level APIs, not many rich UI elements available as extensions (e.g., no quick action extension).

Remaining choice

To the best of my knowledge, the only remaining choice is BlockNote:

Positive points:

  • Actively maintained
  • Backed by a small company
  • Compatible MPL license (except for a few modules using GPL, but we don’t use those).
  • Good default of rich UI elements
  • Good support for realtime edition (based on yjs)
  • We have a good knowledge of the editor thanks to experiments with Cristal

Negative points:
But there is also quite the list of more concerning points that I’d like to highlight (note that I start with the assumption that we want to be 100% iso-compliant with what was possible with CKEditor 4).

@ClementEXWiki @mflorea please let me know if you think there are other important points to highlight.

Before going into the technical aspects. Blocknote is currently maintained by a small company (TypeCell) with 3 main developers. This is a threat to the longevity of the project, and it’s unclear what would happen if the company stopped maintaining the project.

On the technical side (non-exhaustive list):

  1. The project is heavily relying on React, forcing us to have to know this front-end framework in addition to Vue. We can encapsulate React in the single Blocknote module, but it is still adding more work to integrate with Vue components.
  2. Many elements or interactions are difficult to remove from the UI (e.g., it is impossible to disable table cell resizing).
  3. The existence of predefined UI elements can lead to incompatibility with our needs (e.g., Blocknote tables can only have a single header).
  4. There are some technical limitations preventing us from fully integrating macros in an iso-functional way (e.g., custom blocks cannot be nested, meaning that wiki macros cannot be nested).
  5. Some nesting of elements is not possible in Blocknote (e.g., it is not possible to add lists in table cells).
  6. More generally, several concepts are not easily extensible (e.g., adding more parameters to images).

You can look for the issues created by @ClementEXWiki on TypeCellOS/BlockNote and the issues created on our Jira for the Blocknote component for an exhaustive list of currently documented issues.

Conclusion

I think we can say that there is no perfect option.
But, despite its current limitations, Blocknote is the closest we can get to a rich editor matching the needs of XWiki without fully redeveloping the UI elements needed for a rich editor from scratch (based on Prosemirror or Lexical).

Please let me know what you think!
Thanks.

1 Like
2

Good summary, thank you for your research :slight_smile:

Just a question, what do you mean by “no quick action extension” for Lexical? If you’re referring to the slash menu feature, it is available: https://github.com/facebook/lexical/pull/2534.

3

Afaiu it’s only demo code in the lexical-playground directory, not something built to be reused.

4

Do we have any hope that BlockNote will address the mentioned limitations? Would it be feasible that we contribute fixes for them? If not, I don’t see how BlockNote can be a serious option for being a future rich text editor for XWiki. The mentioned limitations sound serious enough that I don’t see how we could ever make this the default editor in XWiki.

5

Nope, this was the case when the PR was merged, but now it’s part of the main React package: lexical/packages/lexical-react/src/LexicalTypeaheadMenuPlugin.tsx at main · facebook/lexical · GitHub

6

On my side, my main worries, so far, are:

  • The differences between BlockNote’s client-side HTML rendering (edit mode) and XWiki’s server-side HTML rendering (view mode). What you see in edit mode is not exactly what you get in view mode. This will be noticeable especially when triggering in-place editing, because the view HTML (from XWiki rendering) is replaced in-place by the edit HTML (from BlockNote’s rendering). Just to give an example, lists are rendered using UL and LI tags by XWiki rendering versus using DIV tags by BlockNote. Of course, we would have this problem with any rich text editor that abstracts the syntax of the edited content.
  • The syntax mismatch between XWiki and BlockNote. The problem we had before, when integrating CKEditor, was that XWiki syntax is less powerful / expressive than the HTML syntax. Everything written in XWiki syntax could be converted to HTML and thus edited with CKEditor, but not everything that CKEditor was producing (HTML) could be converted to XWiki syntax. In order to mitigate this we had to disable certain CKEditor features. Fortunately, CKEditor has a very powerful configuration system that allows us to specify precisely which HTML elements / attributes are supported by a given wiki syntax, and the editor is disabling automatically all the features that output those elements / attributes. The relation between XWiki’s syntax and BlockNote’s schema (AST) is different though: in some areas (e.g. tables, custom data- attributes, subscript, superscript) the XWiki syntax is more powerful / flexible, while in other areas the BlockNote schema is more powerful (block-level content in blockquote, list item attributes). This means it’s not enough to disable some features of BlockNote in order to avoid losing content on save. We also have to make sure we don’t lose content when Alice edits with BlockNote a page that was last edited by Bob using the wiki editor (i.e. using directly XWiki syntax). Both parts are difficult to implement. On one side, BlockNote is currently not flexible enough to allows us to disable all the features that produce unsupported content. On the other side, we would have to identify and protect somehow (e.g. wrap in a rendering macro to make it read-only?) the content that can’t be edited with BlockNote.
  • The cost of customizing / extending certain parts of BlockNote. When we integrated CKEditor 4, it was already a mature editor with lots of configuration options and APIs for integrators to easily extend it. BlockNote is not there yet, so we’ll have to either hope they will implement the features we need or we’ll have to implement them ourselves, with a significant cost.

I haven’t checked the other editors, but I trust Manuel’s evaluation. It looks like we have to put our faith in BlockNote.

Thanks,
Marius