editor (Computers), noun: a program used for writing and revising code, data, or text
read-only (Computers), adjective: of or relating to files or memory that can be read but cannot normally be changed
Several people have asked for a read-only feature to ProseMirror. Today, I spent some time thinking about how this should work. My conclusion was that I have no idea how this should work, and that the different people asking for it probably have different ideas in mind. Here are some possible use cases:
Simply show a document in a page, as plain content
Show a document in a page in such a way that it looks exactly like it would look inside of a ProseMirror editor, but without any editor functionality.
Have a regular editor, including menus and non-editing commands, but disallow all editing. Still allow updating the document through the API.
Have a regular editor, but disallow some kinds of editing.
The top two should probably stay entirely outside of ProseMirror. You can render the HTML of your document, and show that in your page, optionally applying ProseMirror’s stylesheets by wrapping it in a
The third one is unexpectedly hard to implement because distinguishing between user actions and API calls is not something you can easily do, since most user editing actions will go through API calls. Also, for ProseMirror’s approach to managing DOM and selection to make any sense,
contentEditable needs to be enabled, which means the browser will consider the content to be editable and give you cut and paste menu items, etc (even if we end up intercepting and discarding their effect).
I am not really interested in going down the road I went with CodeMirror, which is full of checks and hacks to suppress user editing in read-only mode. It makes the code ugly, and has led to a whole string of bugs where a case was missed and users would be able to edit read-only content in some cases.
The last case, disallowing only some kinds of edits, is kind of like the third, but even messier.
In another thread a system based on filtering transform steps was proposed. Something like that could work (though it’d have to happen on the editor level, not on the transform level, since those aren’t necessarily tied to an editor). This might not always be a very helpful solution though:
You couldn’t really do fine-grained filtering, but you could deny or accept transforms based on some test, either by looking at the steps, or by doing a test on the resulting document.
The filtering will also apply to all API calls that result in a transform. To kludge around that we could add a
filter: falseoption to
applyto suppress it.
The menu wouldn’t be aware of the read-only state of the editor (and I’m not volunteering to maintain all the extra cruft needed to make it aware) so you’d have to explicitly define your own menu for your read-only interface.
What are your thoughts? Suggestions? Do you have a use case I didn’t take into account?