Tailwind Typography 插件

本文来自 TailwindLabs。我放置这篇文章是为了演示如何使用 AstroPaper 主题撰写博客文章/文章。

默认情况下，Tailwind 会移除段落、标题、列表等所有默认的浏览器样式。这对于构建应用程序 UI 来说非常有用，因为你花更少的时间来撤销用户代理样式，但是当你真正需要样式化来自 CMS 或 markdown 文件的富文本内容时，这可能会令人惊讶和不直观。

实际上我们收到了很多关于这个问题的投诉，人们经常问我们：

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

@tailwindcss/typography 插件是我们尝试给你你_真正_想要的东西，而没有任何做蠢事（比如禁用我们的基础样式）的缺点。

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

<article class="prose">
  <h1>大蒜面包配芝士：科学告诉我们什么</h1>
  <p>
    多年来，家长们一直向孩子们宣扬吃大蒜面包配芝士对健康的好处，这种食物在我们的文化中获得了如此标志性的地位，以至于孩子们经常会在万圣节装扮成温暖、芝士味的面包。
  </p>
  <p>
    但最近一项研究表明，这种广受欢迎的开胃菜可能与全国各地爆发的狂犬病病例有关。
  </p>
  <!-- ... -->
</article>

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

接下来会看到什么

接下来的内容只是我为了测试插件本身而写的一堆毫无意义的废话。它包括我能想到的所有合理的排版元素，如粗体文本、无序列表、有序列表、代码块、块引用、甚至斜体。

涵盖所有这些用例很重要，原因有几个：

1. 我们希望所有内容开箱即用看起来很美观。
2. 实际上就是第一个原因，这就是插件的全部意义所在。
3. 这里是第三个假装的原因，虽然三个项目的列表看起来比两个项目的列表更真实。

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

排版应该简单

这是一个标题——如果运气好的话，如果我们做好了工作，它看起来会相当合理。

一位智者曾经告诉我关于排版的事情：

排版非常重要，如果你不想让你的东西看起来像垃圾。把它做好，就不会糟糕。 默认情况下图片看起来也应该没问题，这可能很重要：

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

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

这就是这一节的结尾。

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

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

有时你会让标题直接相互紧挨着。在这些情况下，你通常需要取消第二个标题的上边距，因为让标题靠得更近通常看起来比段落后面跟着标题更好。

当标题出现在段落后面时……

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

• 我经常做列表项包含标题这种事。

  出于某种原因，我觉得这看起来很酷，但这很不幸，因为要让样式正确非常烦人。

  我经常在这些列表项中放两三个段落，所以难点在于让段落之间、列表项标题和各个列表项之间的间距都合理。说实话非常困难，你可以提出一个强有力的论点，认为你根本不应该这样写。

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

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

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

  我认为只用两个项目可能也还好，但三个肯定不会更差，而且既然我似乎能毫不费力地编造出任意内容来输入，我不妨也加上它。

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

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

我认为大多数人会使用 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 元素。

呼，运气好的话，我们已经样式化了这段文字上方的标题，它们看起来还不错。

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

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