본문으로 건너뛰기
에이든의 블로그
뒤로가기

Tailwind Typography 플러그인

이 글은 TailwindLabs에서 가져온 것입니다. AstroPaper 테마를 사용하여 블로그 글을 작성하는 방법을 보여주기 위해 이 글을 게시했습니다.

기본적으로 Tailwind는 단락, 제목, 목록 등에서 모든 기본 브라우저 스타일을 제거합니다. 이는 애플리케이션 UI를 구축할 때 유저 에이전트 스타일을 되돌리는 데 시간을 덜 쓰게 해주므로 매우 유용합니다. 하지만 CMS의 리치 텍스트 에디터나 Markdown 파일에서 가져온 콘텐츠를 정말로 스타일링하려고 할 때는 놀랍고 직관적이지 않을 수 있습니다.

실제로 이에 대한 불만을 많이 받습니다. 사람들이 이런 질문을 자주 합니다:

왜 Tailwind가 내 h1 요소의 기본 스타일을 제거하나요? 이것을 비활성화하려면 어떻게 해야 하나요? 다른 기본 스타일도 다 잃는다고요? 여러분의 말을 이해하지만, 기본 스타일을 단순히 비활성화하는 것이 여러분이 정말 원하는 것은 아니라고 생각합니다. 대시보드 UI에서 p 요소를 사용할 때마다 성가신 마진을 제거하고 싶지는 않을 것입니다. 그리고 블로그 글이 유저 에이전트 스타일을 사용하기를 원하지도 않을 것입니다 — 보기 멋지게 만들고 싶지, 형편없게 만들고 싶지는 않을 테니까요.

@tailwindcss/typography 플러그인은 기본 스타일을 비활성화하는 것 같은 어리석은 일의 단점 없이 여러분이 실제로 원하는 것을 제공하려는 우리의 시도입니다.

이 플러그인은 새로운 prose 클래스를 추가하여, 일반 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>

플러그인 사용 방법과 포함된 기능에 대한 자세한 내용은 문서를 참조하세요.


이후 내용 미리보기

여기서부터는 플러그인 자체를 테스트하기 위해 작성한 내용입니다. 굵은 텍스트, 비순서 목록, 순서 목록, 코드 블록, 인용문, 그리고 이탤릭체까지 생각할 수 있는 모든 합리적인 타이포그래피 요소를 포함합니다.

이러한 모든 사용 사례를 다루는 것이 중요한 몇 가지 이유가 있습니다:

  1. 모든 것이 기본적으로 보기 좋아야 합니다.
  2. 사실 첫 번째 이유가 전부입니다. 그것이 이 플러그인의 핵심이니까요.
  3. 두 개짜리 목록보다 세 개짜리 목록이 더 현실적으로 보이므로 세 번째 이유를 추가했습니다.

이제 다른 헤더 스타일을 시도해 보겠습니다.

타이포그래피는 쉬워야 합니다

위의 헤더를 보셨듯이 — 운이 좋다면 우리가 작업을 제대로 했다면 꽤 합리적으로 보일 것입니다.

어떤 현명한 분이 타이포그래피에 대해 말한 것이 있습니다:

타이포그래피는 결과물이 형편없어 보이지 않으려면 꽤 중요합니다. 잘 만들면 나쁘지 않을 것입니다. 기본적으로 이미지도 여기서 잘 보이는 것이 중요할 것입니다:

일반적인 믿음과 달리, 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” HartCalgary, ABSharpshooter
Stone Cold Steve AustinAustin, TXStone Cold Stunner
Randy SavageSarasota, FLElbow Drop
VaderBoulder, COVader Bomb
Razor RamonChuluota, FLRazor’s Edge

인라인 코드도 잘 보이는지 확인해야 합니다. <span> 요소에 대해 이야기하거나 @tailwindcss/typography에 대한 좋은 소식을 전할 때처럼요.

때때로 제목에도 code를 사용합니다

아마 좋은 아이디어는 아니고, 역사적으로 보기 좋게 만들기가 어려웠습니다. 하지만 이 “코드 블록을 백틱으로 감싸기” 기법은 꽤 잘 작동합니다.

과거에 했던 또 다른 것은 링크 안에 code 태그를 넣는 것입니다. tailwindcss/docs 저장소에 대해 알려주고 싶을 때처럼요. 백틱 아래에 밑줄이 있는 것이 마음에 들지 않지만, 이를 피하기 위해 필요한 노력은 절대 그만한 가치가 없습니다.

아직 h4를 사용하지 않았습니다

하지만 이제 사용했습니다. 콘텐츠에 h5h6은 사용하지 마세요. Medium이 두 가지 헤딩 레벨만 지원하는 데는 이유가 있습니다. 솔직히 h5h6을 사용하면 경고를 표시하는 before 의사 요소를 사용할까 고려했습니다.

기본적으로 스타일을 전혀 적용하지 않는 이유는 h4 요소가 이미 본문 텍스트와 같은 크기로 매우 작기 때문입니다. h5를 본문 텍스트보다 더 작게 만들어야 할까요? 아닙니다.

연속된 제목에 대해서도 생각해야 합니다.

h4 요소에서도 문제가 없는지 확인합시다.

운이 좋다면, 이 텍스트 위의 제목들에 스타일을 적용하여 꽤 보기 좋게 되었을 것입니다.

마무리 단락을 추가하여 적절한 크기의 텍스트 블록으로 끝내겠습니다. 왜 이렇게 끝내고 싶은지 설명할 수 없지만, 문서 끝부분에 제목이 너무 가까이 있으면 어색하거나 균형이 맞지 않아 보일 것 같기 때문이라고 생각합니다.

여기에 쓴 내용이 아마 충분히 길겠지만, 이 마지막 문장을 추가하는 것도 나쁘지 않을 것입니다.