Ckeditor5: Implement simple list in/outdentation using the keyboard

[oleq]

A followup of https://github.com/ckeditor/ckeditor5-list/issues/3#issuecomment-243093364.

Related issue: https://github.com/ckeditor/ckeditor5-link/issues/17#issuecomment-243060618

---

The basic list UI/UX, as described in https://github.com/ckeditor/ckeditor5-list/issues/4, assumes that in/outdentation will be possible only using the keyboard.

[oleq]

The question is: which keyboard shortcut should be used?

The most common and most intuitive are Tab and Shift+Tab. However, given my previous comment and Editor Recommendations guidelines, I'm not so sure Tab is the right keystroke in terms of a11y. OTOH, if the keystroke is the only way to indent/outdent because ckeditor/ckeditor5#2939 does not provide dedicated buttons, combinations like Ctrl+M might be a big problem for the users.

WDYT?

[fredck]

No doubt about Tab and Shift+Tab for me. A11y concerns should be then handled as a result in a separate issue.

[scofalik]

I am already implementing it this way as a part of ckeditor/ckeditor5#2936.

[oleq]

@fredck How would you deal with a11y concerns then? A separate keystroke to escape the editor?

[Reinmar]

@fredck How would you deal with a11y concerns then? A separate keystroke to escape the editor?

I guess that @fredck refers to CKE4's implementation where Tab pressed inside a list will indent it, but somewhere else, or when it's not allowed to indent the list further, it is handled natively.

[fredck]

I didn't think about it thoroughly, but I see right now a few options:

1. There are situations where Tab will not have the indentation behavior inside lists. In such cases, it could have the "leave editor" behavior. For example, if I'm inside a list item, but not at the beginning of it, no indentation should happen.
2. An extra keystroke for such case.

As for now, I would go with "1" and wait for feedback.

[scofalik]

Wait, wait, wait, wait, what? Tab should work only at the beginning of the list? I am against, this is unnatural and not expected. In my opinion, Tab key should work in whole item, this is how it works in editors and we should not promote different behavior in this regard.

[Reinmar]

I think that I agree with @scofalik. We even did this differently in CKE4. You can press Tab wherever in an item which can be indented. Simply – when the indent command is enabled, pressing tab uses it. When it's disabled, the key isn't handled. And of course the command should be enabled everywhere in an item which can be indented.

We've never had any complaints about this behaviour in CKE4, which perhaps isn't an indication that this is intuitive, but at least it should be safe.

[fredck]

In my opinion, Tab key should work in whole item, this is how it works in editors

Er... that's not the behavior of MS Word, for example.

Ofc, a different story is when you select the whole item... but if the caret is blinking in the middle of it, then it is fine if it'll not indent for me.

We've never had any complaints about this behaviour in CKE4, which perhaps isn't an indication that this is intuitive, but at least it should be safe.

That's much probably because is also an OK way to do it and no one really cared about the a11y issue cause by Tab.

I would still go with the MS Word way at first and the wait for feedback. It at least gives us a chance to solve the a11y problem without having to introduce anything else.

[fredck]

the MS Word way

... and GDocs way, btw.

[Reinmar]

That's much probably because is also an OK way to do it and no one really cared about the a11y issue cause by Tab.

I remember that you were discussing a11y when working on this :P. Besides, this was accepted by the community which we know that cares about a11y, so this can be indication for us as well.

Er... that's not the behavior of MS Word, for example.

Ofc, a different story is when you select the whole item... but if the caret is blinking in the middle of it, then it is fine if it'll not indent for me.

Isn't that because Tab in Word and GDocs can insert tab characters? I've just checked GDocs – Tab pressed in a middle of a list item inserts a tab character. So, most likely, that's why Tab changes its behaviour only at the beginning of an item.

[oleq]

GDocs and MS Word can handle things in a different way because they're not components of a webpage, which is a specific, complex environment. They can use Tab for more features because users don't need it to navigate to the next focusable field in the form, etc. It all happens inside of a monolithic application, which gives more flexibility to the developers.

CKE should not blindly copy the behaviour of applications which interact with the world in a totally different way, that's my point.

[fredck]

I'm not sure you guys got the point. The comparison with MS Word and GDocs is not to say that we have the same features as them. There is actually two goals on that:

1. We're talking about the most used editors out there. People should be used to their behavior and therefore will not have any surprise if we do the same.
2. They have a "default behavior" for the Tab key, just like we have. In their case, they insert a tab character. In our case, we leave the editor. Therefore, it is not a matter of saying that we'll not have the same behavior of those applications but instead saying that, just like them, we'll have a way to execute the "default behavior".
3. And just like them, the user will not be able to execute the "default behavior" at the beginning of the list.

... or we just ignore the a11y problem, like exemplified by @Reinmar... but wait, all this talk was exactly about how to solve the a11 problem :/

[Reinmar]

... or we just ignore the a11y problem, like exemplified by @Reinmar... but wait, all this talk was exactly about how to solve the a11 problem :/

None of us understood what you mean. Could you clarify?

[fredck]

@oleq started the talk about how to handle the a11y concern and so I came with a proposal. Then you, @Reinmar, said that the CKEditor 4 way is fine, which means ignoring the a11y problem. But the point is not deciding whether to ignore it or not... is more about, if we would ever face it, what would be our approach?

[Reinmar]

My point was exactly the opposite – by saying that we discussed the a11y implications and that it's never been reported to us (at least I don't remember anything) that stealing Tab for lists is against some rules and common sense, I wanted to say that perhaps it's an OK solution.

Anyway, I'm OK with both solutions. Users will learn pretty quickly when they can press Tab.

[Comandeer]

I agree with @fredck, especially with

We're talking about the most used editors out there. People should be used to their behavior and therefore will not have any surprise if we do the same

The whole keyboard behavior described in Editor Recommendations (not only for lists) is based on the behavior of MS Word, LibreWriter and GDocs – just because this software is a _de facto_ standard and users are so used to it that I'd say that they even _expect_ such behavior in other editors.

We have also dedicated draft for Tab's default behavior which states clearly that this behavior could be overwritten… after considering all a11y issues ;)

[oleq]

Thanks, @Comandeer. This discussion would happen later on anyway as the topic of general a11y shows up. But it's good to have it resolved sooner than later. Let's stick to Tab–derived keystrokes and go on with this approach.

[Reinmar]

I guess we can close this ticket now.