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

Keyboard navigation: Support PageUp/PageDown, Home/End #4004

Closed
2 tasks
mcsf opened this issue Dec 14, 2017 · 2 comments
Closed
2 tasks

Keyboard navigation: Support PageUp/PageDown, Home/End #4004

mcsf opened this issue Dec 14, 2017 · 2 comments
Labels
[Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Enhancement A suggestion for improvement.

Comments

@mcsf
Copy link
Contributor

mcsf commented Dec 14, 2017

Part of #2990.

Issue Overview

When editing with a keyboard, the arrow keys move the caret within and between blocks, as expected. However, a user arguably expects to be able to quickly cover great lengths of content using the PageUp, PageDown, Home and End (UDHE) virtual keys.

N.B.: These keys are nowadays less commonly found as physical keys on a keyboard, but attainable with the arrow keys combined with modifiers such as Fn, Ctrl, depending on the platform, hence the term virtual.

Currently, UDHE scroll the content as expected of a browser page, but never affect caret placement. In other words, suppose that a very long post with many paragraphs is loaded, and that the caret is sitting on the first character of the first block. Pressing PageDown or End will scroll away from that position and that block, other blocks will move into sight, but the caret disappears, since it remained at its initial position. As the user now sees the paragraph at the bottom of the editor, they may press the arrow keys (or immediately enter text) hoping to see the caret appear there; instead, the editor immediately scrolls back to the top. In the end, there is no way to move the caret to the bottom except for:

  • pressing all the way to the bottom, moving the caret one line at a time, or
  • using the pointer to reposition the caret.

Prior art

The described expected behavior can be experienced in conventional word processors.

Possible Solution

Screenshots / Video

Related Issues and/or PRs

Todos

  • Tests
  • Documentation
@mcsf mcsf added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... Needs Design Feedback Needs general design feedback. labels Dec 14, 2017
@karmatosed
Copy link
Member

I just tried in Google docs and on a mac 'Fn + Arrow' seem to work. It's not super discoverable though. if we have to pick one that feels like a solid one to follow as an expected, but hidden pattern.

@karmatosed karmatosed removed the Needs Design Feedback Needs general design feedback. label Jan 3, 2018
@mcsf mcsf added the [Type] Enhancement A suggestion for improvement. label Jul 9, 2018
@mcsf
Copy link
Contributor Author

mcsf commented Jul 9, 2018

Marked as Enhancement, since no such feature is found in Classic. Further, closing due to inactivity and inferred low interest. One can always reopen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

2 participants