WIP: Try vertical arrow key navigation in WritingFlow

[talldan]

Description

Iteration on #16957, which attempts to bring vertical arrow key navigation to the WritingFlow component.

When an up/down arrow key is pressed searches in the relevant direction from the caret until a tabbable text field is found. If none is found, tries searching from the right and left of the caret upwards or downwards until a tabbable is found.

How has this been tested?

Screenshots

Types of changes

New feature (non-breaking change which adds functionality)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[talldan]

This works ok for now, but would fail if the element at the point was some formatting. A solution would be to check parent elements as well.

There is also elementsFromPoint, which although marked on MDN as experimental, seems to be pretty widely supported:
https://developer.mozilla.org/en-US/docs/Web/API/DocumentOrShadowRoot/elementsFromPoint

[talldan]

@ellatrix This is a very early attempt at what we discussed in https://github.com/WordPress/gutenberg/pull/16957—vertical keyboard nav based on element screen positioning.

It seems to work ok so far. I'm not sure how I'd handle something like Cmd+Up to get straight to the top of a range, but for single arrow key presses it seems surprisingly ok!

[talldan]

I thought of a drawback of this approach—there'll be issues with some elements like toolbars covering nearby inputs. Ideally there would be a way to filter out those elements from the search for a tabbable element.

[ellatrix]

I thought of a drawback of this approach—there'll be issues with some elements like toolbars covering nearby inputs. Ideally there would be a way to filter out those elements from the search for a tabbable element.

This should not happen with hiddenCaretRangeFromPoint.

[talldan]

I've switched to using elementsFromPoint which also solves the issue of overlapping elements.

This does seem to work pretty well in my testing so far. Not sure if there are any additional things I need to think about.

Potentially I should constrain the functionality to the bounds of the WritingFlow container.

Another feature that I'm thinking about implementing is the use of Cmd/Ctrl with arrow keys keys to move straight to a table or grid's boundaries (as I had in my table block PR #16957).

I think that could be considered on a separate PR and work on this incrementally.

[talldan]

Ah, I've realised this little experiment of using elementsFromPoint doesn't work as it's unable to navigate to elements that are off-screen. I'll have to rework the PR. I think a good approach would be getting a list of focusableNodes, filtering out those that aren't above/below the caret, and then sorting based on vector distance.

[ellatrix]

Ah, I've realised this little experiment of using elementsFromPoint doesn't work as it's unable to navigate to elements that are off-screen. I'll have to rework the PR.

Have you had a look at how we approach this vertically? I believe we try to scroll, then look again etc., but I'd have to check. Ideally the implementation is very similar so logic can be reused. This can be found in the DOM package.

Otherwise I think the work done here is very promising! Would it be possible to write some e2e test, similar to the ones we have for vertical navigation?

[talldan]

@ellatrix I've taken a different approach now, selecting the tabbable that's closest in distance. It seems to work better than before, and I don't have to worry if the element is off-screen.

I need to consider how it'll work when navigating between blocks, but so far so good.

I'll have a look at writing some e2e tests.

[talldan]

Superceded by #22105