Better list spacing (nested lists and/or lists with multiple paragraphs)

Question

The styling of nested lists with mixed or multiple child elements isn’t great. If you have only a single paragraph of text or a single nested list item within a parent list item then there’s no issue, but as soon as you have more than one child element the styling starts to get a bit unpredictable. This is most noticeable when you have nested lists along with paragraph text in the same parent list item, but also affects things like code blocks and quotes.

This has come up as a support issue (for example How to insert subitem into list without breaking layout? and Nested indenting issue).

The issue is the explicit lack of a bottom margin on child lists and paragraphs regardless of whether there are succeeding elements. So for example, this:

- List item

    - Child list item

    More list item text

- List item

Is rendered as:

• List item

  • Child list item

  More list item text

• List item

And as an image for posterity:

This is because the first "List item" text is wrapped in a <p> tag that has a bottom margin, whereas the child list item and "Child item text" has no bottom margin.

The offending CSS rules (found in "all.css") are:

ul ul, ol ul, ul ol, ol ol {
    margin-bottom: 0;
}

.post-text ul p:last-of-type,
.wmd-preview ul p:last-of-type,
.post-text ol p:last-of-type,
.wmd-preview ol p:last-of-type {
    margin-bottom: 0;
}

Now, we don’t want all nested lists to have no bottom margin and we don’t the last paragraph to have no bottom margin unless it is the last element in that list item, not just the last paragraph.

The simple solution is to remove both of those declarations and replace with:

ul :last-child, ol :last-child {
    margin-bottom: 0;
}

That gives us no bottom margin on the last child element of anything inside lists, which would also cover the last list item itself, meaning we could get rid of this (also in "all.css") too:

.post-text ul li:last-child,
.wmd-preview ul li:last-child,
.post-text ol li:last-child,
.wmd-preview ol li:last-child {
    margin-bottom: 0;
}

Just for reference, this is how the previous example looks with the improved CSS:

Maybe I’m overlooking some other case where those rules are important or maybe they're used elsewhere and simply removing them isn't the best option but at least change the rule affecting paragraphs from :last-of-type to :last-child and stop removing the bottom margin on all nested lists...

This is also a problem with non-nested lists when multiple paragraphs are used. This:

- List item

 Second paragraph for item

- List item

- List item

is rendered like this:

• List item

  Second paragraph for item

• List item

• List item

as an image for posterity:

The second paragraph of the first item shouldn't be visually closer to the second item than it is to the preceding paragraph in the first item.

TL;DR Better nested list spacing please.

Answer 1

Oh hey, looks like we fixed this when switching over to the newfangled Stacks prose component for Markdown rendering.

Answer 2

Until this is fixed properly via CSS, there is a work-around (with three variations).

In the following examples,   is the em-space character and ● is the black circle character (used because the bullet character • is too small).

The first variation is closest to the improved CSS version. It uses manual line breaks and em-spaces to create the second level (and deeper) nested lists.

Raw:

- List item  
<br>&#x2003;&#x25CF; Child list item  

    More list item text

- List item

Display:

• List item
  
   ● Child list item

  More list item text

• List item

The second variation results in a dense list. It uses em-spaces at the start of, and normal double-spaces at the end of, each line to manually create the entire nested list.
(The double-space at the end could also be replaced by a <br> at the start.)

Raw:

 ● List item  
   ● Child list item  
  More list item text  
 ● List item  

Display:

 ● List item
   ● Child list item
  More list item text
 ● List item

The third variation results in an evenly-spaced sparse list. It uses a leading manual line break, a trailing double-space, and em-spaces to manually create the entire nested list.
(Could also use an extra <br> at the start instead of the double-space at the end.)

Raw:

 ● List item  
<br>&#x2003;&#x2003;&#x2003;&#x25CF; Child list item  
<br>&#x2003;&#x2003;More list item text  
<br>&#x2003;&#x25CF; List item  

Display:

 ● List item

   ● Child list item

  More list item text

 ● List item

--------------------------------------------------------------------------------------------------------------

Using the example from this question to demonstrate how to deal with consecutive nested items and extra long lines:

With a double-space at the end of the 1. and 2. lines:

- **Variable name casing**: See [wikipedia article](https://en.wikipedia.org/wiki/Snake_case) on *"Snake Case"*. In Perl, we use *"snake_case"* instead of *"camelCase"*, and be consistent. Example:  
<br>&#x2003;1. Line 14: `my $testType`  
<br>&#x2003;2. Line 18: `my $right_frame`

    In the first line you use camelCase, whereas in the second you use snake_case.

- **Function name casing**:

• Variable name casing: See wikipedia article on "Snake Case". In Perl, we use "snake_case" instead of "camelCase", and be consistent. Example:
  
   1. Line 14: my $testType
  
   2. Line 18: my $right_frame

  In the first line you use camelCase, whereas in the second you use snake_case.

• Function name casing:

Removing the leading manual line breaks:

- **Variable name casing**: See [wikipedia article](https://en.wikipedia.org/wiki/Snake_case) on *"Snake Case"*. In Perl, we use *"snake_case"* instead of *"camelCase"*, and be consistent. Example:  
 1. Line 14: `my $testType`  
 2. Line 18: `my $right_frame`  

    In the first line you use camelCase, whereas in the second you use snake_case.

- **Function name casing**:

• Variable name casing: See wikipedia article on "Snake Case". In Perl, we use "snake_case" instead of "camelCase", and be consistent. Example:
  
   1. Line 14: my $testType
   2. Line 18: my $right_frame

  In the first line you use camelCase, whereas in the second you use snake_case.

• Function name casing:

The dense version (double-spaces at the end of every line):

 ● **Variable name casing**: See [wikipedia article](https://en.wikipedia.org/wiki/Snake_case) on *"Snake Case"*. In Perl, we use  
  *"snake_case"* instead of *"camelCase"*, and be consistent. Example:  
   1. Line 14: `my $testType`  
   2. Line 18: `my $right_frame`  
  In the first line you use camelCase, whereas in the second you use snake_case.  
 ● **Function name casing**:  

 ● Variable name casing: See wikipedia article on "Snake Case". In Perl, we use
  "snake_case" instead of "camelCase", and be consistent. Example:
   1. Line 14: my $testType
   2. Line 18: my $right_frame
  In the first line you use camelCase, whereas in the second you use snake_case.
 ● Function name casing:

--------------------------------------------------------------------------------------------------------------

In answer to fgrieu's question from this post regarding how to correctly use bullets and how to handle long lines:

1. **Mammals**

 like:
<br>&nbsp; &nbsp; &#x25CF; cat multidisciplinary study including sedimentologic, stratigraphic, isotopic,
<br>&#x2003;&#x2003;and palynological aspects in order to reconstruct the paleoenvironment
<br>&#x2003;&#x2003;and to evaluate biochronologic and paleogeographic implications.
<br>&nbsp; &nbsp; &#x25CF; cow
<br>&nbsp; &nbsp; &#x25CF; dog
<br>New faunal and stratigraphic evidence documents the validity of the North American Clarkforkian.

2. **Smurf**

1. Mammals

   like:
       ● cat multidisciplinary study including sedimentologic, stratigraphic, isotopic,
     and palynological aspects in order to reconstruct the paleoenvironment
     and to evaluate biochronologic and paleogeographic implications.
       ● cow
       ● dog
   New faunal and stratigraphic evidence documents the validity of the North American Clarkforkian.

2. Smurf

Note the missing space in front of New faunal. It is not required, but doesn't affect the result if included.
Also note the different usages of '    ● ' (trailing space) and '  ' (no trailing space). These, and all the spaces in them, are critical for correct alignment.

Caveat: Tested and working correctly on Firefox ESR 52.3.0