文档
使用ContentLayer和MDX构建博客

使用ContentLayer和MDX构建博客

学习如何使用ContentLayer和Next.js构建博客

<Callout>

本网站仍在开发中。如果您在页面上看到虚拟文本,说明我还在处理该部分内容。您可以在Twitter @shadcn上关注最新更新。

</Callout> <Callout> 以下文本来自[Tailwind CSS](https://play.tailwindcss.com/uj1vGACRJA?layout=preview)文档。我将其复制到这里以测试Markdown样式。**Tailwind很棒,你应该使用它。** </Callout>

到目前为止,尝试使用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. 这里是第三个假想的理由,因为一个有三个项目的列表看起来比只有两个项目的列表更真实。

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

排版应该很简单

这就是一个标题 - 如果我们做得对,它看起来应该相当合理。

有位智者曾经告诉我关于排版的一句话:

如果你不想让你的东西看起来像垃圾,排版是非常重要的。把它做好,那它就不会变坏。

默认情况下,图片在这里看起来也很重要:

<Image src="/_static/blog/blog-post-4.jpg" width="718" height="404" alt="图片" />

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

现在我要向你展示一个无序列表的例子,以确保它看起来也不错:

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

这就是本节的结尾。

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

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

有时你会有直接相邻的标题。在这些情况下,你通常需要取消第二个标题的顶部边距,因为标题之间的距离比段落后面跟着标题的距离更近通常看起来更好。

当标题跟在段落之后时...

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

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

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

    我在这些列表项中通常也有两到三个段落,所以最困难的部分是让段落之间、列表项标题和单独的列表项之间的间距都合理。老实说,这很困难,你可以强烈地争辩说你根本不应该这样写。

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

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

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

    我想只用两项可能也没问题,但三项肯定不会更糟,而且既然我似乎在毫不费力地编造任意的东西来打字,我不妨把它包括进来。

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

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

我认为大多数人会使用highlight.jsPrism或其他类似的工具来设置他们的代码块样式,但即使没有语法高亮,让它们看起来_还不错_也不会有什么坏处。

以下是写作时默认的tailwind.config.js文件的样子:

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

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

嵌套列表怎么办?

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

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

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

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

    但这次有第二段。

    • 这些列表项不会有<p>标签
    • 因为它们每个只有一行
  • 但在这第二个顶级列表项中,它们会有。

    这特别烦人,因为这个段落的间距。

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

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

    • 最后这里是另一个列表项,这样它更像一个列表。

  • 一个结束的列表项,但没有嵌套列表,为什么不呢?

最后一句话来结束这一节。

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

我差点忘了提到链接,比如这个链接到Tailwind CSS网站。我们差点把它们设置成蓝色,但那太过时了,所以我们选择了深灰色,感觉更前卫。

我们甚至包括了表格样式,看看这个:

| 摔跤手 | 出生地 | 终结技 | | ----------------------- | ----------- | ------------------ | | 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标签,比如如果我想告诉你关于tailwindcss/docs仓库的事。我不喜欢反引号下面有下划线,但为了避免这种情况而付出的代价绝对不值得。

我们还没有使用过h4

但现在我们用了。请不要在你的内容中使用h5h6,Medium只支持两级标题是有原因的,你们这些野蛮人。我真的考虑过使用before伪元素来对你使用h5h6大喊大叫。

我们根本不设置它们的样式,因为h4元素已经很小了,和正文一样大。我们该怎么处理h5,让它比正文更小吗?不,谢谢。

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

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

呼,如果运气好的话,我们已经设置了上面这些标题的样式,它们看起来很不错。

让我们在这里添加一个结束段落,这样内容以一个相当大小的文本块结束。我无法解释为什么我想要这样结束,但我必须假设这是因为我认为如果文档末尾太靠近标题,看起来会很奇怪或不平衡。

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

GitHub风格的Markdown

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

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

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

这对电子邮件链接也有效:[email protected]