Руководство по стилю

До сих пор попытки стилизовать статью, документ или блог с помощью Tailwind были утомительной задачей, требующей острого взгляда на типографику и большого количества сложного пользовательского CSS.

По умолчанию Tailwind удаляет все стандартные стили браузера из абзацев, заголовков, списков и других элементов. Это оказывается действительно полезным для создания пользовательских интерфейсов приложений, так как вы тратите меньше времени на отмену стилей пользовательского агента, но когда вы действительно пытаетесь стилизовать контент, который пришел из редактора с богатым текстом в CMS или файла markdown, это может быть неожиданным и неинтуитивным.

На самом деле мы получаем много жалоб на это, люди регулярно спрашивают нас, например:

Почему Tailwind удаляет стандартные стили на моих элементах h1? Как это отключить? Что вы имеете в виду, говоря, что я теряю все остальные базовые стили тоже? Мы вас слышим, но мы не уверены, что просто отключение наших базовых стилей — это то, что вам действительно нужно. Вы не хотите каждый раз удалять раздражающие отступы, когда используете элемент p в части пользовательского интерфейса вашей панели управления. И я сомневаюсь, что вы действительно хотите, чтобы ваши посты в блоге использовали стили пользовательского агента — вы хотите, чтобы они выглядели потрясающе, а не ужасно.

Плагин @tailwindcss/typography — это наша попытка дать вам то, что вы действительно хотите, без каких-либо недостатков, связанных с отключением наших базовых стилей.

Он добавляет новый класс prose, который вы можете применить к любому блоку стандартного HTML-контента, чтобы превратить его в красивый, хорошо отформатированный документ:

<article class="prose">
  <h1>Чесночный хлеб с сыром: что говорит наука</h1>
  <p>На протяжении многих лет родители пропагандировали пользу для здоровья от употребления чесночного хлеба с сыром своим детям, и эта еда приобрела такой культовый статус в нашей культуре, что дети часто наряжаются в теплую, сырную буханку на Хэллоуин.</p>
  <p>Но недавнее исследование показывает, что этот знаменитый закусочный продукт может быть связан с серией случаев бешенства, возникающих по всей стране.</p>
</article>

Для получения дополнительной информации о том, как использовать плагин и какие функции он включает, прочитайте документацию.

Чего ожидать дальше

Далее следует просто куча абсолютной ерунды, которую я написал, чтобы протестировать сам плагин. Она включает в себя все разумные типографические элементы, которые я мог придумать, такие как жирный текст, ненумерованные списки, нумерованные списки, блоки кода, цитаты, и даже курсив.

Важно охватить все эти случаи использования по нескольким причинам:

1. Мы хотим, чтобы все выглядело хорошо из коробки.
2. На самом деле только первая причина, это вся суть плагина.
3. Вот третья вымышленная причина, хотя список из трех пунктов выглядит более реалистично, чем список из двух пунктов.

Теперь мы попробуем другой стиль заголовка.

Типографика должна быть простой

Итак, это заголовок для вас — с любой удачей, если мы правильно выполнили свою работу, это будет выглядеть довольно разумно.

Что-то мудрое, что мне однажды сказали о типографике:

Типографика очень важна, если вы не хотите, чтобы ваши вещи выглядели как мусор. Сделайте ее хорошей, тогда она не будет плохой.

Вероятно, важно, чтобы изображения здесь по умолчанию тоже выглядели нормально:

Вопреки распространенному мнению, Lorem Ipsum — это не просто случайный текст. Он имеет корни в классической латинской литературе 45 года до н.э., что делает его старше 2000 лет.

Теперь я покажу вам пример ненумерованного списка, чтобы убедиться, что он тоже выглядит хорошо:

• Итак, вот первый элемент в этом списке.
• В этом примере мы держим элементы короткими.
• Позже мы будем использовать более длинные, сложные элементы списка.

И это конец этого раздела.

Что если мы сложим заголовки?

Мы должны убедиться, что это тоже выглядит хорошо.

Иногда у вас есть заголовки прямо друг под другом. В таких случаях вам часто приходится отменять верхний отступ на втором заголовке, потому что обычно лучше, чтобы заголовки были ближе друг к другу, чем абзац, за которым следует заголовок.

Когда заголовок идет после абзаца …

Когда заголовок идет после абзаца, нам нужно немного больше пространства, как я уже упоминал выше. Теперь давайте посмотрим, как будет выглядеть более сложный список.

• Я часто делаю так, чтобы элементы списка имели заголовки.

  По какой-то причине я думаю, что это выглядит круто, что, к сожалению, довольно раздражает, когда нужно правильно настроить стили.

  Я часто добавляю два или три абзаца в эти элементы списка, так что сложная часть — это сделать так, чтобы расстояние между абзацами, заголовком элемента списка и отдельными элементами списка имело смысл. Честно говоря, довольно сложно, можно было бы убедительно утверждать, что так писать не стоит.

• Поскольку это список, мне нужно как минимум два элемента.

  Я уже объяснил, что делаю, в предыдущем элементе списка, но список не был бы списком, если бы в нем был только один элемент, и мы действительно хотим, чтобы это выглядело реалистично. Вот почему я добавил этот второй элемент списка, чтобы у меня действительно было что посмотреть при написании стилей.

• Добавить третий элемент тоже неплохая идея.

  Думаю, было бы нормально использовать только два элемента, но три определенно не хуже, и поскольку у меня, похоже, нет проблем с придумыванием произвольных вещей для написания, я могу также включить его.

После такого списка я обычно добавляю заключительное заявление или абзац, потому что это выглядит странно, если сразу перейти к заголовку.

Код должен выглядеть нормально по умолчанию.

Думаю, большинство людей будут использовать highlight.js или Prism или что-то подобное, если они хотят стилизовать свои блоки кода, но не помешает сделать их нормальными из коробки, даже без подсветки синтаксиса.

Вот как выглядит файл tailwind.config.js по умолчанию на момент написания:

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

Надеюсь, это выглядит достаточно хорошо для вас.

А как насчет вложенных списков?

Вложенные списки практически всегда выглядят плохо, поэтому редакторы вроде Medium даже не позволяют вам их делать, но, думаю, поскольку некоторые из вас все равно будут это делать, мы должны взять на себя бремя хотя бы сделать так, чтобы это работало.

1. Вложенные списки редко бывают хорошей идеей.
   • Вам может казаться, что вы "организованы" или что-то в этом роде, но вы просто создаете уродливую форму на экране, которую трудно читать.
   • Вложенная навигация в пользовательских интерфейсах тоже плохая идея, держите все как можно более плоским.
   • Вложение множества папок в вашем исходном коде тоже не помогает.
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 тоже.

Фух, с любой удачей мы стилизовали заголовки выше этого текста, и они выглядят довольно хорошо.

Давайте добавим заключительный абзац здесь, чтобы все закончилось блоком текста приличного размера. Я не могу объяснить, почему я хочу, чтобы все заканчивалось таким образом, но я должен предположить, что это потому, что я думаю, что все будет выглядеть странно или несбалансированно, если заголовок будет слишком близко к концу документа.

То, что я написал здесь, вероятно, достаточно длинное, но добавление этого последнего предложения не повредит.

Markdown в стиле GitHub

Я также добавил поддержку Markdown в стиле GitHub с использованием remark-gfm.

С remark-gfm мы получаем несколько дополнительных функций в нашем markdown. Пример: автоссылки.

Ссылка вроде www.example.com или https://example.com автоматически будет преобразована в тег a.

Это работает и для ссылок на электронную почту: contact@example.com.