Not sure if this is a bug or a feature request, but I am using medium-editor to allow my users to write formatted text. When creating nested ordered lists, medium-editor does not wrap the children ordered lists in an <li> because current browsers do not render that correctly (see discussion of issue, with examples, here: https://github.com/yabwe/medium-editor/issues/666)

However, PrinceXML only increments the number for each <li>, so nested ordered lists repeat numbers. Is there an option I can set to make Prince number the nested ordered lists the same way current browsers do?

Like this?

<ol>
<li>one</li>
<li>two</li>
<ol>
<li>one</li>
<li>two</li>
</ol>
<li>three</li>
</ol>

This example seems to give the same results in Prince and Firefox, at least.

Mike,

Thanks for the reply. I've investigated some more and have a better understanding of the problem.

This markup:

<ol>
   <li>Item 1</li>
   <ol>
      <li>Item 1 Subitem 1</li>
      <li>Item 1 Subitem 2</li>
      <li>Item 1 Subitem 3</li>
      <li>Item 1 Subitem 4</li>
   </ol>
   <li>Item 2</li>
   <ol>
      <li>Item 2 Subitem 1</li>
      <li>Item 2 Subitem 2</li>
   </ol>
   <li>Item 3</li>
   <ol>
      <li>Item 3 Subitem 1</li>
   </ol>
   <li>Item 4</li>
</ol>

Will render in the browser as:

But will render in Prince as:

It seems that Prince does not pay attention to the closing </ol> tag of the child and continues on to the next highest number for the next <li>

1. Screen Shot 2016-07-20 at 11.53.14 AM.png‎ 24.8 kB ‎
   Browser rendering
2. Screen Shot 2016-07-20 at 11.53.33 AM.png‎ 41.3 kB ‎
   Prince rendering

Oops, the test case I provided earlier was useless, as it gives the same result for bad behaviour as well as good behaviour!

Any thoughts on this? I may be able to reconfigure the HTML prior to Prince's processing but I'd rather not go through the challenges of parsing and rearranging HTML if I can avoid it.

This may require some major changes to the way we handle list item counters, which are currently implemented as regular CSS counters like this:

ol { counter-reset: list-item }

Unfortunately the scope of a CSS counter includes the following sibling elements, so including an <ol> as a child of another <ol> will create overlapping nested counter scopes, which is almost certainly not what is intended. You can see this behaviour by adding this rule to your test case:

li::marker { content: counters(list-item, ".") }

Since browsers are clearly numbering list items using an internal mechanism unrelated to CSS, I suppose we shall need to do likewise.

Thanks for the additional information. My understanding is that the browsers are doing something different from the spec (there's a fairly detailed discussion of that in the GitHub issue I linked in my first post) which I'm sure is a total pain.

For now I plan to fix this by modifying the HTML before handing off to Prince by embedding <ol> within its preceding <li>. Wish me luck and thanks!

Good luck!

An update that might help other people looking at this thread - I was able to solve this with javascript which was way easier than trying to rearrange the DOM nodes.

Here is the function I used:

function fixOrderedLists() {
    var orderedLists = document.querySelectorAll('ol');
			
    for (var i = 0; i < orderedLists.length; i++) {
        var counter = 1;
        var listChildren = orderedLists[i].children;
        for (var j = 0; j < listChildren.length; j++) {
            if (listChildren[j].tagName == "LI") {
                listChildren[j].setAttribute("value", counter);
                counter++;
            }
        }
    }
}

I get all ordered lists and then loop through the direct children <li> of each one, manually setting the "value" attribute. Credit to jhoweaa for pointing out the "value" attribute which I didn't even know existed.

Concise and clever!

Hi jerkob,
glad you found a solution for this. I'm somewhat surprised that the Medium editor creates the nested OLs as direct children of the outer OL instead of being inside the LI elements. Maybe we should let them know that this would presumably be more cross-engine compatible:

<ol>
   <li>Item 1
       <ol>
          <li>Item 1 Subitem 1</li>
          <li>Item 1 Subitem 2</li>
          <li>Item 1 Subitem 3</li>
          <li>Item 1 Subitem 4</li>
       </ol>
   </li>
   <li>Item 2
       <ol>
          <li>Item 2 Subitem 1</li>
          <li>Item 2 Subitem 2</li>
       </ol>
   </li>
   <li>Item 3
       <ol>
          <li>Item 3 Subitem 1</li>
       </ol>
   </li>
   <li>Item 4</li>
</ol>

Anyway, Prince needs to fix this to be more compatible with browsers, and I've derived a test case from your code and added it here:
https://github.com/yeslogic/miscellaneous-testcases/blob/master/generated-content/ol-nested-inside-ol-001.htm
Thanks for bringing up the issue and writing such a good demo

Announcement: repos for tests/utils