User edits a document that’s written in a specific syntax
That syntax supports a specific feature, that cannot be disabled in the editor (because of lack of configuration)
User inserts a content with the provided feature
For instance, let’s say we can’t disable nested lists, and a syntax doesn’t support it. How do we handle it? The file can’t be saved “as is”, so we have three main choices:
Fail on save, showing an error message indicating a feature used in the editor cannot be saved properly
Silently strip the content when saving the document (which IMO seems like a very bad idea)
Show a warning popup, and on save ask the user what they want to do
Option n°3 ensures the user is notified immediately, and has the final word. For some features, stripping may not be too bad: for instance, transforming a footer in a table into a normal row may not be a deal breaker. Option n°1 forces the user to deal with the matter immediately.
What we’ve tried to do in the past (at least in the wiki editor and I think also in CKEditor), is to customize the editor’s features based on the syntax capability. In your example if the target syntax doesn’t support nested list, then the editor shouldn’t allow you to enter a nested list.
That’s by far the best approach to me (but it’s probably not the simplest).
BTW for a syntax to be supported in the editor it requires to have both a parser and a renderer.
We also don’t need to support the WYSIWYG for all syntaxes if there are syntaxes too hard to support and that will not work well, at least until we make the required changes to the editor.
What we also need to decide is how we handle the case when the editor doesn’t support a feature that the syntax supports. The best, IMO, is to mark the concerned content as readonly in the editor with some explanation (on hover for ex) as to why it cannot be edited.
I’m aware of that, but I’m specifically talking about cases where a feature cannot be disabled in the editor for any reason (lack of programmability, etc.)
The short answer is that it needs to be fixed so that it can be disabled (ie a PR should be sent to BlockNote to fix this).
Maybe your question is: what to do in the meantime (ie before it’s fixed)?
In that case, option 3 is probably the best since it encompasses option 1. Option 2 is a bad idea as you mentioned.
There’s also another option: when you press edit for a doc, the syntax capabilities are checked against the editor’s capabilities and if there’s a mismatch, show a warning to the user, indicating the problems and asking to continue, cancel or switch to the wiki editor.
Now I’m curious to understand your real use case because nested lists are supported by all syntaxes AFAIK.
I think it’s useful to distinguish between two case:
the editor generates content that can’t be saved with the backend syntax
the backend syntax supports content that the editor can’t edit
For the first case the best solution, as Vincent and Manuel mentioned, is to disable the editor features that produce content unsupported by the backend syntax. If the editor doesn’t provide the required configuration to do this cleanly, we can always rely on CSS or JavaScript hacks to hide / remove those features from the editor. This can be packaged in a client-side component whose hint is the backend syntax. So each backend syntax we support could provide its own hacks to disable / hide / remove the editing features that it doesn’t support.
For the second case the best option is to mark as read-only the content that the editor can’t edit. Each backend syntax we support could provide a component implementation that iterates the syntax tree looking for syntax elements that are not supported by the editor, marking one of its ancestors as read-only. That ancestor should ideally be as close as possible to the unsupported syntax element / node, but in some case we might have to mark as read-only an entire block of content (e.g. the entire table or paragraph).