It appears that the same problem occurs to the desktop application on Windows as well when the size of the numbered list goes to 1000 or above.

I just tested this on v1.7.11 Ubuntun 20.04 and v1.7.5 Android 11.

I could duplicate this behaviour in the viewer on android and on the WYSIWYG editor on the desktop. I could not duplicate this behaviour on the markdown editor/viewer on desktop.

I was able to reproduce the problem on

Joplin 1.8.0 (dev, darwin)

Client ID: e354a932e6e143c782264aad4112b674
Sync Version: 2
Profile Version: 34
Keychain Supported: Yes

Revision: 5b65186b4 (dev)

Although not at 100, but at 1,000.

I can see this bug on Windows 10,

after 999 items in markdown editor/viewer.

after 99 items in WYSIWYG editor

Joplin 1.7.11 (prod, win32)

Client ID: a0c954327e82488cb38da36c5c2a167d
Sync Version: 2
Profile Version: 34
Keychain Supported: Yes

Revision: f560563d8 (master)

In noteStyle.ts , `margin-left : 1.7em ' is fixed , changing that to 2em fixes the issue ,but i guess making this dynamic will be a better choice .
can i work on this issue

@singhakshita Sure, go ahead. Be sure to read the guidelines first.

Is this solved? May i work on this?

if we create a list after 99 th element i.e 100 100 102 th element in the rich text editor and then switch to markdown and back to rich text editor it appears like this

it actually doesn't add space , all the 'ul' elements appears inside the 99 th elements ,it can be seen here

This issue has been seen on mac OS ,i am not sure if this persists on any other OS.
I am not sure if this issue has to opened separately or should i send the pull request sorting out this issue as well in the same PR only(since it can be OS specific)

Well @singhakshita, i can reproduce this currently too on macOS.
Although what i figured out was that it takes all the elements in a single list item after 99th element, that's why it doesn't add space.

yeah i said that only , i was just clarifying that it might look like its adding space but actually its adding list items inside that 99th element

Although @tessus , if i try to set a left margin to the ordered list to fix this, should i consider list upto 1000 or even greater? Thanks.

I'm not really sure, but IMO this should be dynamic. I'm not a UI designer, but from a coding standpoint a dynamic solution would be preferable. In my case it only happens afer the 99th item and I never have numbered lists that long.

On a desktop Chrome-based browser on a Mac, I can reproduce the 1000-length list problem with straight HTML, so I think correctly rendering three-digit list numbers on all platforms is sufficient. Experimentally, I've found that adding ol li {padding-left:1.5rem} does the trick on Mac/iPhone/iPad, even with large monospace fonts.

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

ghostwriter uses list-style-position: inside;

ol, ul {
    list-style-position: inside;
    padding: 0;
}

This can be the correct solution for us if we would like to change the way list items align if we want to support as many digits as we want.

Github uses a fixed padding of 2rem:

.markdown-body ol, .markdown-body ul {
    padding-left: 2em;
}

Apparently, this runs into the same problem when it comes to 1000, but generally, this is fine because they keep the markdown in a container with a padding of 32px.

I think the Github solution would be totally feasible in our case. By simply selecting an appropriate margin/padding we can support up to 99999 list items.
This should cover most of the use cases (plus it might be noticeably unresponsive when a list reaches that many items, which is a more critical problem than the cut off). A dynamic solution might not be necessary.

May i work on this ?

@harsh0032 go ahead.

Is this issue solved?

Is this issue solved?

Doesn't seem so. You can try the latest pre-release and see for yourself.

Is this issue solved?

Doesn't seem so. You can try the latest pre-release and see for yourself.

I checked and the issue still persists. Can i work on this?

@Ritesh-Aggarwal you can go ahead!

I am trying to setup for development but i am getting errors when i run npm install in root on windows
I checked the issue and found this forum but it isn't still working.Can anyone refer to a better solution to this issue.
forum mentioned: https://discourse.joplinapp.org/t/error-while-setting-up/15157/6

@Ritesh-Aggarwal please create a post on discourse for your installation problem of the dev env.

Hi. I just confirmed the issue yesterday at my Android and IOS devices. I could not go over 100. Is there any work being done on this issue?

Hi, I have examined the issue in both android and window 10.
In android, the problem occurs for 3 digit numbers ( after 99 ):

In window 10, the problem occurs for 4 digit numbers ( after 999 ):

What I want to ask is Can I work on it?

@MuhammadBilalBinAtique go ahead, but please check the previous attempts to fix this and make sure your solution is better. This is a complex problem and only correct solutions will be accepted.

@CalebJohn Can you please share some views on what the correct solution will look like?

@CalebJohn Can you please share some views on what the correct solution will look like?

Sorry @MuhammadBilalBinAtique, I have not looked into this problem deeply and cannot guide you in solving it.

@MuhammadBilalBinAtique please do not post text as screenshots. seriously how do people come up with idiotic idea?

And then please maybe search for the problem on the forum or ask there. gh is used to discuss reproducible errors. The problem is known, nothing left to discuss. So either you can come up with a PR or use the forum for questions.