Серверные и Клиентские компоненты

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

Вот что такое дефолт 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" внутри ссылки, например, если бы я хотел рассказать вам о tailwindcss/docs хранилище. Мне не нравится, что под обратными галочками есть подчеркивание, но это абсолютно не стоит того безумия, которое потребовалось бы, чтобы избежать его.

Мы еще не использовали h4

Но теперь у нас есть. Пожалуйста, не используйте h5 или h6 в своем контенте, Medium поддерживает только два уровня заголовков не просто так, вы, животные. Я, честно говоря, подумывал использовать псевдоэлемент before, чтобы накричать на вас, если вы используете "h5" или h6.

Мы вообще не оформляем их из коробки, потому что элементы h4 уже настолько малы, что имеют тот же размер, что и основная копия. Что мы должны делать с h5, сделать его маленьким, чем основная копия? Нет, спасибо.

Однако нам все еще нужно подумать о составных заголовках.

Давайте также убедимся, что мы не облажаемся с элементами h4.

Уф, если повезет, мы оформили заголовки над этим текстом, и они выглядят довольно хорошо.

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

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

GitHub Flavored Markdown

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

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

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

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