flat list plugin (nesting with css instead of nested nodes)

[GermanJablo]

Hello, I see that the lists plugin required a lot of work due to the logic of the nested lists. Didn't you consider the option to "simulate" nested lists using CSS as you do with paragraph indentation instead of nesting the dom? For example something like:

<ul>
<li data-indent=0>list without indent</li>
<li data-indent=1>list with 1 indent</li>
<li data-indent=2>list with 2 indents</li>
</ul>

I'm pretty convinced that this solution:

1. Should be faster / perform better
2. It is much easier to program/requires fewer lines.
3. Also, offers a better UX when converting paragraphs to list items and vice versa. Paragraphs have an "indent" property that is independent of list indentation and does not rely on a property. Therefore, when making the conversion, said information is "lost" and undesired behavior is produced.

Have you considered this solution? Is there any reason why you think it's better to nest lists (ul inside ul...)?

[trueadm]

Yes, we considered it. However, to make nested lists semantically correct and accessible they need to be properly nested. There are also other issues with numbered lists or nested list styling when you don’t properly nest.

[GermanJablo]

Could you explain what you mean by semantics and accessibility? In fact, what I am saying is that what is already being done with the paragraphs, do it with the lists. HTML never thought of a property or attribute for a tab, however, its functionality is being "hacked" with a __indent property right now (Which seems to me a much better decision than what outliners like workflowy or notion do that nest paragraphs) . I don't think that doing the same thing that is being done with the paragraphs with the lists would present a different problem.

The case of numbered lists is a good point. I think it could be solved with a property like __start (of type number, which resets the count of the numbered list), or __number (which directly indicates the number of the list). Still I think it would be much simpler, easier and more efficient than nesting lists.

I say this because I myself made the transition by building my own text editor, from a nested model to a flat one, and the benefits were very evident.

edit: Also note for example the transition the Reddit folks made to the comment model (compare old Reddit [nested] to new [flat]).
Another user has also said on Discord that the flat model is also what Google Docs uses (I don't know right now because of its rendering in Canvas)

[trueadm]

As for the accessibility side of things, if you use a proper nested list implementation, screen readers like JAWS and NVDA properly announce them. If you do the hacky approach, they don't. This is even more evident with list of different types, i.e. nesting bullet lists in numbered lists. Screen reader support is important to us and we want to keep providing the same great level of support where possible.

As for Google Docs, they recently moved to using canvas rather than the DOM, so I'm unsure if we can compare with them anymore too. In terms of performance and simplicity I agree with you, but like I said, the UX/AX is more important to get right in our opinion.