Introduce headless editor

[Reinmar]

See @fredck's initial ticket: ckeditor/ckeditor5-design#86.

The goal of a headless editor would be to make it as simple as possible to create an editor with your own UI.

This means that we need:

• A special editor class which initialises no UI.
• Some way to turn off the UI which features bring themselves (e.g. the link feature will display a balloon when you click on a link). This is more tricky as it affects how the features work. Perhaps, following the "feature engine + end feature" split, we could also split the part which is responsible for enabling UI. So, we'd have "feature engine + feature UI + end feature" (where the last bit would require the first two).
• Finally, when implementing features we need to think on designing their APIs (commands, public methods) in such a way that you're able to reuse all that functionality in your own, external code. This should be mostly fine already, but it's something which we need to keep constantly in our heads.

EDIT: See #984 for explanation how headless editor can be implemented.

[artaommahe]

Also this is useful to render saved editor schema in readonly mode. It allows to store editor schema in DB instead of plain html and have dynamic rendering (converting schema -> html) at front-end to display article to user.

[Reinmar]

This is a use case we've been also considering. To make it possible, we decided to split every feature into two level:

• the engine part,
• and the full feature (the engine part + the UI).

You can clearly see this division in the Bold feature:

• BoldEngine implements the schema rules, converters between the model and the view and even a command. This means that if you load an editor with this feature you'll be able to perform model<->view conversion (loading data, getting data) and even apply/remove the bold attribute from the selection (using virtual selection in the model). All this, without any dependency on the DOM and the browser environment in general.
• Bold requires BoldEngine and adds a UI on top of it (button + keystroke).

So, not only this architecture allows running (in Node.js) an editor with some features to load/convert/retrieve the data, but it also allows operating on this data. Since model and view (virtual DOM, not real DOM) are browser-independent, unless rendering to the DOM is not enabled, you can do everything you want.

[adelura]

If it's going to be a big feature/epic then I have suggestion for code name for that one: Mike.

[djanosik]

I've tried to build an embeddable / headless editor. It works quite well so far, but there are some issues:

1. It's about 100 kB (ES5, gzipped). I wonder if it will be possible to make it a bit smaller. 100 kB is not too much, but mobile devices often run on slow connections.
2. The Blockquote plugin overwrites enter key behavior. I don't use this plugin because I don't want GUI. But I need fully functional typing. I think such overwrite should be handled somewhere else, perhaps in BlockquoteTyping plugin.

[Reinmar]

Wow, thanks for the feedback :)

It's about 100 kB (ES5, gzipped). I wonder if it will be possible to make it a bit smaller. 100 kB is not too much, but mobile devices often run on slow connections. See report.

Let's discuss it in #435.

The Blockquote plugin overwrites enter key behavior. I don't use this plugin because I don't want GUI. But I need fully functional typing. I think such overwrite should be handled somewhere else, perhaps in BlockquoteTyping plugin.

I didn't expect that anyone will ever want to split the code into even smaller pieces :). I thought that we're already going crazy dividing features into two parts (engine + UI).

But your point of view makes a lot of sense. We need to decide whether we more want to divide features into browser-independent + browser-dependent pieces or headless + head. I reported a more specific ticket about it in #488. Feel free to comment there.

[Reinmar]

There's a discussion regarding implementing a headless editor in #984. We've explained there some architectural concepts like how's the current feature split working and what interfaces make for an editor.

[Inviz]

Hello friends. I've tried to use ckeditor5 as headless editor, fully removing all the ui and so far my experience is alright, but i needed some re-touches.

1. I managed to change build system (using vite) and not use webpack, or any ckeditor-specific plugins
2. It is difficult to not get css loaded into the build. A lot of files include them inside packages. I had to create custom rollup transformer to stub the css into empty files, but it's still not really a clean solution. Same with the svg icons
3. There're some modules that access some ui code ,e.g. editor.ui.focusTracker, so i stubbed it.
4. I had to pick non-ui specific files for all the modules i used (e.g. headingediting.js vs heading.js), but some of the modules still require ui files by using imports from main file (e.g. hypothetical xxxediting.js does import {xxx} from "index.js" which does import xxxui.js. I think one of examples is undo plugin
5. Unfortunately it currently is really hard to get some of the cruft out of the build (e.g. widgetresize)
6. It was really nice to be able to use ckeditor on dom elements directly, implementing custom focus handling, etc. It went really smooth.

Overal i'm decently happy with the result, but it obviously could use some love. I think CKEditor5 is the best framework out there and i'm using it with a lot of custom plugins and external ui. I just wish there was a cleaner (more complete) way to achieve it.

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[Inviz]

Still important

…

On Sun, Oct 22, 2023 at 1:13 PM CKEditor Bot ***@***.***> wrote: There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue. — Reply to this email directly, view it on GitHub <#438 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAVFDGD3A5TCW4BAH42MDYASTPHAVCNFSM4DKHLWD2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXGM4TSNRYHA2Q> . You are receiving this because you commented.Message ID: ***@***.***>