Example: * 1932.
Those are suprisingly working: * 1917-32.
- 1917-32.
Im using the newest 3.3.0.beta3-dev without any plugins.
2 Likes
-
- testing
-
- second-line test
Markup used
* 1932. test smth
* 1933. again now then
Yeah, I can see the issue but this doesn’t seem to be valid Markdown markup. I tested the above with another Markdown editor and I see a similar issue:
You can avoid this by omitting the dot after the number. For example:
- 1932 - testing
- 1933 - second-line test
or by excluding the * at the beginning:
- testing
- second-line test
1932. testing
1933. second-line test
1 Like
But that does only work for consecutive years
- first
- second
- third
2008. first
2014. second
2015. third
Maybe using HTML instead of Markdown also works as an alternative:
- 1997. first
- 2000. second
- 2015. third
<ul>
<li> 1997. first</li>
<li> 2000. second</li>
<li> 2015. third</li>
</ul>
1 Like
That’s a Markdown limitation too. Tested Github and a few other Markdown editors, they all default to sequential lists.
3 Likes
Removing this margin with css normalizes it.
li>ul, li>ol, .cooked li>ul, .cooked li>ol, .d-editor-preview li>ul, .d-editor-preview li>ol {
margin: 0; /* Remove this */
}
1 Like
12983298. one
2. test
- one
- test
Yeah I have seen this before, we do fancy stuff in CSS that breaks this visually for outlier cases.
I think the reason for this was that it can be abused, perhaps @awesomerobot remembers.
2 Likes
hmmm, another test:
- 12983298\. one
- 2\. test
- 12983298. one
- 2. test
* 12983298\. one
* 2\. test
- 12983298. one
- 2. test
Evidently a number followed by a period, even if not the first token on the line, will be seen as a numeric list.
1 Like
This is because in markdown, when a . is placed after a number, it’s assumed that it’s an ordered list.
So by using formatting like * 1932. you’re generating the HTML:
<ul>
<li>
<ol start="1932">
<li><!-- item content --></li>
</ol>
</li>
<li>
<ol start="1933">
<li><!-- item content --></li>
</ol>
</li>
</ul>
Technically valid, but strange and unintended.
This is because when you introduce a -, it’s no longer a sequential number, so it’s not an ordered list and the . is disregarded.
To avoid this, ideally you’d either use:
* 1932 (unordered list if numbers aren’t sequential)
or
1932. (ordered list if numbers are sequential)
If the . is necessary, and it’s not an ordered list, you can escape the . with a \ like this:
* 1932\.
This is a separate issue, and happens with default browser CSS too:
The item marker in an HTML list is a pseudo element that gets placed before the list’s padding/margin are considered, so it always appears outside of the content’s “box”. Even when removing the margin/padding from a list, the markers will overflow.
For example, with the margin/padding removed from the list and overflow: hidden on the parent container, you don’t see the list markers at all:
So anyway, since the padding applied to the left of the list is a static value, and the list markers are placed in a way that falls within the padding, at some point the numbers will overflow.
Our CSS makes lists a little more horizontally compact than the default, and we have both left margin and padding… but the result is essentially the same:
There’s some CSS… list-style-position: inside that can override the marker positioning, this puts the marker inside the content box. But this means you’d no longer get nice number alignment:
list-style-position: outside; (default):
list-style-position: inside; (list marker occupies content space)
So to properly support ordered lists of any length and avoid impacting content alignment, we’d have to do something like… use JS to detect the number of digits in the marker (start from the first number in the list, then count all the list items to determine length) and apply enough padding to accommodate the highest number.
4 Likes
Thank you for the report. We’ve provided a workaround that we believe should help. Right now, we’re not able to fix every edge case and will close this report for now.
2 Likes