Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extra spaces present in li tags with links #1059

Open
efc opened this issue Dec 18, 2024 · 1 comment
Open

Extra spaces present in li tags with links #1059

efc opened this issue Dec 18, 2024 · 1 comment

Comments

@efc
Copy link

efc commented Dec 18, 2024

Version(s) affected

2.6

Description

When I create a list...

- one
- two [link](url)
- [link](url) three
- [four link](url)

What is rendered is this...

<ul>
<li>one</li>
<li>two <a href="url">link</a>
</li>
<li>
<a href="url">link</a> three</li>
<li>
<a href="url">four link</a>
</li>
</ul>

Each one of the <li> tags is rendered with different spacing. The first has no spaces around the given content. The second has a space at the end, produced by the newline after the </a>. The third has a space at the beginning produced by the newline before the <a>. The fourth has newlines before and after the list item content.

It seems that a newline is being placed before or after the link depending on whether it is at the start or end (or both) of the list item.

This inconsistency makes using CSS li::before or li::after content on list items unpredictable. And it makes it completely impossible to create, for example, some li::after text that should never be separated from the list item by any space at all.

It seems wrong for extra spaces to be introduced into these list items. The consistent and correct rendering would be something like this.

<ul>
<li>one</li>
<li>two <a href="url">link</a></li>
<li><a href="url">link</a> three</li>
<li><a href="url">four link</a></li>
</ul>

Is it possible to achieve that?

How to reproduce

- one
- two [link](url)
- [link](url) three
- [four link](url)

I am using Laravel and Statamic, which seem to use 2.2.1 by default (which exhibits the same behavior). I have updated my version to 2.6 to confirm the problem still exists.

composer.lock.txt

@samwilson
Copy link

Looks like commonmark.js is more consistent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants