---
title: 介绍
description: MkSaaS 是构建 AI SaaS 网站的最佳代码模板。
---

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

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

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

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

`@tailwindcss/typography` 插件是我们尝试给您真正想要的东西，而不会有做一些愚蠢的事情（比如禁用我们的基本样式）的任何缺点。

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

```html
<article class="prose">
  <h1>Garlic bread with cheese: What the science tells us</h1>
  <p>
    For years parents have espoused the health benefits of eating garlic bread
    with cheese to their children, with the food earning such an iconic status
    in our culture that kids will often dress up as warm, cheesy loaf for
    Halloween.
  </p>
  <p>
    But a recent study shows that the celebrated appetizer may be linked to a
    series of rabies cases springing up around the country.
  </p>
</article>
```

有关如何使用该插件及其包含的功能的更多信息，[阅读文档](https://github.com/tailwindcss/typography/blob/master/README.md)。

---

## 从现在开始期待什么

从这里开始的是我写的一堆绝对无意义的内容，用来测试插件本身。它包括我能想到的每一个合理的排版元素，如**粗体文本**、无序列表、有序列表、代码块、块引用，_甚至斜体_。

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

1.  我们希望一切开箱即用看起来都很好。
2.  实际上只是第一个原因，这是插件的全部意义。
3.  这里有第三个假装的原因，尽管一个有三个项目的列表看起来比一个有两个项目的列表更真实。

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

### 排版应该很简单

所以这是给你的一个标题——如果我们做得正确，那应该看起来相当合理。

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

> 如果你不希望你的东西看起来像垃圾，排版是非常重要的。做好它，那么它就不会糟糕。

默认情况下，图片在这里看起来也应该不错：

{/* <img
  src="/images/blog/mksaas-og.png"
  width="718"
  height="404"
  alt="图片"
/> */}

与普遍的看法相反，Lorem Ipsum 并不是简单的随机文本。它起源于公元前 45 年的一段古典拉丁文学，使其有超过 2000 年的历史。

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

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

这就是本节的结尾。

## 如果我们堆叠标题怎么办？

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

有时候你有直接堆叠在一起的标题。在这些情况下，你通常必须取消第二个标题上的顶部边距，因为标题彼此靠得更近通常看起来比段落后面跟着标题要好。

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

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

- **我经常做这种事，列表项有标题。**

  由于某种原因，我认为这看起来很酷，这很不幸，因为要让样式正确是相当烦人的。

  我在这些列表项中通常也有两到三个段落，所以困难的部分是让段落之间的间距、列表项标题和单独的列表项都有意义。老实说，这很困难，你可以提出一个强有力的论点，认为你根本不应该这样写。

- **由于这是一个列表，我至少需要两个项目。**

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

- **添加第三项也不是一个坏主意。**

  我认为只使用两个项目可能已经足够了，但三个肯定不会更糟，而且由于我似乎在编造任意的东西时没有遇到麻烦，我不妨包括它。

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

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

我认为大多数人如果想要设置他们的代码块的样式，会使用 [highlight.js](https://highlightjs.org/) 或 [Prism](https://prismjs.com/) 或其他东西，但是让它们开箱即用看起来_还不错_，即使没有语法高亮，也不会有害。

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

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

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

### 嵌套列表怎么办？

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

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

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

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

  但这次有第二段。

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

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

  这特别烦人，因为这段话的间距。

  - 正如你在这里看到的，因为我添加了第二行，这个列表项现在有一个 `<p>` 标签。

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

  - 最后这里有另一个列表项，所以它更像一个列表。

- 一个结束列表项，但没有嵌套列表，为什么不呢？

最后一句话结束这一节。

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

我几乎忘了提到链接，比如[这个链接到 Tailwind CSS 网站](https://tailwindcss.com)。我们几乎把它们变成蓝色，但那是昨天的事了，所以我们选择了深灰色，感觉更前卫。

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

| 摔跤手                  | 出生地        | 终结技              |
| ----------------------- | ------------- | ------------------- |
| Bret "The Hitman" Hart  | Calgary, AB   | Sharpshooter        |
| Stone Cold Steve Austin | Austin, TX    | Stone Cold Stunner  |
| Randy Savage            | Sarasota, FL  | Elbow Drop          |
| Vader                   | Boulder, CO   | Vader Bomb          |
| Razor Ramon             | Chuluota, FL  | Razor's Edge        |

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

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

尽管这可能是一个坏主意，而且历史上我一直很难让它看起来不错。不过这个_"将代码块包裹在反引号中"_的技巧效果相当不错。

我过去做过的另一件事是在链接中放置一个 `code` 标签，比如如果我想告诉你关于 [`tailwindcss/docs`](https://github.com/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。 
