CSS have a bad effect when li element has no sub-element.

[sgalcheung]

What version of starlight are you using?

0.32.5

What version of astro are you using?

5.6.1

What package manager are you using?

pnpm

What operating system are you using?

Mac

What browser are you using?

Edge

Describe the Bug

This has a bad effect, obviously. Between two li elements, when the first li has no sub-element, this spacing is too large.

And this style is in here.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-j6nhcnxs?file=README.md

Participation

• [x] I am willing to submit a pull request for this issue.

[sgalcheung]

This is a method to resolve it：

.sl-markdown-content   li> :is(
    /* Scenario 1: Normal scenario (last child element+not unique child element) */
    :last-child:not(:only-child):not(li, ul, ol, a, strong, em, del, span, input, code, br, script, :where(.not-content *)),

    /* Scenario 2:< Li>is the last one in the list, even if there is only one<p>, it still takes effect*/
    :last-child:where(li:last-child > :last-child):not(li, ul, ol, a, strong, em, del, span, input, code, br, script, :where(.not-content *)),

    /* Scenario 3: Dealing with special situations at the end of<script>(keeping it unchanged) */
    :not(script):has(~ script:last-child):not(:has(~ :not(script)))) {
    margin-bottom: 1.25rem;
  }

[delucis]

Hi @sgalcheung — would you be able to make a minimal reproduction for this issue? I’d like to test your PR but realised we don’t have an example of the behaviour you’re describing I can quickly check.

You can use https://astro.new/starlight-basics and then save and share the link.

[sgalcheung]

I added the minimal reproduction markdown-demo, you can see this demo page Markdown demo page.

[delucis]

Thanks for the reproduction! Just to make sure I understand the issue correctly, are you referring to this extra space, highlighted here between list item 3 and its children?

[sgalcheung]

No, I meant that between the first li and the second li, should not be effective in margin in one no-sub-element li, and it not the last one li.

[delucis]

Ah, I see. Hmm, tricky. The Starlight styles here follow a quite common approach based on how Markdown processing works. When a list is authored without any newline spacing, list items are rendered without <p> tags inside. When a list is authored with even one blank newline, Markdown wraps list item children in paragraphs.

For example, the following Markdown:

1. one
2. two
3. three

Generates the following HTML:

<ol>
  <li>one</li>
  <li>two</li>
  <li>three</li>
</ol>

1. one
2. two
3. three

But the following Markdown:

1. one

2. two
3. three

Generates the following HTML with a <p> tag in each list item:

<ol>
  <li><p>one</p></li>
  <li><p>two</p></li>
  <li><p>three</p></li>
</ol>

1. one

2. two

3. three

Note how GitHub also spaces this second list more based on the authoring style.

In other words, it’s kind of a “standard” practice to add the more widely spaced style for lists like this. Although in the case of your example the first list item is short, if we change the style it would mean that even long, single-paragraph list items would be narrowly spaced even when authored with those additional spaces around the list items, which I don’t think is what people would expect.

The proposed change would also make list spacing potentially inconsistent: lists that include some items with just one child and other items with multiple would have varied spacing between list items, which I suspect would look like a mistake potentially.

Given this, I’m not sure if this is actually a bug.

Instead, what you probably would want to do is to remove the empty newline in your list to get the “compact” rendering style:

1. 项目一 有序列表 `数字 + . + 空格键`
2. 项目二
   ![GitHub set up](https://zh.mweb.im/asset/img/set-up-git.gif)
-                                                              
3. 项目三
   1. 项目三的子项目一 有序列表 `TAB + 数字 + . + 空格键`
   2. 项目三的子项目二
4. 项目四

1. 项目一 有序列表 数字 + . + 空格键
2. 项目二
3. 项目三
   1. 项目三的子项目一 有序列表 TAB + 数字 + . + 空格键
   2. 项目三的子项目二
4. 项目四

[sgalcheung]

Oh, that's amazing! A newline causes this problem, this newline puts each list item in a <p> tag. I agree with you, we don't need to change anything.

[sgalcheung]

I moved to gfm discussion on this case, so I close this issue.