There should be an empty paragraph in the newly created editor

[pjasiun]

When you create an editor, but not call setData you have the editor without any paragraph inside and strange things (big fan!) happens. You can type, but you can not break, since there is no paragraph to break.

Note that this should be up to the editor's implementation what is the default content. The one-line-title editor might not have any paragraph by default.

[fredck]

As a matter of fact, that paragraph doesn't exist. It is just a place where the caret can be placed so one can start typing.

For instance, the expectation is that the editor will return an empty HTML if nothing is typed in that paragraph.

Therefore, I was wondering if this couldn't be a helper, instead of a Model element. A view only element that is created in the Model only when the user adds something into it.

This problem extends not only to empty documents. It also applies to other situations where we need an empty "escape" place at the end of the document, when for example we have just a table, a widget or an image inside the document.

[Reinmar]

Shouldn't editor return an empty data when you have an empty heading inside too? I mean... at least in CKEditor 4. Because I think that it complicates things a lot if we try to think this way. To keep things simple I'd always have a block in the editable and also in the model (when talking about block editables). Otherwise, it'll be crazy.

[fredck]

Shouldn't editor return an empty data when you have an empty heading inside too?

Yes, it should. So maybe a different strategy, that involves touching the Model as well, would be better.

This problem extends not only to empty documents. It also applies to other situations where we need an empty "escape" place at the end of the document, when for example we have just a table, a widget or an image inside the document.

Still, this situation is valid so we could use the very same logic for these cases as well.

[Reinmar]

Yes, it should.

Why, in fact? For me "I wrote an empty blog post" or "an empty email reply" simply invalid. I wouldn't expect anything special from the editor in such case... Do you have an idea why we should return empty string?

[fredck]

Why, in fact?

Because we learned a lot from the CKEditor history.

For me "I wrote an empty blog post" or "an empty email reply" simply invalid

Exactly, and that's the main reason for it. Many platforms do form validation based on the data produced by the form fields. If the editor returns an empty paragraph, it'll not be understood as empty because the expectation is an empty string.

[Reinmar]

Because we learned a lot from the CKEditor history.

So I was asking exactly this – what we've learned? ;)

The validation scenario makes of course great sense.

[Reinmar]

DUP: https://github.com/ckeditor/ckeditor5-core/issues/65

[Reinmar]

If anyone wants to tackle this – what's the proposed solution?

One that came to my mind is to implement it in ckeditor5-paragraph which already handles similar cases during conversion. It listens to insert events and autoparagraph content which is either unsupported by the editor or which is not wrapped in any block.

Here, I'd see a changesDone listener (change is not an option, I think, because temporarily the editor may be empty) which checks if the content is totally empty and, if is, creates a paragraph and puts selection in it.

[Reinmar]

Note – the advantage of listening to model changes is that we'll fix the content in other situations in which it might've been emptied totally. We've been trying to implement deleteContent() and insertContent() in such a way that they don't ever leave an empty content, but who knows what other features will do.

[fredck]

Here, I'd see a chagesDone listener (change is not an option, I think, because temporarily the editor may be empty) which checks if the content is totally empty and, if is, creates a paragraph and puts selection in it.

We may face the same problem even when the editor has contents. For example, if it has an image only.

I've commented the following earlier:

This problem extends not only to empty documents. It also applies to other situations where we need an empty "escape" place at the end of the document, when for example we have just a table, a widget or an image inside the document.

What about figuring out a solution that would handle all these cases where the user doesn't have any place in the root to place the selection in?

[Reinmar]

What about figuring out a solution that would handle all these cases where the user doesn't have any place in the root to place the selection in?

This is a bit different issue and if we want to have a quick win on the setData( '' ) I wouldn't risk investigating the other issue :D.

E.g. In CKE4 we introduced magicline to deal with this problem and changed the insertion algorithms so they don't create an empty paragraph after tables, hrs, etc. Magicline isn't perfect too and CKE5 gives us far more options than we had in CKE4, but, exactly for this reason, I wouldn't want to spend more time on this now. After all, we have only the image widget to deal with now.

Another example – what with spaces between two images? Should the temporary "escape" block be there too? The same question can be asked about the space at the beginning of the document. Nooo... I already started thinking on this. Stop! :D

[Reinmar]

OK, it can be done this way – you select an image which is the last element in the content. Then you press arrow down because you want to type after it – this adds a temporary paragraph. It gets removed if you move out of it without typing in it.

But, if we agree this is the way, then it's certainly a separate issue. It's a magicfing... magicblock!

[fredck]

you select an image which is the last element in the content. Then you press arrow down because you want to type after it

That's my point... I don't think that this is the way users will do it.

The fact is that before an image at the start of the contents, or even in-between subsequent images, there is no visible empty space. For these cases, magic-line is definitely the right solution.

At the end of the contents though, users usually see empty space. So if they want to type there, they go on that empty space and click. It would be frustrating to see that the caret doesn't get there and to have to learn that I have to click the image and use the arrows to reach that space. That would even sound weird, because arrows are used to move to existing places, so why it didn't work with the click?

That's why I'm proposing a simpler solution to solve that one problem. Something that would guarantee that there is always a place to put the selection in at the end of the document.

Ideally, such paragraph would be marked as "magic", because it hasn't been created by the user and would be removed when retrieving the contents (that's why I proposed it being a view only feature).

[Reinmar]

So if they want to type there, they go on that empty space and click. It would be frustrating to see that the caret doesn't get there and to have to learn that I have to click the image and use the arrows to reach that space

Yep, if we'd go this way, then this would need to be connected with the magicline.

That's why I'm proposing a simpler solution to solve that one problem. Something that would guarantee that there is always a place to put the selection in at the end of the document.

Ideally, such paragraph would be marked as "magic", because it hasn't been created by the user and would be removed when retrieving the contents (that's why I proposed it being a view only feature).

We can't have magic elements in the model without having serious problems with editing algorithms. We also don't think that we could have magic elements in the view without having them in the model because there'd be serious issues with the selection, mappings and everything around.

Which means that this isn't a simple solution to implement. Its simplicity is in how it could work for the user, but it's not trivial to develop.

Hence, I'll report a separate ticket for it to not bloat this one.

[Reinmar]

➡️ Magicline and magicblock: #407

[scofalik]

Okay, so as the discussion shown, there are actually multiple things to resolve, and we should resolve them one by one in separate issues.

In this issue let's stick with the original problem which was: there should be always a <p></p> in main editable (as long as there is a paragraph feature).

The "quick win" solution was already proposed by @Reinmar - on changesDone check if there are any contents in editor and if not, add <paragraph> to the model.

As I was about to implement this solution one thing came to my mind: we could have multiple roots. Since paragraph feature should be universal I think it should be ready to handle editors with multiple roots. So my idea is to check all the roots on changesDone (except of graveyard root) and fix all roots that are empty (and can have <paragraph> element according to Schema).

[Reinmar]

https://github.com/ckeditor/ckeditor5-paragraph/issues/19 has been closed, so now when loading empty data or if some algorithm mistakenly cleared the editor completely an empty paragraph will be created.

[Reinmar]

And I'll close this ticket. It was originally reported to handle the situation where you initialise the editor on a completely empty content and we fixed that. Other considerations, especially magic-line oriented ones, should be handled separately (#407).