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 元素搞砸。

呼，幸运的话，我们已经样式化了这段文字上面的标题，它们看起来很不错。让我们在这里添加一个结束段落，这样事情就能以一个大小适中的文本块结束。 我无法解释为什么我希望事情以那种方式结束，但我不得不假设这是因为我认为如果标题离文档结尾太近，事情看起来会很奇怪或不平衡。我在这里写的可能已经够长了，但加上这最后一句话也没什么坏处。