Nested list annoyances

Spec
1

I have a grieve about how nested lists are shown wrt. vertical whitespace:

1. first
    * foo
    * bar
2. second
    * baz

is rendered compact as

  1. first
    • foo
    • bar
  2. second
    • baz

Adding a single empty line before 2. ends up with additional vertical whitespace after 1. and 2.:

  1. first

    • foo
    • bar

  2. second

    • baz

If I add 2 empty lines before 2., i get the desired result

  1. first

    • foo
    • bar

  2. second

    • baz

Note: the preview, the final posting, and the online test tool all behave differently for this it seems! Please simply copy and paste the example into the online test tool and add 0, 1, or 2 empty lines before 2. second

2

Markdown doesn’t specify a layout but an abstract syntax tree that corresponds to HTML elements. Click the “HTML” tab in the online test tool to see the output. So the three versions of the list you posted correspond to three different semantic HTML documents. If you don’t like the vertical spacing you can always change that with CSS.

2 Likes
3

Yeah, but I don’t want to be forced to add CSS I want it to look “right” by default. Adding blank lines does have semantic in Markdown and CommonMark (e.g. compact vs. non-compact lists). So what I think I want is that CommonMark says something like: “adding a blank line before a list item will switch to a non-compact form, resulting in additional vertical whitespace above that list item”.

4

So I think it comes down to: rendered 2-level lists with sublists look (much) better when they are rendered as a sequence of tight lists than when rendered as a loose list, because the vertical whitespace ends up in the “right” place (i.e. before the top-level list items and not after them). But the 2 blank lines to achieve that look unnatural in the commonmark source because they move the list items too far apart.

And yes, this might all come down to strange rules on how <p>, <li>, and <ul> or <ol> interact in HTML. But that should not be my concern as a commonmark user.

5

This seems to be, more or less, example 205 in the spec. Trying that out, I don’t like the way the spacing looks either:

  • a

    • b
    • c

  • d

    • e
    • f

    • I think it would be better if the sublists were grouped more closely with the item they are under:

    <ul>
<p><li>a
<ul>
<li>b</li>
<li>c</li>
</ul></li></p>
<p><li>d
<ul>
<li>e</li>
<li>f</li>
</ul></li></p>
</ul>

  • a
    • b
    • c

  • d
    • e
    • f

    • 6

    That does seem more logical, and definitely looks better by default. (Smart defaults are key, especially for a project like this.) Then if you do want the sublists to be further spaced, you’d make them loose lists.

    7

    @jericson Your proposed HTML is not valid: “Element p not allowed as child of element ul”. A list consists of list items, not paragraphs (although list items may contain paragraphs).

    1 Like
    8

    Huh. Valid HTML should be required of any output. I’ll just wave my hand and say that it should be rendered the way my invalid HTML is rendered in my browser. :wink:

    Playing around a bit more, I can’t find a way to express what I want in HTML without breaking things.

    9

    Interesting. So given this input:

    1. first
    * foo
    * bar

2. second
    * baz

    The reference implementation is putting a <p> tag around the words first and second that isn’t there if the blank line above #2 is removed. I think the <p> tag is the problem, not a good way to generate an open list.

    I’m no CSS expert, but it seems like a much better way of implementing open lists would be:

        <style>
    ol.open > li { margin-bottom :1em;}
    </style>
    <ol class="open">
        <li>
                first
                <ul>
                    <li>foo</li>
                    <li>bar</li>
                </ul>
        </li>
        <li>
                second
                <ul>
                    <li>baz</li>
                </ul>
        </li>
    </ol>
    10

    Loose lists are usually intended for containing paragraphs, hence the <p> tags.

    I do not think there is a case to change the html here, this is the reason css exists.

    11

    To be CSS friendly, HTML need to use attributes, rather than attempting to force formatting through the use of semantic tags like <p> and <table>. That’s the whole reason semantically-neutral tags like <div> and <span> were introduced: to promote moving semantics into attributes.

    P.S: I did use CSS. :smiley:

    PPS: In the input above, there are no CommonMark paragraphs, its all made up of list-items, so I still assert use of the <p> tag in the HTML output is the error, this time based on semantics rather than formatting.