Skip to content

Decide and implement Tab/Shift+Tab semantics for Document blocks #162

Description

@brylie

Split out from #158's third checklist item. #158 (ArrowUp/ArrowDown cross-block navigation) is implemented in PR #160 — a keyboard-only user can already move between all Document blocks without a mouse using the arrow keys, meeting #158's "Done when" bar. Tab itself, however, still does nothing block-aware: it just moves focus past the whole block list to the next unrelated control (e.g. the "Add block" button).

This is deliberately not implemented as part of #158, because there's no existing indent concept in the data model (WorkspaceRecord/ViewConfig) to hook a Shift+Tab-outdent onto — giving Tab a meaning here (block-to-block focus move? list-item indent, which would need new data-model support? both, context-dependently?) is a real product/UX decision, not a quick addition.

  • Decide what Tab/Shift+Tab should do inside a Document block editor (indent vs. block-to-block focus move vs. no-op-by-design)
  • If indent is chosen: design how that's represented in the data model (list nesting doesn't currently exist)
  • Implement and test the decided behavior

Done when: Tab/Shift+Tab inside a block editor has an intentional, documented, tested behavior (even if that behavior is "left to native focus order, and here's why").

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wantedExtra attention is needed

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions