Inconsistent wrapping of list item contents inside p elements

Implementation
1

I’m sorry that this might be a bit long. At present (v.0.26), if two items of an ordered list are separated by a blank line, the javascript reference implementation of CommonMark will wrap the content of each list item inside an HTML p element. For instances,

1. hello
2. world
3. foo bar

creates

<ol>
<li>hello</li>
<li>world</li>
<li>foo bar</li>
</ol>

while

1. hello
2. world

3. foo bar

creates

<ol>
<li>
<p>hello</p>
</li>
<li>
<p>world</p>
</li>
<li>
<p>foo bar</p>
</li>
</ol>

When one types the first two items, their contents are not wrapped inside any p elements. However, when one insert a blank line followed by a third item, suddenly the HTML markups for the first two items change.

Such retrospective change may surprise a user. It also creates problems when one want to style a list using CSS. For instance, one common trick to change the appearance of a list marker from 1. to (1) is to declare in the stylesheet something like this:

ol {
  list-style: none;
  counter-reset: myCounter;
}

ol li::before {
  counter-increment: myCounter;
  content: "(" counter(myCounter) ")";
}

However, since the item’s content is unexpectedly surrounded by a p element, which is of block-level, the above CSS declarations would introduce unexpected line-breaks:

(1) 
hello

(2) 
world

(3)
foo bar

While this can be fixed by styling also ol li p:first-of-type, there are other problems as well (e.g. with list items wrapped inside p elements, margins between paragraphs in different items may not collapse). There may be some CSS tricks to fix all these problems, but this inconsistency in wrapping list items inside p elements make CSS styling of list markers error prone.

So, I would like to know if this behaviour of CommonMark is intentional. If not, is it going to change?

2

Yes, it’s intentional. Whole lists can be “tight” or “loose”; you can’t have a list that is partly tight and partly loose. That looks terrible typographically. And many output formats (e.g. LaTeX) don’t support that.

The solution for you is easy: don’t insert that blank space before the last list item.

1 Like