ordered lists that don't start at 1

[marius@…]

If I try to split a numbered list and insert an explanation in the middle, like this:

  1. Item
  2. Item
  3. Item

some comment

  4. Item
  5. Item

then Trac shows the list with numbers 1, 2, 3, 1, 2 instead of 1, 2, 3, 4, 5.

Wish: Trac should specify the starting value of a numbered list explicitly (<ol start="4">), if that list didn't start from 1.

[Christopher Lenz]

The only problem I can see with this is that unfortunately, the start attribute of the <ol> has been ​deprecated in HTML, which means it is not valid XHTML Strict.

Personally, I'd say that doesn't matter, though.

[markus]

I agree with cmlenz. IMHO there're no other ways than either just use the deprecated start attribute in XHTML Strict or switch to XHTML Transitional. According to the W3C you should use counters instead of the start and value attributes, but this is currently only supported by Opera.

[Christian Boos]

Patch adding the start attribute when needed, plus allow for other types of lists.

[Christian Boos]

I've added a patch for this feature. I took this opportunity to add support for alpha and roman numbered lists.

I wonder if while I'm at it, I should add support for unnumbered lists started by a "-" character, which are pretty common in changeset log messages…

[Christian Boos]

Patch applied in r3162.

[mieses]

The number sequence is still reset after a break:

 1. Item 1
 1. Item 2
 1. Item 3
some comment
 1. Item 4
 1. Item 5

renders as:

1. Item 1
2. Item 2
3. Item 3

some comment

1. Item 4
2. Item 5

Also, the start attribute of <ol> is not rendered for numbers whose leading digit is a '1'.

 1. Item 1
 2. Item 2

 10. Item 10
 1. Item 11

 20. Item 20
 1. Item 21

 100. Item 100

 200. Item 200

renders as:

1. Item 1
2. Item 2

10. Item 10
11. Item 11

20. Item 20
21. Item 21

100. Item 100

200. Item 200

[Christian Boos]

The number sequence is reset after a break by design. If this is not what you want, then you can explicitly set the restart number (like in the example in the description), except for 2-digits numbers, as you've found out.

I'll look into changing that for 0.12.

[mieses]

Thank you. This is the first time i'm tempted to learn python to fix it myself.

Any number starting with a '1', not just 2 digit numbers, fails to explicitly set the restart value. 20-99 are OK. The problem is with 10-19, 100-199, 1000-1999, etc.

Also, it's not possible to explicitly set the restart value in the case of a,b,c,d and i,ii,iii etc.

(Maybe I over-use the list formatting feature and this issue is not very critical.)

[clm100]

I'd like to bump up resets of non-numeric ordered lists:

Renders as:

 A. Something
 B. Something
Comment
 C. Something

Renders as:

1. Something
2. Something

Comment

3. Something

[mpotter@…]

Note: In supporting continuation of non-numeric order lists there is a potential syntax conflict:

Is "I. " the continuation of an A. B. C. D. list or the start of an I. II. III. IV. list?

[Christian Boos]

I was about to close this one as another duplicate of #8892, but it looks like this is still wrong (as seen in comment:8).

The corresponding HTML is now:

<ol class="upperalpha"><li>Something
</li><li>Something
</li></ol><p>
Comment
</p>
<ol class="upperalpha" start="C"><li>Something
</li></ol>

But this renders as:

1. Something
2. Something

Comment

1. Something

Follow-up needed to r9208, as the restart value must be a numerical one, even for loweralpha or upperalpha ordered list.

[Christian Boos]

Fixed in r9314.

[Jun Omae]

I noticed that ordered list with zero starts at 1. Trac Wiki generates <ol class="arabiczero"> but ol.arabiczero rule isn't defined in trac.css. Instead, ol.arabic is defined. Is that behavior a defect?

See also demo-0.12/ticket/6330.

[anonymous]

ol.arabic seems to be used with RST (#721)

[Christian Boos]

Replying to jomae:

I noticed that ordered list with zero starts at 1. Trac Wiki generates <ol class="arabiczero"> but ol.arabiczero rule isn't defined in trac.css. Instead, ol.arabic is defined. Is that behavior a defect?

Right, now r3162 looks also wrong to me in that respect.

Proposed fix:

trac/wiki/formatter.py

@@ -814 +814 @@
         else:
             type_ = 'ol'
             lstart = fullmatch.group('lstart')
-            start = None
-            idx = '0iI'.find(listid)
-            if idx > -1:
-                class_ = ('arabiczero', 'lowerroman', 'upperroman')[idx]
-            elif listid.isdigit():
-                start = lstart != '1' and int(lstart)
+            if listid == 'i':
+                class_ = 'lowerroman'
+            elif listid == 'I':
+                class_ = 'upperroman'
+            elif listid.isdigit() and lstart != '1':
+                start = int(lstart)
             elif listid.islower():
                 class_ = 'loweralpha'
                 if len(lstart) == 1 and lstart != 'a':
@@ -845 +845 @@
             self._list_stack.append((new_type, depth))
             self._set_tab(depth)
             class_attr = (lclass and ' class="%s"' % lclass) or ''
-            start_attr = (start and ' start="%s"' % start) or ''
+            start_attr = (start is not None and ' start="%s"' % start) or ''
             self.out.write('<'+new_type+class_attr+start_attr+'><li>')
         def close_item():
             self.flush_tags()

trac/wiki/tests/wiki-tests.txt

@@ -1352 +1352 @@
  1. item 1
    a. item 1.a
    a. item 1.b
+     0. start at 0
 
 Some paragraph
 
@@ -1363 +1364 @@
 <ol><li>item 1
 <ol class="loweralpha"><li>item 1.a
 </li><li>item 1.b
-</li></ol></li></ol><p>
+<ol start="0"><li>start at 0
+</li></ol></li></ol></li></ol><p>
 Some paragraph
 </p>
 <ol start="2"><li>continue with item 2
@@ -1376 +1378 @@
 1. item 1
    a. item 1.a
    a. item 1.b
+     0. start at 0
 
 Some paragraph                                                                                                                              

Targeting the 0.12.7 milestone, but if you think this won't disrupt the beta1 release, I can also commit the fix earlier.

[Ryan J Ollos]

Replying to cboos:

Targeting the 0.12.7 milestone, but if you think this won't disrupt the beta1 release, I can also commit the fix earlier.

If you commit in the next 12 hours it shouldn't disrupt the release. I'm going to do another documentation sync tonight, and then continue with the release in the morning.

[Jun Omae]

Thanks for the patch. I agree targeting the 0.12.7 milestone. Because that is a minor issue.

[Christian Boos]

Fine by me, let's get that in after the release.

[Christian Boos]

Patch applied on 1.0-stable in [13417] and merged on trunk in [13418].