本文介绍了Github Markdown中列表项之间出现多余的行的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个包含六个列表的自述文件.

I have a Readme with a half dozen lists.

一切正常,直到倒数第二个列表.问题在于这些列表项之间会出现一个额外的换行符.屏幕截图会更清楚:

Everything works fine until the second to last list. The problem is that an extra newline appears between those list items. This will be more clear with a screenshot:

我正在使用Sublime文本中的Markdown Preview软件包,如果使用Github Markdown预处理器进行预览,则会遇到相同的格式问题.

I am using the Markdown Preview package in sublime text and I see the same formatting issue if I preview using the Github Markdown preprocessor.

最奇怪的是,如果我在https://jbt.github.io/markdown-editor

What's most weird, though, is that I don't see the same issue if I type my text into https://jbt.github.io/markdown-editor

如果您想尝试一下,请使用以下字符串:

If you would like to try yourself, use the following string:

_git_

- **gl**: `git log <optional args>` _shows the revision history_
- **gpoh**: `git push origin head` _pushes the current branch_
- **gpom**: `git push origin master` _pushes the master branch_
- **grv**: `git remote -v` _lists the remotes_
- **gs**: `git status` _shows unstaged & staged changes_
- **gacm**: `git add -A; git commit -m "<message>"` _commits all changes with a message_
- **gacm-lfs**: `sudo git add -A; sudo git commit -m <message>` _it might not be this way for everyone,
  but for me `sudo git` uses git-lfs (git large filesystem) while `git` uses regular git. This function
  adds and commits all files with a message in a git-lfs repo._
- **gc**: `git checkout <branch>` _changes branches_
- **gclo**: `git clone <repo>` _clones a repo_
- **get_branch**: `git branch -f origin/<branch>; git checkout <branch>` _gets a specific branch from a remote repo_

_fish meta functions_

- **backup_functions**: `cd ~/.config/fish/functions; git add -A; git commit -m "<message>"; git push origin master; cd -` _backups the functions folder into a repo_
- **cdfns**: `cd ~/.config/fish/functions` _changes into the functions dir_
- **cfn**: `cat ~/.config/fish/functions/<name>.fish` _shows the definition of a function_
- **efn**: `nano ~/.config/fish/functions/<name>.fish` _edits a function's definition (using nano)_
- **fn**: `echo -e "function $argv[1]\n  $argv[2]\nend" > ~/.config/fish/functions/$argv[1].fish` _create a function_
- **fns**: `ls ~/.config/fish/functions` _list functions_
- **rmfn**: `rm ~/.config/fish/functions/<name>.fish` _remove a function_
- **fndoc**: `echo -e "- <text>" >> ~/.config/fish/functions/README.md` _adds a line to the readme documenting a function_
- **fs**: `funcsave <name>` _alias for funcsave, e.g.:_

      function fs
        funcsave $argv
      end
      fs fs

推荐答案

您的第一个列表是紧密"列表,而第二个列表是松散"列表,因为它在其中一个列表项中包含一个代码块.如果要使列表匹配,请对两者使用相同的类型.在第一个列表中的项目之间添加空白行将使它们匹配.正如规范所述:

Your first list is a "tight" list while the second is a "loose" list because it contains a codeblock in one of the list items. If you want the lists to match, use the same type for both. Adding a blank line between items on the first list will cause them to match. As the spec explains:

作为一个简单的示例,此列表:

As a simple example, this list:

* line 1
* line 2

将呈现为此HTML:

<ul>
    <li>line 1</li>
    <li>line 2</li>
</ul>

此列表:

* line 1
* line 2

  a second block

将呈现为:

<ul>
    <li>
        <p>line 1</p>
    </li>
    <li>
        <p>line 2</p>
        <p>a second block</p>
    </li>
</ul>

请注意,第二个列表项包含多个段落.因此,列表项中的每个段落都包装在< p> 标记中,从而使列表成为松散"列表.为了保持一致性,列表中的所有项目然后都包装在< p> 标记中(包括第一项).尽管该示例使用了一个段落,但同样适用于任何块级构造,包括示例中的代码块.

Notice that the second list item contains multiple paragraphs. Therefore each paragraph in the the list item is wrapped in <p> tags, making the list a "loose" list. For consistency, all items in the list are then wrapped in <p> tags (including the first item). While that example uses a paragraph, the same applies to any blocklevel construct, including the codeblock in your example.

您还可以通过在列表项之间添加空白行来强制列表成为松散"列表.例如,此列表:

You can also force a list to be a "loose" list by adding a blank line between list items. For example, this list:

* line 1

* line 2

此HTML的结果:

<ul>
    <li>
        <p>line 1</p>
    </li>
    <li>
        <p>line 2</p>
    </li>
</ul>

因此,如果您在第一个列表中的至少两个项目之间添加了空白行,则两个列表将始终显示,并且在它们之间留有一些空白.

Therefore, if you add a blank line between at least two of the items in your first list, both lists will consistently be displayed with some white space between them.

将列表项的内容包装在< p> 标记中会添加空格的原因是,页面(CSS)的样式已为定义了填充和/或边距< p> 标签.可以在自己的网站上(但在第三方主机上)编辑CSS来删除此填充/边距,但这通常不是一种选择.

The reason that wrapping the content of the list item in <p> tags adds white space is that the styles for the page (CSS) have defined padding and/or margin for <p> tags. One could edit the CSS to remove this padding/margin on their own site, but on third party hosts, that is generally not an option.

关于为什么某些工具似乎没有表现出这种行为的原因;它们可能具有默认的CSS样式,这会导致两种类型的列表看起来相同(例如,StackOverflow会这样做).另一种可能性是,他们使用的是老式的Markdown解析器,而不是更新得多的CommonMark规范(GitHub使用该规范).原始的 Markdown规则也具有宽松列表和紧凑列表的概念,但行为并非如此如此专门定义,因此不同的实现方式表现略有不同.许多人遵循参考实现,仅使与空行相邻的列表项松动",使所有其他项紧".在您的示例中,只有最后一项是宽松"的,但由于它是列表中的最后一项,因此不会那么明显.有关各种实现方式行为的比较,请参见 Babelmark .

As for why some tools do not seem to exhibit this behavior; it could be that they have default CSS styles which cause both types of lists to look the same (StackOverflow does this for example). The other possibility is that they are using an old-school Markdown parser rather than the much newer CommonMark spec (which GitHub uses). The original Markdown rules also had the concept of loose and tight lists, but the behavior was not so specifically defined so different implementations behaved slightly differently. Many followed the reference implementation and only made the list items adjacent to blank lines "loose" and all other items "tight". In your example only the last item would be "loose" but, as it is the last item in the list, would not be as noticeable. For a comparison of how various implementations behave, see Babelmark.

不管实现如何,如果您想要紧凑"列表,始终获得此结果的唯一方法是永远不要在列表项中的任何地方包含任何空行.这意味着,除了一些非常特殊的例外,您永远无法嵌套其他块级构造:

Regardless of implementation, if you want "tight" lists, the only way to always get that is to never include any blank lines anywhere in your list items. That means that you can never nest other block level constructs, with a few very specific exceptions:

  1. 明显的例外是嵌套列表,但即使如此,您仍需要避免空白行(请参见示例):

* parent item
    * nested item
    * Another nested item
* sibling of parent
* Another sibling of parent

  • 嵌套的代码块或blockquote可以嵌套在 some 实现中,但是它需要从列表项的第一行开始并且不包含空行.

  • A nested codeblock or blockquote can be nested in some implementations, but it needs to start on the first line of the list item and contain no blank lines.

    * list item
    *     A code block because it is indented appropriately
    * > a blockquote
    * a list item
    

    如您所见,示例,所以它仅在某些实现中有效.值得注意的是,CommonMark实现.换句话说,它将在GitHub上运行,但可能无法在其他工具或其他站点上使用.

    As you can see in that example, it only works in some implementations. Notably, the CommonMark implementations. In other words it will work on GitHub, but it may not with other tools or on other sites.

    无论如何,如果您有多个子段落,代码块和/或块引用,您的清单就不会紧.

    Regardless, you can not have a a tight list if you have multiple child paragraphs, code blocks, and/or blockquotes.

    这篇关于Github Markdown中列表项之间出现多余的行的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

  • 07-29 18:47
    查看更多