1 Item 1
2 Item 2 + 3
4 Item 4
- Item 1
- Item 2 + 3
- Item 4
I would expect auto-numbering only if all lines start with 1.
That is actually also like it worked in Cairo.
We have to be careful. When users write 1, 2, 3, 4.. TWiki neatly renders the list as a correct HTML numbered list. Even I do like that often because it makes it possible to see the actual number in edit mode and that helps editing long lists.
If we suddenly only render the numbers as a HTML list if all numbers are 1 most old topics with numbered lists will look like crap and users can no longer choose to write the real numbers and get a nice looking list.
I can show an example of the result by putting 4 spaces instead of 3.
1 Some first text
2 Some second text
3 Some third text
4 Some forth text
Well. Not exactly the result the user will want or expects.
The best would be if TWiki auto-numbered when all numbers are 1 and made neat rendering that looks like the HTML list when numbers are not all 1's and allowed you to jump in the numbering or start from another number than 1.
But this makes the whole thing more complex I guess because the current implementation makes the brower do the counting based on very simple HTML tags.
So I am not sure how to tackle this one. But you have hit a nail that confuses users for sure. But we have to think about how to fix it so we do not break the nice indented rendering for those that did/do not write only 1's
Right; TWiki has "always done it that way" and this behaviour is enshrined in a testcase i.e. "the spec". This is a spec c hange, and as such needs to be discussed in Codev before this report can be reactivated. Setting no action.
Follow-up in TWiki:Codev.OverridingNumericLists