Numbered lists have unwanted line feed / carriage control after the number.

[bwims]

Issue description

Numbered lists have line breaks after the numbers

Markdown to reproduce

1. **Basic Shed with Insulation:**
   - **Size:** Small (6x4 ft to 8x6 ft)
   - **Cost:** £1,500 to £3,000
   - **Details:** Includes basic insulation, simple interior finishes, and no additional services like electricity or plumbing.

2. **Standard Garden Office:**
   - **Size:** Medium (10x8 ft to 12x10 ft)
   - **Cost:** £5,000 to £10,000
   - **Details:** Better quality insulation, basic interior finishes, electricity, and potentially some heating solutions.

3. **High-End Garden Studio/Office:**
   - **Size:** Large (12x10 ft to 20x12 ft)
   - **Cost:** £10,000 to £25,000+
   - **Details:** High-quality insulation, premium interior finishes, full electrics, heating, double-glazed windows, and possibly plumbing for water supply and drainage.

Screenshot

This is what the VSCode preview shows ( I believe correctly)

This is what MarkdownViewerPlusPlus displays (I believe incorrectly

Environment

• Notepad++ 8.5.8 (x64)
• MarkdownViewer++ 0.8.2.0
• Windows 10 (x64)

[alcoolfire]

I am experiencing the same problem, but it doesn't matter if it is a numbered or bulleted list. The bug is triggered only when there is at least one blank line between at least one adjacent pair of list items, a so-called "loose" list. The bug is not triggered for "tight" lists. So, this tight list markdown will render correctly in MarkdownViewer++:

- first
- second
- third

but this loose list will not:

- first

- second
- third

and neither will this loose list:

- first

- second

- third

The CommonMark list spec seems clear to me:

A list is a sequence of one or more list items of the same type. The list items may be separated by any number of blank lines.

Markdown source is supposed to be relatively human-friendly, which is why loose lists are permitted and used by many people. Nothing in the markdown specs that I've found should ever lead to a line break being inserted between a list marker and its associated text.

Notepad++ v7.9.2 and MarkdownViewer++ v0.8.2.25525

[alcoolfire]

The CommonMark spec Example 306 shows the HTML to be generated for loose lists, which follows. It is the addition of the <p> tags that are used for loose lists:

<ul>
<li>
<p>foo</p>
</li>
<li>
<p>bar</p>
</li>
<li>
<p>baz</p>
</li>
</ul>

Try that in a mainstream web browser. Courtesy of GitHub markdown support, the following should show the result in whatever browser one happens to be viewing this bug report with:

• foo

• bar

• baz

Then paste that very same block of HTML into a markdown file for MarkdownViewer++ to render and one will see it rendered incorrectly (line break between list markers and text). I think this suggests a bug in the embedded HTML renderer in MarkdownViewer++ rather than in the markdown-to-HTML conversion stage.

[anthonyg2003]

Until this bug is patched, here is a CSS workaround that you can put into Options > HTML > Custom CSS:

/* Fix unwanted line breaks in loose lists */
li > p {
    display: inline !important;
    margin: 0 !important;
    padding: 0 !important;
}

[alcoolfire]

Thank you, @anthonyg2003 :-) That is an excellent workaround, especially since this project seems to have been abandoned in 2018.

To be accurate, it is worth noting that this CSS workaround provides an aesthetically acceptable rendering but not a strictly correct rendering. If one plays with the CommonMark spec Example 306 interactive Try It dingus, it can be verified that any loose list should be rendered with a consistent blank line spacing between every list element in the list (even if the blank line looseness is inconsistent in the markdown). The above CSS workaround renders all loose lists as if they are tight lists. I wonder if there might be a tweak possible for that workaround CSS to render both tight lists and loose lists correctly?

FWIW, my test set for loose and tight lists and sublists follows...

Markdown for testing:

### Markdown: tight list

- first
- second
- third

### Markdown: inconsistent loose list

1. alpha

1. beta
1. gamma

### Markdown: consistent loose list

- one

- two

- three

### Markdown: loose list with loose and tight sublists

1. **Loose list element with consistent loose sublist:**
   - should be space rendered after this line

   - should be space rendered after this line

   - should be space rendered after this line, courtesy loose parent list and loose sublist

1. **Loose list element with tight sublist:**
   1. should be **no** space rendered after this line
   1. should be **no** space rendered after this line
   1. should be space rendered after this line, courtesy loose parent list

1. **Loose list element with inconsistent loose sublist:**

   - should be space rendered after this line
   - should be space rendered after this line

   - should be space rendered after this line, courtesy loose parent list and loose sublist

As rendered by GitHub in web browser:

Markdown: tight list

• first
• second
• third

Markdown: inconsistent loose list

1. alpha

2. beta

3. gamma

Markdown: consistent loose list

• one

• two

• three

Markdown: loose list with loose and tight sublists

1. Loose list element with consistent loose sublist:

   • should be space rendered after this line

   • should be space rendered after this line

   • should be space rendered after this line, courtesy loose parent list and loose sublist

2. Loose list element with tight sublist:

   1. should be no space rendered after this line
   2. should be no space rendered after this line
   3. should be space rendered after this line, courtesy loose parent list

3. Loose list element with inconsistent loose sublist:

   • should be space rendered after this line

   • should be space rendered after this line

   • should be space rendered after this line, courtesy loose parent list and loose sublist

As rendered by MarkdownViewer++ with CSS workaround:

[alcoolfire]

It turns out that although the CSS workaround by @anthonyg2003 works, I'm not really sure why. It is a correct workaround, at least for simple cases, but it isn't doing quite what is being expressed. The child combinator "li > p" is indeed what we want, but it is not acting as a child combinator. Bug #34 tells us that the '>' is being incorrectly rewritten as ">" in the CSS actually fed to the HTML parser, both for rendering in Notepad++ and in exported HTML. This is readily verified. In effect, our workaround is being parsed not as "li > p" but is behaving as if it were written as descendent combinator "li p". Why the ">" is not simply invalidating the CSS entirely, I'm not sure - our workaround really shouldn't be working. Feed the following to the W3C CSS Validator to show it invalid:

li > p {
    display: inline !important;
    margin: 0 !important;
    padding: 0 !important;
}