Improve keyboard navigation across blocks

[mcsf]

This is an umbrella issue to group tasks and coordinate efforts to improve keyboard navigation in and across blocks. Key concerns include accessibility, but also making sure the block abstraction and our block-wise implementation details don’t get in the way of a user’s writing flow, who may expect the same fluidity and predictability of movement as when using a conventional word processor.

Some current issues are:

• intangibly suboptimal perceived performance when moving up and down between paragraphs, partly due to the moving happening on keyup rather than keydown (see reason) fixed by Block navigation with keydown #2979;
• for this reason, it isn’t possible to move between paragraphs by keeping the arrow keys pressed (Block navigation doesn't work when arrow keys are held down #2976) fixed by Block navigation with keydown #2979;
• caret position in a line isn’t preserved when moving between paragraphs; a solution could involve the in-flux browser-native caretPositionFromPoint / caretRangeFromPoint methods (see also TinyMCE’s polyfill: doc, source) → open PR Vertical arrow key navigation #2988;
• paragraph multi-selection is achievable with mouse selection, but not with the traditional shift+arrow keyboard method; @iseulde has been working on this front (Multi select on shift+click #1965, Multi-select: try no buffer and lower throttle delay #2935, Remove multi-selection header #2934), as well as on pasting.

I cite these examples because I’d like to recommend that we try to properly abstract these capabilities and neatly separate concerns, ideally by improving or mimicking WritingFlow.

[ellatrix]

#2988 uses the native caretRangeFromPoint (widely supported now). I don't think we have to use the TinyMCE APIs here, especially since we decided a while ago to separate this from editable and make it more general.

As soon as #2934 is merged, I can rebase the shift+click PR. #2934 fixes quite a few bugs with multi-select in general.

[ellatrix]

One of the questions with shift+arrow key (not shift+click) is what to do when there's multiple editable areas in a block. What should happen if the following focusable elements is an editable in the same block? Should this behaviour be part of WritingFlow at all? shift+click for example is not, because it's purely on a block level. @mtias @jasmussen Any ideas here?

[jasmussen]

If you are starting the shift-selection across blocks from a text block and into a block with multiple edtiables, it's no problem because as soon as you cross the block boundary it becomes block level selection.

If you start the selection inside a complex block, you select the block first?

I.e. let's say you just inserted an image, and now have focus inside the caption input field. If you press shift up you first select the entire image block, and then you start select the preceeding blocks.

Let's say you have a quote with a citation, and you set the caret inside the quote, select until the end of the quote, and press shift down (towards the citation) — then you select the whole quote block first, and then you select successive blocks if you continue.

What do you think? Does that make sense?

[ellatrix]

Let's say you have a quote with a citation, and you set the caret inside the quote, select until the end of the quote, and press shift down (towards the citation) — then you select the whole quote block first, and then you select successive blocks if you continue.

Thanks, that last bit is what I needed to know. Seems evident now that you say it. :D

[ephox-mogran]

I've given multi-block selection with the keyboard a go. The PR is #3038

[afercia]

See also #2031

[ellatrix]

I think all that's left here is #3232 (#2990 (comment))?

[mcsf]

I think all that's left here is #3232 (#2990 (comment))?

Also #3244, which I've just added.

[ellatrix]

Something else we might want to look into: when making a selection with the mouse, it used to be that you could just return to the editable and still move the selection there without any extra clicks. Somewhere this got broken. When you go back to the editable now, the selection is frozen to the point where the mouse left the editable area.

[mtias]

@mcsf @iseulde what's the status here, do we need to keep this issue open?

[mcsf]

Considering that this issue's main purpose was to raise awareness and aggregate related issues, I'm OK if we close it: new issues have been opened and they can typically be found via the labels Writing Flow and Accessibility.

However, closing this shouldn't be taken as a sign that work is done. #3999, #4004 and many others are still open and sometimes glaring.