The discussion is about the issue of numbers being cut off in long lists on Discourse. Slowhand initially reported the issue, and jomaxro identified it as a Discourse issue, not specific to the user’s site.
codinghorror suggested editing the relevant CSS to fix the issue, and neil provided the SCSS code used. However, codinghorror later suggested that allocating enough space for only three digits should be sufficient.
cpradio discovered that the issue is caused by the CSS rule ul, ol, dd { margin: 0 0 9px 25px; padding: 0; }, specifically the padding: 0 part. cpradio later provided screenshots of before and after the CSS change, and submitted a PR to fix the issue.
The PR was merged, but sam noted that the indent for lists is now quite deep and inconsistent with bulleted lists. cpradio suggested removing ul from the rule to make them indented the same amount, and later submitted another PR to fix this issue.
The second PR was also merged, and cpradio provided screenshots of the changes.
I searched for quite a while and didn’t see anything about this.
We have several lists of episodes that go into 2- and 3-digits, and the left side of the numbers are cut off starting at about 20.
When you get to triple-digits, the entire first number is gone.
Is this something I can have an Admin adjust on our end?
Thank you for any help you can give me.
Este es un problema de Discourse, no tiene nada que ver con tu sitio.
Consulta https://try.discourse.org/t/testing-long-lists/708?u=jomaxro
Lo traslado a Contribute > Bug, a menos que el equipo considere que es mejor dejarlo en Contribute > UX.
Just edit the relevant CSS as needed in Admin, Customize, CSS
FYI the SCSS used:
.topic-body .contents {
ul, ol, dd {
margin-left: 40px;
}
}
Let’s see, now that commonmark is here we can start with whatever number we like and it is easier to demo this
and
CSS is broken on mobile numbers are cut
I don’t know that we really need to allocate enough space for ten digit numbered lists.. I think allowing space for the digit one plus two more, should work, eg:
vs.
Except that one of the cases I’ve run into this is starting a line with a four digit year.
July 20th in History.
The first Women’s Rights Convention in Seneca Falls, New York ends.
British Columbia joins Canada.
The first International Special Olympics Summer Games are held at Soldier Field in Chicago.
Apollo 11 lands, first humans on the Moon.
In the preview, your quoted “9999.” is shown in full, but my years cut off the first digit. In your post, I just see two digits of your “9999.”. Of course, since this thinks I’ve created an <ol>, all of the years after the first are trashed anyway.
It seems to be due to this rule
ul, ol, dd {
margin: 0 0 9px 25px;
padding: 0;
}
If you comment that out, or “mark as it inactive in dev tools”, the list numbering just works, with any numbering.
It seems the padding: 0 is the bigger culprit of that rule for causing issues.
Can you do a few screenshots of before and after?
We might as just do a PR to clean up this CSS if there is no impact on the “before”
I’ll see what I can come up with. Might not be to later tonight though.
User Menu:
Homepage:
Preview creating Topic:
Cooked Topic with Unordered Lists, Ordered Lists and Definitions
User Menu:
Homepage:
Preview/Editing Topic that was created:
Cooked Topic with Unordered Lists, Ordered Lists and Definitions
(no before captured)
Preview Pane:
Cooked Version
Verdict:
The browser seems to use “safe” defaults for padding/margins to prevent ridiculous rendering? (tested in latest Chrome and IE 11 – because I had access to it)
I’ve yet to pin point why the preview shows 5 digits and cooked shows 4 when both have a padding of 40…
For those wondering, I took screenshots of the menus and homepage because they utilize ol for the category/tags drop down and wanted to show they were not impacted negatively by this change.
The User Menu probably doesn’t use it, but figured, might as well screenshot it too!
Here is a CodePen showing browsers cut off crazy long list numbers too (so it isn’t Discourse specific)
I know why this occurs now, the 5 is in the “overflow” boundary and the preview content is within another div that has a padding of 7px all around, thus the overflow of the 5 is able to be seen.
Preview padding, showing the 5 in overflow.
Cooked indicating no additional padding, thus no overflow shown
OK, this now merged:
The indent for lists now is quite deep:
And not really consistent with indenting of bulleted lists, which does impact readability.
@awesomerobot can you have a quick to see if there is a CSS fix to improve this a bit?
If not, one options may be to place a class via the renderer on “big” lists.
Then we can use our old styling and add some additional rules for
.ul.digits-2
.ul.digits-3
and so on.
The simple solution is to remove ul from the rule I removed ol from, that would make them both indented the same browser default amount.
I can submit such a PR fairly quickly (if you’d want to go that route)
Sure go with that for now.
K, I’ll get that done tonight. Let me go most of the endpoints of Discourse to make sure it doesn’t do anything crazy to the existing UI and I’ll get it submitted. 
Okay, had to approach it differently as doing the same fix for ol actually broke the main navigation.
https://github.com/discourse/discourse/pull/4999
Before:
After:
