Inline editor creator

[oleq]

ATM, the only "kind" of editor CKEditor 5 offers is the classic one https://github.com/ckeditor/ckeditor5-editor-classic. The Classic Editor converts a <textarea> into a "boxed" editor instance, which visually corresponds with what wysiwygarea and divarea plugins provide in CKEditor 4. While it works just fine, CKEditor 5 would feel strangely limited if it was the only creator shipped by the core team. So the idea is to also port the Inline Editor from v4.

Why Inline Editor?

1. It is one of the most amazing features of CKEditor 4. Despite being a totally new thing, CKEditor 5 must come with at least a minimum continuity, so developers migrating from v4 to v5 can find the same basic editor concepts powered by the new engine.

2. Inline is the truly seamless editing strategy. It does not interfere with the flow of the web page, e.g. it does not inject any UI and the such. It's perfect for forms with multiple fields where an avalanche of Classic Editors would bring only noise and disrupt the UX of the web page.

3. It's about minimalism. The compact UI it uses makes the editing feel lightweight and smart. And that's how we think when developing CKEditor 5.

What exactly should be ported?

The most basic implementation should bring a v4–styled CKEDITOR.inline( 'editor' ); initialization out of contenteditable element, like:

import InlineEditor from 'ckeditor5-editor-inline/src/inline';

InlineEditor.create( document.querySelector( '#editor' ), {
	plugins: ...,
	toolbar: ...
} )
.then( newEditor => {
	...
} );

But then, there could be more than that:

Inline out of textarea

http://docs.ckeditor.com/#!/api/CKEDITOR-method-inline

It is also possible to create an inline editor from the <textarea> element. If you do so, an additional

element with editable content will be created directly after the <textarea> element and the <textarea> element will be hidden.

Do we need it in v5? Would it be a new editor type or just a subset of the Inline, which kicks in when creator discovers the element is a <textarea>?

Inline all

http://docs.ckeditor.com/#!/api/CKEDITOR-method-inlineAll

Calls inline for all page elements with the contenteditable attribute set to true.

Do we want it in v5? If yes, then how to implement it? Should InlineEditor.createAll() return an array of Promises? Note that there's no such thing as CKEDITOR.instances any longer to browse/manage the instances in v5.

Do we want to allow each instance be configured separately in such situation?

Auto inline

By default in v4, if CKEDITOR.disableAutoInline has not been enabled, editors are created automatically for every contenteditable="true" element in DOM. So to seize the full control over the web page and configure each editor instance separately, the following code was needed, which I admit, was quite annoying (there are millions of questions on SO how to do it).

CKEDITOR.disableAutoInline = true;

CKEDITOR.inline( 'editable' );

I hope we don't port this thing because, as I said, it is counter–intuitive and annoying and InlineEditor.createAll() would be as good in this situation.

TBH, I'm also against InlineEditor.createAll() and, in fact, any kid of automation because it is just a syntax sugar for:

document.querySelectorAll( '[contenteditable]' ).forEach( el => {
	InlineEditor.create( el, {
		plugins: ...,
		toolbar: ...
	} )
	.then( newEditor => {
		...
	} );
} );

UI/UX

I'm for porting it almost 1:1 so there's no need to re–invent the wheel. That also includes the smart toolbar positioning, switching from to the bottom depending on the document scroll.

Something else?

Questions? Ideas?

[fredck]

Inline out of textarea
Inline all
Auto inline

I would start with fewer features, not having any of the above. Let's leave to the developer to create an element with the editable content inside and then use the inline creator to just activate CKEditor on it. All above features can come in the future if they will really make sense.

UI/UX

+1

[VincentClair]

Hello,

I could explain my need for ma app. Hope it could help.

Ideally, I would like to define a inline editor for many elements of a page (that is certainly in an iframe).
Elements could be of all sort: title (ie. Hn), blocks elements (div, article, etc.) or inline elements (span, etc.). The toolbar must adapt his functionalities with each type of element (no paragraph in Hn for example).

When I am in a block element and select some text, the toolbar should appear just above or behind the selection, to minimize mouse movement to toolbar.
I also could allow carriage return (br) in titles and inline elements for example.

The first solution, and easier for you as I understand, is to begin with InlineEditor.create call for each element. I think its perfect and the 3 others methods is really not interesting actually (Inline out of textarea, Inline all, Auto inline).

[oleq]

Ideally, I would like to define a inline editor for many elements of a page (that is certainly in an iframe).
Elements could be of all sort: title (ie. Hn), blocks elements (div, article, etc.) or inline elements (span, etc.). The toolbar must adapt his functionalities with each type of element (no paragraph in Hn for example).

This is certainly something that we consider, if only because we already support it in CKEditor 4. Take a look at the sample http://sdk.ckeditor.com/samples/inline.html, there's no list/table/blockquote when editing the <hN> element.

When I am in a block element and select some text, the toolbar should appear just above or behind the selection, to minimize mouse movement to toolbar.

The strategy of displaying the toolbar has a great impact on the UX. What you expect, is a contextual toolbar, which would always follow the selection. And as any kind of solution, it isn't perfect.

For instance, if we decided to display the toolbar always whether the selection is collapsed or expanded, it could be annoying for the users who do a lot of copy–paste work in the text, usually with the keyboard. The toolbar would follow "like a puppy" wherever the work is happening in the text, floating over a line or two and hiding the content underneath.

OTOH, if we decided to display the toolbar for expanded selection only, there would be no easy access to the tools e.g. bold, when the user's selection is collapsed and they want to start writing in bold from some particular point in the text.

So essentially, what we're talking about is a different kind of editor, bringing a different set of problems and features to the UX.

Editor–inline isn't perfect either, just like you noticed, the distance between the selection and the toolbar can become a problem, but OTOH, it never floats over the text so 100% of visible content is always available to read and select. And this is something that v4 users got used to, it will certainly help them in the migration.

There are many different editor types we would like to provide, as CKEditor 5 is more an editing framework than the actual editor. But as any project, CKEditor has limited resources and we think about priorities first. That's why we started with editor–classic you can play with on–line and now we're focused on editor–inline.

I created a separate issue for your feature request where we can discuss the details and consider the actual implementation.

BTW: Just to let you know, we considered this type of toolbar as a PoC in the past. If you configure a dev env, you can play with it
in http://localhost:8125/ckeditor5-ui/tests/manual/contextualtoolbar/contextualtoolbar.html.

I also could allow carriage return (br) in titles and inline elements for example.

I believe the discussion on this subject is already in https://github.com/ckeditor/ckeditor5-editor-inline/issues/3#issuecomment-279661467.