Skip to content
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

Closed
4 of 20 tasks
azaozz opened this issue Mar 4, 2017 · 20 comments
Closed
4 of 20 tasks

Simple text interactions #179

azaozz opened this issue Mar 4, 2017 · 20 comments
Assignees
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Question Questions about the design or development of the editor. [Type] Technical Prototype Offers a technical exploration into an idea as an example of what's possible

Comments

@azaozz
Copy link
Contributor

azaozz commented Mar 4, 2017

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.

@mtias mtias added [Type] Question Questions about the design or development of the editor. [Type] Technical Prototype Offers a technical exploration into an idea as an example of what's possible labels Mar 7, 2017
@afercia
Copy link
Contributor

afercia commented Mar 15, 2017

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.

This was referenced Mar 29, 2017
@afercia afercia added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Apr 29, 2017
@ellatrix ellatrix self-assigned this Jun 21, 2017
@swissspidy
Copy link
Member

Another thing that needs to be considered: Select all content using Cmd+A / Ctrl+A. Right now, this doesn't work.

@ellatrix
Copy link
Member

See #3 and #1211.

@nylen
Copy link
Member

nylen commented Jul 7, 2017

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.

@nylen nylen reopened this Jul 7, 2017
@ellatrix
Copy link
Member

ellatrix commented Jul 7, 2017

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.

@ellatrix
Copy link
Member

ellatrix commented Jul 19, 2017

Notes (WIP):

  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.
  1. 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.

✅ 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.

  1. 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.
  1. 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.

🚧 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.

  1. 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.
  1. 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.

🚧 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.

  1. 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).
  1. 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).
  1. Repeat 7 but paste one word. The word should be between the colored text with the top paragraph color (in the top span).
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.

⚠️ I'm sot sure if such granular control is needed? E.g. you can delete part of the first paragraph and part of the second. I'm not sure if it's common to delete two halves of a paragraph (which should have a break in content per the definition of a paragraph). Paragraphs, headings, lists etc. should all be natural breaks in content. With Gutenberg, we may actually encourage writing better coherent paragraphs. 🙂

  1. 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.

✅ 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.

  1. 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.

✅ Works.

  1. 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.

✅ I does work, but I think we need to clean up and handle paste better.

  1. 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.)

✅ Works, but can probably be tweaked so it works better. See 18. That seems to be default MCE behaviour though.

  1. 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.

⚠️ We disabled drag on text. You can copy paste instead. We could probably enable this again, and limit dragging to just text (no images).

@ellatrix
Copy link
Member

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.:

  • I have written a large article while thoughts were pouring out of my head. I now wish to rearrange my sentences and clean things up a bit. I will need to be able to:
    • Adjust sentences (no problem).
    • Remove sentences, possibly in bulk. As long as I need to remove just one or two sentences in a paragraph, or a whole paragraph, this is no problem. I'm running into problems when I want to delete part of two or more paragraphs. Normally I can do that, and the rest will merge together.
    • Similarly I run into problems when I'd like to move part of two or more paragraphs. I'm forced to move it around, or copy paste, by whole paragraphs.

What other problems are there? What flows do you have that Gutenberg hinders?

@aduth
Copy link
Member

aduth commented Jul 25, 2017

A few flows I've shared before which are common to my drafting needs:

Partially select across paragraphs and either delete to collapse, or start typing to replace:

Select Across

Arrow down from one paragraph to the next and have caret at same relative position:

Arrow Down

@ellatrix
Copy link
Member

ellatrix commented Jul 25, 2017

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.

@aduth
Copy link
Member

aduth commented Jul 25, 2017

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:

Down Current

@ellatrix
Copy link
Member

I've tried contentEditable on the wrapper with a few different approaches, but either it doesn't work, there are focus issues, or it is unreliable (on input, MCE will suddenly see the top content editable as the root)... I've also triggered a white screen a few times without any errors, so I'm giving up on this idea entirely. @youknowriad Do you think there are any good approaches to this?

@ellatrix
Copy link
Member

Ideally I was looking for something like this:

screenshot 2017-07-25 20 19 16

@youknowriad
Copy link
Contributor

@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)...

@ellatrix
Copy link
Member

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.

@nylen
Copy link
Member

nylen commented Jul 26, 2017

Partially select across paragraphs and either delete to collapse, or start typing to replace

Arrow down from one paragraph to the next and have caret at same relative position

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 contenteditable elements.

We can get the coordinates on key down, and place it back

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":

Arrow Down

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.

@ellatrix
Copy link
Member

ellatrix commented Aug 5, 2017

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).

@aduth
Copy link
Member

aduth commented Aug 7, 2017

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)

@ellatrix
Copy link
Member

ellatrix commented Aug 7, 2017

@aduth Interesting. I wonder how that affects accessibility.

@ZebulanStanphill
Copy link
Member

ZebulanStanphill commented Apr 12, 2018

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 <br /> tag, which is kind of weird, and the rest of the list items turn into their own separate Paragraph blocks. I think this behavior is confusing and probably not intended.

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 <p> tags into a <li> and it will be considered valid, but there is no way to do this through pasting content.

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.

@mcsf
Copy link
Contributor

mcsf commented Jul 16, 2018

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:

  • 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. • Marked as something not to implement, incompatible with other interaction methods.
  • 1–15. All of these are cross-block interactions, which is a topic tracked in Gutenberg cross-block selection #3629.

Thus, I'm closing this one. 👏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Question Questions about the design or development of the editor. [Type] Technical Prototype Offers a technical exploration into an idea as an example of what's possible
Projects
None yet
Development

No branches or pull requests