-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backspace should not change the type of the trailing block (probably shouldn't merge it at all) #6680
Comments
What does it work like in other editors? |
Yeah, it happens to me too whenever I use shift + down arrow key to select blocks. Funny I never reported it... Just a note to be careful when working on it, so that the way how CKEditor 5 handles backspace did not break lists handling (if it may be in some way influenced by the fix implemented to solve this issue at all). |
Selection cases1. Vertical selection (mouse or keyboard)Mouse dragged vertically along the block elements (or keyboard up / down arrows) makes the selection expand to the start of next block element. 2. Mouse tripple-click selectionBehaves exactly as vertical selection (includes start of next block element). 3. Horizontal selection (mouse or keyboard)Mouse dragged horizontally over the block elements (or keyboard Shift + left / right / home / end arrows) does not expand the selection to any other block element. 4. DeleteCommandIt's expanding the selection by one character in the direction of the command (Backspace - "backward", Delete - "forward") and then triggering 5. EnterCommandFor the expanded selection is triggering 6. Paste from ClipboardContent in clipboard does not contain trailing newline and after pasting it in front of some block they are merged. |
ProblemsCases 1 and 2 - the selection includes the start position of next block elementAfter deleting content the following block element should keep its type and attributes no matter whether it was Delete or Backspace (GDocs behave in this way). Case 3 - the selection doesn't include next blockThis case works as in GDocs and seems reasonable. Case 4 - DeleteCommand with empty block before the selectionSince Case 5 - EnterCommandSelection should not jump to the start position of following block element. Case 6 - Paste from ClipboardThe clipboard data should contain trailing block if it was selected with it while copying/cutting. |
Described expected behavior is not sth GDocs do.
GDocs results with:
But title of this issue "Backspace should not change the type of the trailing block" is a valid point of the need of not merging those blocks as we do it currently and this is really annoying UX. How this currently works is a result of OT's preferred way of handling such situations, but as discussed in #4434 there is an option of "right-merging" those elements. From cases described above there are 3 areas where we can improve:
|
The I think there should be followups for:
|
After f2f talk with @Reinmar - there is one more use case: Due to behavior of Enter (which is consistent with GDocs and Pages) after removing whole paragraphs hitting Enter creates another header block but in this scenario paragraph would be more reasonable so it seems it's better to not merge them. So more user friendly behavior would be (despite it's not consistent with other editors): |
Fix (engine): Backspace will not change the type of the trailing block. Closes #6680.
📝 Provide detailed reproduction steps (if any)
When having the following selection:
I expect to end with this after pressing Backspace:
Actual result
The format of the trailing block is changed to the format of the former block. Technically speaking, the heading is being merged into the first paragraph.
UX
This is especially irritating when you try to delete e.g. paragraphs between 2 headings:
I get the "Proposal" heading turned into a paragraph. What I'd expect is having the two paragraphs above deleted, one left and the heading not touched at all:
Background
The trailing block problem is a well-known DOM selection representation issue. For instance, when you triple-click a line of text to select the entire line, the selection looks like this:
Unfortunately:
We already handled this situation in the
selection.getSelectedBlocks()
method, so e.g. when yoy apply a block format to this selection, it does not affect the "Foo" block.It'd now be good to also handle this in
deleteContent()
by simply ignoring the trailing block if the selection starts at its beginning.If you'd like to see this fixed sooner, add a 👍 reaction to this post.
The text was updated successfully, but these errors were encountered: