-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Simple text interactions #179
Comments
About basic navigation through text and selection of text using only the keyboard, I'd totally second that anything that works in a textarea should work exactly in the same way in the editor. Also, some screen readers have additional features to navigate through text, for example VoiceOver allows to navigate text by paragraph and by sentence, in addition to the more "classical" navigation by line, by word, and by character. The more the implementation is closer to native HTML elements, the more all this will work. |
Another thing that needs to be considered: Select all content using Cmd+A / Ctrl+A. Right now, this doesn't work. |
This issue represents a set of common writing flows that reflect a large range of "traditional" editing operations. It's clear that we are taking the editor in a different direction than a traditional writing experience, but the reasons for this [edit: specifically, breaking up the flow of writing into one block per paragraph] haven't really been explained publicly. We've already seen a good bit of user feedback related to this set of issues, and I expect to see a lot more. We are implementing some basic behaviors in this area, such as arrow keys to move between blocks (#1161 and #1778). This exploration should also continue with the goal of removing friction while writing and especially while transitioning over to the new editor. |
There's quite of few things here we can still address, even after #1778. One of these days I'll try to get the the multi-select with arrow keys to work. |
Notes (WIP):
✅ For Gutenberg, hold and drag will trigger multi block selection. Holding and moving the pointer from a block to another block will select both and all the blocks in between.
🚧 See #1965. I'd propose to do this similarly to hold + move the pointer. If a block is selected and you hold SHIFT and click in another, both blocks will be selected + all the blocks in between.
🚧 I'd propose to do this similarly to hold + move the pointer. As soon as you reach the end of the block, you select block per block on arrow up or down. This would be similar to the shortcut for selecting multiple paragraphs, but instead of halves, it selects whole blocks. We won't be able to give such granular control though, and I wonder if it's needed. What's a good use case? Maybe once I have a use case, there maybe be other ways to achieve the same end result.
✅ Works for paragraphs and headings at the moment, and in a block quote paragraphs will be split as well. There is discussion to change the ENTER behaviour back to double line instead of single line.
✅ Works.
✅ I does work, but I think we need to clean up and handle paste better.
✅ Works, but can probably be tweaked so it works better. See 18. That seems to be default MCE behaviour though.
|
I'll take some of the inter paragraph selection comments back, I agree it's useful when you're editing an article and you need to move sentences around. I wonder if we could come up with any better flow? I think it's important that we list our the current flows here, so we know exactly what needs to be addressed. I know that @azaozz listed some, but a lot of them seem to be similar without much context. Let's try to boil this down to a list of things that explains what it's trying to achieve and what the needs are. E.g.:
What other problems are there? What flows do you have that Gutenberg hinders? |
Thanks @aduth! The first one is exactly what I tried to describe above. Concerning the second, is it a lot more annoying for you that the cursor moves to the start? To me, compared to the first flow, it seems like a nice to have, but something that can be lived with. Solving one would likely solve the other though, but I'm just trying to figure out the major issues. |
I wouldn't go so far as to say I'm dependent on the behavior, but rather have become so accustomed to it that anything else "breaks my flow". At the very least, I would like for us to ensure that pressing down a single time from the last line in a paragraph moves to the next text block. Currently it moves to the end of the current text block, and requires a second down press to continue: |
I've tried |
@iseulde short answer: No :) I tried several approaches too and they all seem "fragile" and break easily. I honestly think that what we currently have is a good compromise (the multi selection selecting the whole blocks), we should focus on improving its edgecases: copy/pasting, adding some controls maybe (multiple transformations or something like that)... |
I feel a bit annoyed with myself that I haven't found a proper solution for this. I actually think that the arrow key navigation is solvable, even without a wrapper content editable or anything like that. We can get the coordinates on key down, and place it back with https://github.com/tinymce/tinymce/blob/4.6.4/src/core/src/main/js/dom/Selection.js#L949... But the selection is a really tough problem to solve, and it seem that's the only problem there really is with the current approach in master. |
These are the exact two flows that I use extremely frequently, and it would significantly degrade usability for me personally if they don't work as expected. Especially the first one, which is far more difficult (and may be impossible) when using separate
The actual behavior of arrow up/down is more complicated than that. In @aduth's gif from above, watch the cursor as it moves from "Nam", down to "diam" (the last word of a short line), then down again to "libero": Using the behavior you propose, the cursor would instead move to "Praesent" in the second paragraph. I think this is probably OK, just worth noting. |
Today I’ve looked a bit more into our cross block selection problem (I know, I know), and I have found something. It works in Chrome and Firefox without any problems so far. Safari is buggy, but may find a solution. The idea is to disable contentEditable as soon as there is multi selection. So far in Chrome and Firefox the browser takes over the selection anchor, so you can just continue your selection. Of course we'll need to add some logic to delete that selection and merge the blocks (since it's not editable), but that's doable. We also don't need formatting here, I think it's good to limit that per paragraph. The main thing seems to be delete, maybe copy too. The other thing is keyboard selection. For that as well we can take the same approach, though that would require some more code. As soon as you reach the end of the current editable, we can disable contentEditable, set the selection back, and you can continue you selection as normal. The great thing about disabling contentEditable is that it is way less fragile than enabling on a parent. At this point I'm not going to look further into it, as I think other things are more urgent, but this seems like a path worth exploring once we have some time to look into it. Or I might pick it up again some weekend. I pushed the experiment on https://github.com/WordPress/gutenberg/tree/try/select-cross-block (only consequential paragraphs). |
Another thought: by default, nothing is contenteditable, but in response to selection becomes contenteditable by a common wrapper. Demo: https://codepen.io/aduth/pen/gxmpYv (works on left-to-right selection, no multi-selection) |
@aduth Interesting. I wonder how that affects accessibility. |
Disclaimer: I am not a WordPress or Gutenberg developer. Interactions 1 through 13 are currently not possible with the current way multiple block selection works. I am not sure how this could be worked around without having to give up the currently fairly simple UX for selecting multiple blocks. I am fine with giving up cross-block text selection in exchange for the simple multiple block selection, but I do not know if other people feel the same. See also: #3629. Interaction 14 seems to be possible. Currently, pressing backspace when the caret is at the start of a List block will merge the first list item with the paragraph (under the rest of the paragraph and put on a newline via a Interaction 15 is kind of implemented, but with a slight difference. The quote is put on a new list item, and the citation is put on another list item. I am fine with this behavior, but what about you? Interaction 16 is already implemented for Paragraph blocks. As for the Quote block, It currently just creates a new paragraph within the Quote block. I think this is the best behavior, since a quoted source can contain more than one paragraph. Additionally, it should be noted that the Quote block is being reworked in #6054 to use nested blocks like Paragraph blocks and possibly also List and Heading blocks (since a quoted source may contain those), though the paragraph-splitting behavior will basically be the same as it is now since the paragraph-in-Quote-block behavior appears to be identical to the Paragraph block behavior with regard to splitting. I would say that this interaction could be checked off the list. Interaction 17 is implemented and seems to work exactly like you wanted! I think you can check this off the list. Interaction 18 does not yet work, but with the upcoming rework of Quote blocks to use nested blocks, it will probably start working, since the behavior should be the same as it is for Paragraph blocks outside of a Quote block. Interaction 19 does not happen the way you described, but the current behavior is not bad either. The list item you paste into is split into 2 list items, and the pasted paragraphs each become list items in between them. If you use the "Edit as HTML" option, you can insert Interaction 20 does not work. When you try to drag text, it does nothing until you reach another block, at which point the multiple block selection kicks in. I am not sure if this behavior can be changed without interfering with the multiple block selection logic or not. It might be impossible to implement with the current implementation of multiple block selection. |
We've come a long way since opening this issue. :) Per comments on the thread and my own retesting, I've checked the boxes for implemented interactions, leaving out only:
Thus, I'm closing this one. 👏 |
All of these come "built-in" the single editor (because contenteditable). They also work in pretty much all text editors (including textareas). None of them currently works in the "per-block" editor. If decided to build that editor, all of these can be considered blockers. Also, most/all of these interactions are essential for accessibility.
To test: add four text blocks: paragraph, a list with 3-4 items, a blockquote, another paragraph. Select some of the text in the middle of the paragraphs and make it different color (add spans). Select some other text and make it a link.
1. Click in the middle of the first block and drag to the middle of the second. Should select the bottom half of the first and top half of the second.
2. Click in the middle of the first block and drag to the middle of the fourth. Should select the bottom half of the first, all of the second and third, and the top half of the fourth.
3. Click in the middle of the first block. Hold down Shift and click in the middle of the second. Should select the bottom half of the first and top half of the second.
4. Click in the middle of the first block. Hold down Shift and click in the middle of the fourth. Should select the bottom half of the first, all of the second and third, and the top half of the fourth.
5. Click in the middle of the first block. Hold down Shift and press the down arrow until you reach the middle of the second. Should select the bottom half of the first and top half of the second. Repeat and use the right arrow, then click in the second block and use the up and left arrows.
6. Click in the middle of the first block. Hold down Shift and press the down arrow until you reach the middle of the fourth. Should select the bottom half of the first, all of the second and third, and the top half of the fourth.
7. Select from the middle of the colored text in the first paragraph to the middle of the colored text in the last paragraph. Press Backspace. The selection should be deleted and the unselected parts of the colored text should be next to one another (colors should still be there).
8. Repeat 7 but instead of Backspace type one letter. The letter should be in the middle of the colored text with the top paragraph color (in the top span).
9. Repeat 7 but paste one word. The word should be between the colored text with the top paragraph color (in the top span).
10. Repeat 7 and paste 2-3 more paragraphs (copied from another wen page). The selection should be deleted, and the paragraphs should be inserted splitting the top and bottom paragraphs.
11. Select from the middle of the top paragraph to the second list item. Press Backspace. The top paragraph and the list should be truncated but stay separate blocks.
12. Select from the second list item to the middle of the blockquote. Press Backspace. The selection should be deleted and the remaining text from blockquote should be merged with the list item. The blockquote should be removed.
13. Select from the middle of the blockquote to the middle of the following paragraph. Press Backspace. The remaining text from the paragraph should be merged with the text in the blockquote.
14. Place the caret at the beginning of the list. Press Backspace. The first list item should be merged with the above paragraph and removed from the list.
15. Place the caret at the end of the last item in the list. Press Delete. The text from the blockquote should be merged with the last list item and the blockquote block removed.
16. Place the caret in the middle of the top paragraph. Press Enter. The paragraph should be split into two paragraphs. Repeat with the blockquote, should be split in two.
17. Copy few paragraphs from another web page (can also contain headers). Place the caret in the middle of the top paragraph. Paste. The top paragraph should be split into two and the pasted paragraphs should be between. Repeat with the blockquote.
18. Copy few paragraphs from another web page (can also contain headers). Place the caret in the middle of the blockquote. Paste. The text of the blockquote should be split into two and the pasted paragraphs should be between. All should still be inside the blockquote.
19. Copy few paragraphs from another web page (can also contain headers). Place the caret in the middle of one of the list items. Paste. The text of the list item should be split into two and the pasted paragraphs should be between. All should still be inside the list item. (By default in HTML blockquotes and list items are blocks that can contain other blocks.)
20. Select some text in one of the paragraphs. Drag it to a list item or the blockquote. The text should be removed from the paragraph and added to the other block.
There may be cases that I've missed. Please add them in the comments.
The text was updated successfully, but these errors were encountered: