Should a keystroke be always disabled when a related command is disabled?

[oleq]

A follow-up of ckeditor/ckeditor5-code-block#1 (comment).

Problem

Use case with lists

1. Create a list with 2 items.
2. Move the selection to the second one.
3. Tab to indent.
4. Tab to indent again.

There's no way to indent more so the indent command is disabled so is the Tab keystroke. When the user hits Tab, it falls back to default behavior that cycles focus on the entire webpage. This could be very confusing because you edit some lists and then suddenly you're somewhere else.

Use case with code blocks

1. Create a code block.
2. Indent some line.
3. Put selection in that line.
4. Shift+Tab to outdent.
5. Shift+Tab to outdent again (even if there's no indentation left).

Again, when the user hits Tab, it falls back to default behavior that cycles focus on the entire webpage. And again, this could be very confusing because you edit some code and then suddenly you're somewhere else.

Comment

I think we should not bind keystrokes blindly to the commands they execute. It's a confusing UX that the keystroke changes it's behavior despite staying in the same context (list, code block).

WDYT?

@dkonopka @Reinmar @mlewand

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).