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

呼，希望我們已經樣式化了上面的標題，它們看起來不錯。

讓我們在這裡添加一個結束段落，以便事情以一個大小合適的文本塊結束。我無法解釋為什麼我希望事情以這種方式結束，但我必須假設這是因為我認為如果標題離文檔末尾太近，事情會看起來很奇怪或不平衡。

我在這裡寫的內容可能已經夠長了，但添加這最後一句話不會有壞處。