样式指南

到目前为止，尝试使用 Tailwind 样式化文章、文档或博客文章一直是一项需要对排版有敏锐眼光和大量复杂自定义 CSS 的繁琐任务。

默认情况下，Tailwind 会移除段落、标题、列表等的所有默认浏览器样式。这在构建应用程序 UI 时非常有用，因为你可以减少撤销用户代理样式的时间，但当你 确实只是 想要为来自 CMS 的富文本编辑器或 Markdown 文件的内容设置样式时，这可能会令人惊讶且不直观。

实际上，我们经常收到很多关于这方面的抱怨，人们经常问我们类似的问题：

为什么 Tailwind 会移除我的 h1 元素的默认样式？我该如何禁用它？你是什么意思，我也会失去所有其他基础样式？ 我们听到了你的声音，但我们并不认为简单地禁用我们的基础样式是你真正想要的。你不希望每次在仪表板 UI 的某个部分使用 p 元素时都要移除烦人的边距。而且我也怀疑你真的希望你的博客文章使用用户代理样式——你希望它们看起来 很棒，而不是糟糕。

@tailwindcss/typography 插件是我们试图在不做一些愚蠢的事情（比如禁用我们的基础样式）的情况下，给你 真正 想要的东西。

它添加了一个新的 prose 类，你可以将其应用于任何普通 HTML 内容块，并将其转换为一个美观、格式良好的文档：

<article class="prose">
  <h1>奶酪蒜蓉面包：科学告诉了我们什么</h1>
  <p>多年来，父母们一直向孩子们宣扬吃奶酪蒜蓉面包的健康益处，这种食物在我们的文化中获得了如此标志性的地位，以至于孩子们经常在万圣节打扮成温暖的奶酪面包。</p>
  <p>但最近的一项研究表明，这种备受推崇的开胃菜可能与全国范围内出现的一系列狂犬病病例有关。</p>
</article>

有关如何使用该插件及其包含的功能的更多信息，请阅读文档。

接下来会发生什么

接下来的内容只是我写的一些绝对无意义的东西，用来测试插件本身。它包括我能想到的每个合理的排版元素，比如 加粗文本、无序列表、有序列表、代码块、引用块、甚至斜体。

涵盖所有这些用例很重要，原因如下：

1. 我们希望所有内容开箱即用都看起来不错。
2. 其实只有第一个原因，这就是插件的全部意义。
3. 这是一个虚假的第三个原因，因为一个有三个项目的列表看起来比只有两个项目的列表更真实。

现在我们将尝试另一种标题样式。

排版应该很简单

这是一个标题——如果我们做得正确，它看起来应该相当合理。

一个明智的人曾经告诉我关于排版的事情是：

如果你不想让你的东西看起来像垃圾，排版非常重要。做好它，它就不会糟糕。

默认情况下，图片看起来也应该不错，这可能很重要：

与普遍的看法相反，Lorem Ipsum 并不仅仅是随机文本。它起源于公元前 45 年的一篇经典拉丁文学作品，已有 2000 多年的历史。

现在我要展示一个无序列表的示例，以确保它看起来也不错：

• 这是此列表中的第一个项目。
• 在此示例中，我们保持项目简短。
• 稍后，我们将使用更长、更复杂的列表项目。

这部分到此结束。

如果我们堆叠标题会怎样？

我们也应该确保它看起来不错。

有时你会有直接相邻的标题。在这些情况下，你通常需要撤销第二个标题的顶部边距，因为标题彼此靠得更近通常看起来比段落后跟一个标题更好。

当标题出现在段落之后……

当标题出现在段落之后时，我们需要更多的空间，就像我上面已经提到的那样。现在让我们看看更复杂的列表会是什么样子。

• 我经常这样做，列表项目有标题。

  出于某种原因，我认为这看起来很酷，这很不幸，因为让样式正确非常麻烦。

  我通常在这些列表项目中也有两到三个段落，因此难点在于让段落之间、列表项目标题和单独的列表项目之间的间距都合理。说实话，这真的很难，你可以强烈主张你根本不应该这样写。

• 因为这是一个列表，我至少需要两个项目。

  我已经在前一个列表项目中解释了我在做什么，但如果只有一个项目，列表就不是列表了，我们真的希望它看起来真实。这就是为什么我添加了这个第二个列表项目，这样我在编写样式时实际上有东西可以看。

• 添加第三个项目也不是个坏主意。

  我认为只使用两个项目可能也没问题，但三个肯定不会更糟，而且既然我似乎毫不费力地编造任意的东西来写，我不妨把它包括进去。

在这种列表之后，我通常会有一个结束语或段落，因为直接跳到标题看起来有点奇怪。

代码默认情况下应该看起来不错。

我认为大多数人会使用 highlight.js 或 Prism 或其他东西来为他们的代码块设置样式，但即使没有语法高亮，让它们开箱即用地看起来 不错 也无妨。

以下是撰写本文时默认的 tailwind.config.js 文件的样子：

module.exports = {
  purge: [],
  theme: {
    extend: {}
  },
  variants: {},
  plugins: []
}

希望这对你来说看起来足够好了。

嵌套列表怎么样？

嵌套列表基本上总是看起来很糟糕，这就是为什么像 Medium 这样的编辑器甚至不允许你这样做，但我猜既然你们中的一些人会这样做，我们就必须承担至少让它起作用的负担。

1. 嵌套列表很少是个好主意。
   • 你可能觉得自己真的很“有条理”或什么的，但你只是在屏幕上创建了一个难以阅读的丑陋形状。
   • UI 中的嵌套导航也是个坏主意，尽量保持扁平化。
   • 在源代码中嵌套大量文件夹也没有帮助。
2. 既然我们需要更多项目，这里是另一个。
   • 我不确定我们是否会费心设置超过两级的样式。
   • 两级已经太多了，三级肯定是个坏主意。
   • 如果你嵌套四级，你应该进监狱。
3. 两个项目不算列表，三个就不错了。
   • 再次强调，如果你希望人们真正阅读你的内容，请不要嵌套列表。
   • 没有人想看这个。
   • 我很不高兴我们甚至不得不费心设置这个样式。

Markdown 中列表最烦人的事情是，除非列表项目中有多个段落，否则 <li> 元素不会有子 <p> 标签。这意味着我还得担心设置这种烦人的情况的样式。

• 例如，这里是另一个嵌套列表。

  但这次有第二段。

  • 这些列表项目不会有 <p> 标签
  • 因为它们每行只有一行

• 但在这个第二个顶级列表项目中，它们会有。

  这尤其令人烦恼，因为这个段落的间距。

  • 如你所见，因为我添加了第二行，这个列表项目现在有了一个 <p> 标签。

    顺便说一下，这就是我所说的第二行。

  • 最后这里是另一个列表项目，所以它更像一个列表。

• 一个结束的列表项目，但没有嵌套列表，因为为什么不呢？

最后一句话结束这一部分。

我们需要设置其他元素的样式

我差点忘了提到链接，比如这个指向 Tailwind CSS 网站的链接。我们差点让它们变成蓝色，但那太过时了，所以我们选择了深灰色，感觉更有个性。

我们甚至包括了表格样式，看看：

我们还需要确保内联代码看起来不错，比如如果我想谈论 <span> 元素或告诉你关于 @tailwindcss/typography 的好消息。

有时我甚至在标题中使用 code

尽管这可能是个坏主意，而且历史上我很难让它看起来不错。但这个 “用反引号包裹代码块” 的技巧确实效果不错。

我过去做的另一件事是将 code 标签放在链接中，比如如果我想告诉你关于 tailwindcss/docs 仓库的事情。我不喜欢反引号下面有下划线，但要避免这种情况需要付出的代价绝对不值得。

我们还没有使用过 h4

但现在我们用了。请不要在你的内容中使用 h5 或 h6，Medium 只支持两个标题级别是有原因的，你们这些动物。我甚至认真考虑过使用 before 伪元素在你使用 h5 或 h6 时对你大喊大叫。

我们默认情况下根本不设置它们的样式，因为 h4 元素已经很小了，与正文文本的大小相同。我们应该对 h5 做什么，让它比正文文本还小吗？不，谢谢。

不过我们仍然需要考虑堆叠标题。

让我们确保我们不会搞砸 h4 元素。

呼，希望我们已经设置了上面这些标题的样式，它们看起来不错。

让我们在这里添加一个结束段落，这样事情会以一个大小适中的文本块结束。我无法解释为什么我希望事情以这种方式结束，但我必须假设这是因为我认为如果标题离文档末尾太近，事情会看起来很奇怪或不平衡。

我在这里写的内容可能已经足够长了，但添加这最后一句话也无妨。

GitHub 风格的 Markdown

我还使用 remark-gfm 添加了对 GitHub 风格 Markdown 的支持。

使用 remark-gfm，我们在 Markdown 中获得了一些额外的功能。例如：自动链接文字。

像 www.example.com 或 https://example.com 这样的链接会自动转换为 a 标签。

这对电子邮件链接也有效：contact@example.com。