Writing flow: fix tab behaviour #30000
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: +77 B (0%) Total Size: 1.41 MB
ℹ️ View Unchanged
|
ellatrix
force-pushed
the
fix/writing-flow-tab
branch
from
58f948c to
f00d391
Compare
gziolo
added
the
[Feature] Writing Flow
ellatrix
force-pushed
the
fix/writing-flow-tab
branch
3 times, most recently
from
539d2db to
9a17527
Compare
7 tasks
ellatrix
force-pushed
the
fix/writing-flow-tab
branch
from
9a17527 to
e1b227d
Compare
ellatrix
force-pushed
the
fix/writing-flow-tab
branch
3 times, most recently
from
35e2a04 to
6e71345
Compare
|
This seems solid. Merging. Let me know if there's any issues. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Discovered in #29874 (comment).
Currently tab behaviour from a field in a block is unexpectedly moving focus within the block rather than before or after the editor area (toolbar or inspector). This is not consistent with the behaviour that was originally proposed and implemented in #19235. The "specification" we should be following is that of a
textarea: the editable field containing all blocks is a single tab stop.See the existing comment at
gutenberg/packages/block-editor/src/components/writing-flow/index.js
Lines 393 to 398 in 45715c4
A nice side effect of making the behaviour more consistent is that it reduces the complexity of writing flow.
One exception that I encountered is when there are form elements within a block, for example as part of a placeholder, in which case the controls can be considered to be editor UI. In that case we should allow navigating by Tab between those controls. Ideally, in the future, these controls should be placed in an iframe so that both the editor UI styling and the Tab behaviour is isolated from the content.
How has this been tested?
Create an image block and focus the caption. Press Shift+Tab. The toolbar should receive focus, not the block wrapper.
Similarly for a table, Tab from any table cell should focus the toolbar or inspector, not the next/previous table cell. Arrow keys must be used for content navigation like you would in a text area or normal content editable area.
Screenshots
Types of changes
Bug fix.
Checklist: