New Line in List After Sub-List Creates New Paragraph Block #1550

Closed
opened 2026-02-05 01:12:24 +03:00 by OVERLORD · 11 comments
Owner

Originally created by @techmattr on GitHub (Feb 20, 2020).

Create List

  1. Thing 1

  2. Thing 2

    1. Sub-Thing 1
    2. Sub-Thing 2
  3. Thing 3

While editing a list or ordered list a new line should remain in the same block unless you Enter twice. There is no way to break out of the sub-list and maintain the paragraph block for the next item in the main list.

Originally created by @techmattr on GitHub (Feb 20, 2020). Create List 1. Thing 1 2. Thing 2 1. Sub-Thing 1 2. Sub-Thing 2 3. Thing 3 While editing a list or ordered list a new line should remain in the same block unless you Enter twice. There is no way to break out of the sub-list and maintain the paragraph block for the next item in the main list.
OVERLORD added the 🐛 Bug🎨 Design💻 Front-End labels 2026-02-05 01:12:24 +03:00
Author
Owner

@techmattr commented on GitHub (Feb 20, 2020):

Apparently GitHub is even worse at this. Here is screenshot example from BookStack: https://i.imgur.com/R9t39Yy.png

@techmattr commented on GitHub (Feb 20, 2020): Apparently GitHub is even worse at this. Here is screenshot example from BookStack: https://i.imgur.com/R9t39Yy.png
Author
Owner

@homotechsual commented on GitHub (Feb 20, 2020):

Just to be clear the input looks like this:

1. Thing 1
2. Thing 2
    1. Sub-Thing 1
    2. Sub-Thing 2
3. Thing 3
@homotechsual commented on GitHub (Feb 20, 2020): Just to be clear the input looks like this: ``` md 1. Thing 1 2. Thing 2 1. Sub-Thing 1 2. Sub-Thing 2 3. Thing 3 ```
Author
Owner

@homotechsual commented on GitHub (Feb 20, 2020):

Aha - think I've found the culprit.

The HTML markup for the above is entirely correct.

<ol>
<li>Thing 1</li>
<li>Thing 2
<ol>
<li>Sub-Thing 1</li>
<li>Sub-Thing 2</li>
</ol>
</li>
<li>Thing 3</li>
</ol>

The issue is the CSS which has the following:

p, ul, ol, pre, table, blockquote {
    margin-top: 0.3em;
    margin-bottom: 1.375em;
}

So at the end of the nested ol (the sub-list) the CSS is adding enough padding so as to appear to have a newline. The markdown is rendering to the correct HTML.

@homotechsual commented on GitHub (Feb 20, 2020): Aha - think I've found the culprit. The HTML markup for the above is entirely correct. ``` html <ol> <li>Thing 1</li> <li>Thing 2 <ol> <li>Sub-Thing 1</li> <li>Sub-Thing 2</li> </ol> </li> <li>Thing 3</li> </ol> ``` The issue is the CSS which has the following: ``` css p, ul, ol, pre, table, blockquote { margin-top: 0.3em; margin-bottom: 1.375em; } ``` So at the end of the nested `ol` (the sub-list) the CSS is adding enough padding so as to appear to have a newline. The markdown is rendering to the correct HTML.
Author
Owner

@homotechsual commented on GitHub (Feb 20, 2020):

What's needed here is a rule to stop nested lists getting the padding. e.g:

li > ul {
    margin-block-start: 0px;
    margin-block-end: 0px;
}

plus

li > ol {
    margin-block-start: 0px;
    margin-block-end: 0px;
}

this gives us this output:
image

@homotechsual commented on GitHub (Feb 20, 2020): What's needed here is a rule to stop nested lists getting the padding. e.g: ``` css li > ul { margin-block-start: 0px; margin-block-end: 0px; } ``` plus ``` css li > ol { margin-block-start: 0px; margin-block-end: 0px; } ``` this gives us this output: ![image](https://user-images.githubusercontent.com/2288257/74938665-56ad4180-53e6-11ea-8a1f-609a9df58684.png)
Author
Owner

@homotechsual commented on GitHub (Feb 20, 2020):

Side-note: GitHub is just being stupid at this - they are wrapping the text for each <li> element in a <p> tag providing the paragraph padding.

@homotechsual commented on GitHub (Feb 20, 2020): **Side-note:** GitHub is just being stupid at this - they are wrapping the text for each `<li>` element in a `<p>` tag providing the paragraph padding.
Author
Owner

@techmattr commented on GitHub (Feb 20, 2020):

That does seem to mostly fix it. There are still a few extra vertical pixels between sub-thing b and thing c but it doesn't look completely off anymore.

bQF6EdN

@techmattr commented on GitHub (Feb 20, 2020): That does seem to mostly fix it. There are still a few extra vertical pixels between **sub-thing b** and **thing c** but it doesn't look completely off anymore. ![bQF6EdN](https://user-images.githubusercontent.com/12102155/74941317-d0cacf80-53c0-11ea-816f-dffbdb84cdfe.png)
Author
Owner

@homotechsual commented on GitHub (Feb 20, 2020):

So there are... now here we have a problem. OCD essentially means I'm now going to find out where they are coming from and fix them.. Thanks for that :-p

@homotechsual commented on GitHub (Feb 20, 2020): So there are... now here we have a problem. OCD essentially means I'm now going to find out where they are coming from and fix them.. Thanks for that :-p
Author
Owner

@techmattr commented on GitHub (Feb 20, 2020):

Hah. Yeah that's really strange. I'm using Firefox and Stylus to render the CSS so it could be something with either of those...

@techmattr commented on GitHub (Feb 20, 2020): Hah. Yeah that's really strange. I'm using Firefox and Stylus to render the CSS so it could be something with either of those...
Author
Owner

@homotechsual commented on GitHub (Feb 20, 2020):

Maybe adding

padding-block-start: 0;
padding-block-end: 0;

would help.

So the full CSS rule could be:

li > ol, li > ul {
    margin-block-end: 0px;
    margin-block-start: 0px;
    padding-block-end: 0px;
    padding-block-start: 0px;
}

But having measured it on Edge (Chromium) I don't see the same additional space.

@homotechsual commented on GitHub (Feb 20, 2020): Maybe adding ``` padding-block-start: 0; padding-block-end: 0; ``` would help. So the full CSS rule could be: ``` css li > ol, li > ul { margin-block-end: 0px; margin-block-start: 0px; padding-block-end: 0px; padding-block-start: 0px; } ``` But having measured it on Edge (Chromium) I don't see the same additional space.
Author
Owner

@homotechsual commented on GitHub (Feb 20, 2020):

Opened a PR to fix.

@homotechsual commented on GitHub (Feb 20, 2020): Opened a PR to fix.
Author
Owner

@ssddanbrown commented on GitHub (Mar 15, 2020):

Thanks @techmattr for reporting and thanks again @MikeyMJCO for patching.

Merged in to master to be part of the next patch release.

@ssddanbrown commented on GitHub (Mar 15, 2020): Thanks @techmattr for reporting and thanks again @MikeyMJCO for patching. Merged in to master to be part of the next patch release.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#1550