Tailwind Typography 插件

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

默认情况下，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. 这里有第三个假装的原因，尽管有三个项目的列表看起来比有两个项目的列表更真实。

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

排版应该很简单

所以这就是一个标题——如果我们做得正确，运气好的话，它看起来会相当合理。

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

如果你不想让你的东西看起来像垃圾，排版是非常重要的。做好它，它就不会糟糕。 图像在这里默认看起来也很重要：

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

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

这就是本节的结尾。

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

我们也应该确保这看起来很好。

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

当标题出现在段落之后…

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

• 我经常做这种列表项有标题的事情。

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

  我在这些列表项中通常也有两到三个段落，所以困难的部分是让段落、列表项标题和单独的列表项之间的间距都有意义。说实话相当困难，你可以强烈争论说你就不应该这样写。

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

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

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

  我认为只使用两个项目可能就足够了，但三个绝对不会更糟，既然我似乎在编造任意的东西来输入方面没有问题，我不妨包括它。

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

代码默认应该看起来还可以。

我认为大多数人如果想要样式化他们的代码块，会使用 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 元素搞砸这个。

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

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

我在这里写的可能已经足够长了，但添加这最后一句话不会有害。