Numbered Lists in Editor & Preview not working properly

Steps to reproduce

Type an ordered list like this:

  1. something in here.
    1. something in here.
  2. something in here.
    1. something in here.

Expected result

  1. something in here.
    1. something in here.
  2. something in here.
    1. something in here.

Actual result

  1. something in here.
    1. something in here.
  2. something in here.
    2. something in here.

It seems like the order number of child-item are not follow the father-item, but follow the entire list.

Environment

  • Operating system: Windows 10
  • Obsidian version: 0.6.2
  • Using custom CSS: No

Additional information

5 Likes

Same on Catalina - 0.6.2

only in edit mode - preview works OK

2 Likes

Related bug.

Another related bug

1 Like

Version 0.6.5 –

Edit view on left; preview on right

FYI - this seems to be especially related to the default themes, so it could be specific to the default editor CSS files. I can get ordered lists to work correctly with one of the community themes (“80s Neon” theme by @death.au), whereas previously that theme would not work for me. So something changed in the right direction – maybe the core CSS. So the problem may lie with the default themes only. Notice the bug report from @hiddenone at the top of this thread says “Using Custom CSS: No.”

That’s strange if true, since I believe the issue is with the actual text being inserted not with how it’s being styled or rendered.

This is going to sound weird, but I believe the image you posted is absolutely correct. Hear me out:

  • In the editor view you have, at the top level, a numbered list with one item numbered ‘1’ - this renders as ‘1’ and no one should doubt this is fine
  • At the second level, you have three numbered items, starting with 2 (2,6,10). In the preview, you also have three numbered items, starting with 2 (2,3,4).
  • At the third level, under ‘6’/‘3’, you have two numbered items, starting with 7 (7,9). In the preview, you also have three numbered items, starting with 7 (7,8).

The markdown render seems to take the first number you supply in a list and number from there incrementally. If your list was 1,2,3 - it would number 1,2,3. If it was 1,1,1 it would also number 1,2,3. If it was 1,15,42 it would also number 1,2,3.
This is handy for when you rearrange your list and numbers get removed and added - you don’t have to keep track of them in the source, the preview will do it for you.

The issue that’s confusing matters here is that the editor attempts to number the lists automatically as you add new lines, but that number doesn’t reset automatically when you indent the list. So the preview starts a new inner list from the indent at the number that the editor automatically put in there, when you’re expecting it to start from 1.

The issue with my theme is to do with the way I restart the count at a new list in a way that is different than the browser does it by default[^1]. In this instance, my theme looks right, compared to what you’re expecting, but it’s actually wrong because it doesn’t start the list at the number specified.

tl;dr: @Caketray was right and the issue is with the text being inserted and not with the render - my themes are actually wrong.

[^1]: I remove the auto numbers and replace them with my own so I can do fancy colours and shadows and stuff

All that said, The issue @hiddenone originally posted does sound like a bug

Wow. I think this has become an unhealthy obsession for me – straight to CSS first thing in the morning.

You make an interesting point. So I think it may be an issue of deciding: by which rules of CSS grammar does the community (or the devs of course) want their text interpreted? Or better yet, we use custom CSS to style what we like regardless of what is objectively ‘correct.’

Check this out and hit the Preview tab on the right – it’s a site that compares many of the flavors of Markdown. I put my example text in there. Look at all the different renderings. :woozy_face: I think I need to go back to bed.

There are two separate things going on here.

  1. First is the way the smart indent assistant is working in edit mode. This need fixing

  2. The way numbered lists are interpreted by markdown parsers. According to the spec.
    A list that in source is

1.
1.
1.

Is correct and should be rendered as

1.
2.
3.

This part of the markdown spec makes people think that there is something wrong, but it’s just the spec.

Wow. Commonmark (the one I usually judge based off) doesn’t recognise a nested ul unless it starts with 1., but it’s happy to accept any number to start with at the top level. That’s really weird to me.

This got me looking at the CommonMark spec.
I found this:

In order to solve of unwanted lists in paragraphs with hard-wrapped numerals, we allow only lists starting with 1 to interrupt paragraphs.

Also

There can be any number of blank lines between items

Which means if you put an extra newline before each new intended list, the results become a bit more consistent. Still a bit weird in spots though.

Some improvements to the smart indent will be present to 0.7.

1 Like

i was going to report this.
v0.67 win 10 PC with CSS