Split out from #162, which decided Tab/Shift+Tab inside a Document block's rich-text content are left to native browser focus order rather than doing anything block-aware (see PR #274, rich-text-toolbar.md §5.5).
The alternative meaning — Tab indents a list item, Shift+Tab outdents it, the standard word-processor/outliner convention — was deliberately not chosen there, because there's no list-nesting concept to indent into: WorkspaceRecord/ViewConfig (data-model.md) has no representation for a list item being a child of another list item. Building that is a real data-model design decision (parent/child list semantics, how it interacts with parentId/ordering, Markdown transcoding for nested lists, MCP tool surface implications), not a keyboard-handler change — and the 0.4.0 editor UX research brief explicitly scopes the block-actions/outline work to move/duplicate/delete/convert and multi-select, "not arbitrary nested data semantics yet."
Not in scope: reopening #162's Tab-as-focus-order decision — that stands regardless of this issue's outcome, unless a future design specifically chooses to override native focus order for it.
Done when: there's an explicit decision (data-model.md updated either with a nesting design, or with a recorded "not doing this" rationale) and, if nesting is built, an intentional documented behavior for indent/outdent.
Split out from #162, which decided Tab/Shift+Tab inside a Document block's rich-text content are left to native browser focus order rather than doing anything block-aware (see PR #274,
rich-text-toolbar.md§5.5).The alternative meaning — Tab indents a list item, Shift+Tab outdents it, the standard word-processor/outliner convention — was deliberately not chosen there, because there's no list-nesting concept to indent into:
WorkspaceRecord/ViewConfig(data-model.md) has no representation for a list item being a child of another list item. Building that is a real data-model design decision (parent/child list semantics, how it interacts withparentId/ordering, Markdown transcoding for nested lists, MCP tool surface implications), not a keyboard-handler change — and the 0.4.0 editor UX research brief explicitly scopes the block-actions/outline work to move/duplicate/delete/convert and multi-select, "not arbitrary nested data semantics yet."Not in scope: reopening #162's Tab-as-focus-order decision — that stands regardless of this issue's outcome, unless a future design specifically chooses to override native focus order for it.
Done when: there's an explicit decision (data-model.md updated either with a nesting design, or with a recorded "not doing this" rationale) and, if nesting is built, an intentional documented behavior for indent/outdent.