Lists

[Comandeer]

Lists are natural way to enumerate wide variety of things.

There are two elements in HTML standard that are used to mark up lists:

• ol element – used to mark up ordered, usually numbered lists
• ul element – used to mark up unordered, usually bulleted lists

They are serving two different purposes, so we should introduce 2 features for lists:

• "Bulleted lists" – marked up with ul
• "Numbered lists" – marked up with ol

It is also worth noting that there is also element dedicated to create generic key – value lists (formerly: definition lists), dl.

[Comandeer]

I've added drafts for Bulleted List and Numbered List features.

[fredck]

I think the expected behavior of the Tab key must be included. Nowadays one simply expects that it'll work as the way to indent / outdent lists, deprecating the need of a dedicated toolbar button for it.

[Comandeer]

I think that Tab behavior is a separate issue, which belongs to "Usability" category (we have even placeholder for Tab key there).

[fredck]

As a followup on my comment in #41, I still think that the behavior of the Tab key on lists should be spec'ed here in the UX section.

For instance, if not for the Tab key, how we pretend to spec the indentation of lists?

[Comandeer]

For instance, if not for the Tab key, how we pretend to spec the indentation of lists?

Good point. However indentation of lists still have some kind of button in offline RTEs – even if Tab key works in them. There is also an issue with generated code (nested lists), so the indentation of lists must be split into two parts: UI/UX (Tab & button or only Tab) and the explanation of how it affects the current list item.

[fredck]

However indentation of lists still have some kind of button in offline RTEs

True and I believe this is the "old approach". I'm for "trying" to avoid buttons just for this, after all the other feature related to such buttons, to indent paragraphs, doesn't fit the specs.

[Comandeer]

As I pointed in #36, the current version of the draft define only default behavior (inserting paragraphs) and encourages other features to overwrite it. So we should also have a section related to behavior of Enter key inside a list item. The default behavior of it should be IMO:

• If the Enter key is pressed inside a list item, the new list item is created.
• If the Enter key is pressed inside an empty list item, this item is replaced with a paragraph, so the list itself is split into two lists or simply followed by a paragraph.

[fredck]

If the Enter key is pressed inside an empty list item, this item is replaced with a paragraph, so the list itself is split into two lists or simply followed by a paragraph.

Other than this, it should behave like "outdent" if the empty item is indented.

[Comandeer]

Shouldn't outdenting be implemented using Backspace? Actually I don't find outdenting with Enter very intuitive. It also doesn't work in LibreWriter (I've checked it a moment ago).

[fredck]

Backspace in my opinion should remove the list item and move the caret at the end of the previous item.

Note that we're talking about Enter on an empty item. Example (| => caret):

• A
  • B
  • C
  • |
• D

Enter should cause this:

• A
  • B
  • C
• |
• D

Another Enter:

• A
  • B
  • C

|

• D

[Comandeer]

Ok, I came up with something like that:

• Backspace inside an empty list item SHOULD delete the current list item and move selection to the end of the previous list item, if that list item exists. If there is no list items left, the whole list SHOULD be deleted.
• Backspace at the beginning of a non-empty list item SHOULD join the current list item with the previous list item, if that item exists, otherwise transform current list item into the default block context.
• Delete inside an empty list item SHOULD delete the current list item and move selection to the beginning of the next list item, if that list item exists. If there is no list items left, the whole list SHOULD be deleted.
• Delete at the end of a non-empty list item SHOULD join the next block context of any type with the current list item, if the next block context exists.
• Tab at the beginning of a non-empty list item or inside an empty list item SHOULD indent the current list item.
• Enter inside a non-empty list item SHOULD insert a new list item before the current list item.
• Enter inside an empty, indented list item SHOULD outdent the current list item.
• Enter inside an empty, non-indented list item SHOULD create a new default block context, following the list. If there are list items following the current list item, the list SHOULD be split into two lists, separated by the newly created default block context.

If it seems alright, I'll update the drafts.

[fredck]

• Backspace inside an empty list item SHOULD delete the current list item and move selection to the end of the previous list item, if that list item exists. If there is no list items left, the whole list SHOULD be deleted.
• Backspace at the beginning of a non-empty list item SHOULD join the current list item with the previous list item, if that item exists, otherwise transform current list item into the default block context.

For simplification, I think that both these cases can be unified as the second case works well for both empty and non-empty list items.

• Delete inside an empty list item SHOULD delete the current list item and move selection to the beginning of the next list item, if that list item exists. If there is no list items left, the whole list SHOULD be deleted.
• Delete at the end of a non-empty list item SHOULD join the next block context of any type with the current list item, if the next block context exists.

Here the same, the second case works for both. Additionally, to have less text, I would remove the "if the next block context exists". Who cares if it joins with "nothing" :)

Actually, the idea of having a list with only an empty item totally deleted (and replaced with a default block) on Delete is nice, so I would add a dedicated case just for this.

Tab at the beginning of a non-empty list item or inside an empty list item SHOULD indent the current list item.

For precision: ", if the list item is allowed to be indented"

Shift+Tab is missing, which brings "outdent".

Enter looks fine.

[Comandeer]

Ok, I've updated the drafts for lists with a description of keyboard behavior.

[Comandeer]

I'm just reading ARIA authoring practices and found this:

Optionally, if the developer wishes to provide the ability to insert a tab into the document, it is recommended one of the following methods be used.

• Provide indent and outdent buttons in the menu. Keyboard shortcuts to the buttons should be Control+M for indent and Control+Shift+M for outdent.
• Provide a button in the menu to toggle the use of Tab between the two modes. If this button is used, then Control+M is recommended as a keyboard shortcut to toggle the button.

So probably our current draft for Tab behavior should be tested with accessibility in mind,

[fredck]

The clear problem with Tab is that it is used to "leave" the editor, moving to the next focusable element. Therefore, assigning any other behavior to it is problematic.

In the other hand, using Tab for things like indentation is a de-facto UX standard. Therefore there must be a trade off between general usability and accessibility.

Taking the ARIA best practices in consideration we MAY add to the specs Control+M as an additional shortcut and leave the Tab issue as an implementation decision (for example, one could make it configurable).

[Comandeer]

Ok, I've added a short note about it with proper reference.

[Comandeer]

Ok, it seems like a stable feature. I propose moving it from draft to the recommendation status. I'll wait 3 days for objections and then do what should be done ;)