Enter key behaviour

[Comandeer]

As it is widely known, Enter key is used to create new line in "classic" text editors (MS Word, LibreOffice Writer, etc.):

• Enter creates new paragraph/block of text;
• Shift + Enter inserts new line into the current paragraph;
• Ctrl + Enter inserts page break.

Therefore users are expecting similar behaviour from online WYSIWYG editors:

• Enter should create the p element (paragraph); there is also possibility to create the div element (block), but it has no semantic meaning;
• Shift + Enter should create the br element (line break); creating new p element could be counter-intuitive (and it changes the semantics of the text);
• Ctrl + Enter – I don't really know how to handle that… inserting form feed and marking it with some visual element (span)?

The use-case for Enter is obvious.

For Shift + Enter I could think of poems or address blocks (so texts where line break doesn't indicate change of topic, but it's purely a typographic convention):

<p>Comandeer<br>
Test Street 56<br>
GhostTown</p>

Use-case for Ctrl + Enter is dependent of the context, e.g. unprintable texts (blog article, e-mail…) does not need that sort of features, but online book creator – needs it badly.

---

To sum up: by default editor should:

• create new paragraphs (p elements) on Enter key
• create line breaks (br elements) on Shift + Enter key

Am I missing something or it sounds reasonable?

I've also made a small research how online WYSIWYG handle that keys now: https://gist.github.com/Comandeer/5f47231c7683a09c7374

[fredck]

That's a good start and it sums up well the basics of it. The only point of debate on those aspects is whether Enter should produce br.

I agree with the proposal that Enter should care about the semantical value of its behavior in undoubtedly break text into p elements.

This issue is much broader though. We need to come to an agreement on how Enter will behave on non plain paragraph contexts, like titles, lists, tables, pre-formatted text, etc.

[Reinmar]

I would be very strict about one thing – if the current selection position supports block content, the Enter must work on the block level (e.g. split the <p>). If the selection position doesn't allow blocks, the Enter would work like Shift + Enter. If <br> isn't allowed, then Enter should be disabled.

In other words, there are 3 modes: block, soft, disabled. The Enter tries to execute 1st or 2nd mode (in this order). The Shift + Enter tries only the 2nd mode.

I'm also trying to express here that this behaviour should not be configurable. The enter key behaviour should only depend on the data model (its schema) and the current selection position. Otherwise developers tend to break the editor.

And the last requirement in my opinion is that lists, headings and other blocks are special types of blocks. No type (or default type) == paragraph. Hence, paragraph must be enabled for other types to be enabled as well. For instance, you shouldn't be able to have lists when paragraphs are forbidden, because that leads to ridiculous situations and makes enter key (and other features) implementation a nightmare.

[Comandeer]

Ok, I've created the first version of draft.

Only the general behavior is included, so creating new block context and inserting a line break. There is also a note that the default block context is a paragraph, but it could be changed by a certain feature.

[Comandeer]

Ok, it seems like a stable feature. I propose moving it from draft to the recommendation status. I'll wait 3 days for objections and then do what should be done ;)