Implement FocusSelectableCommand('previous|next')

[johannesmutter]

Expected behaviour:

jump to next / previous focusable text property.

what's actually happening:

focus jumps to other focusable html elements outside of svedit doc, e.g. in demo to "GitHub Stars" button then "Browser Addressbar".

[michael]

We use one top-level contenteditable, and that's the only focusable thing we have natively.

I'm not sure about this one. I guess it's also something for app land, you can add a handler for the TAB key, and set the selection to the next focusable thing within the document.

ProseMirror doesn't handle TAB as well. You'll just jump out of the editable document to the next focusable thing.

[johannesmutter]

IMHO just because contenteditable or prosemirror have no concept for Tab key behaviour / are treated as a single focusable thing, doesn't mean it's a behaviour that should be ignored. Ask yourself what would your or another user expect when pressing the tab key when there's a bunch of fields in front of them, very much visually and from behaviour similar to a regular html form.

Made a PR here with more detailed reasoning why I think this should be core:
#158

[michael]

My main concern is that it's not clear to me what the expectation of pressing TAB in a rich text editor (or website editor) is.

In your view, a document is a collection of focusable fields that you can reach via TAB. In forms you can't reach other fields with the cursor keys, so there has to be some way to get from one textarea to the next, and finally to select the submit button.

However, for text editors where you have one connected cavas (Google Docs, Word, Medium.com) you can reach everything with the cursor keys, and TAB is usually used for other things, like indenting a list (shift + TAB to unindent). Haven't seen a one-canvas text interface that lets you navigate through a document using TAB yet.

I think the most flexible approach is just to let apps handle that themselves, then you are in control, and you don't need to battle a core behavior if you want to do something custom on that key. However, to reduce the amount of code to wire this up, I think we should have commands in Svedit. Much like SelectAll, we'd have FocusNextSelectable, FocusPreviousSelectable, that you can then call in your custom onkeydown handler.

I don't want to over-engineer this part yet, but potentially a declarative API for keyboard mappings would also help here. The idea is that you define a keyboard shortcut, and map it to a command. However the challenge here is to design this with minimalism in mind, we don't need something like VSCode, but we'd just like to have an easy way to map our commands to keys.

[johannesmutter]

Good points, haven't thought about Tab to indent a list.
Establishing a commands list with keyboard mapping sounds like a very developer friendly solution to me 👍