Комментарии 18
Было бы интересно почитать не только про синтаксис, но и про то, как это готовить, чтобы у коллег в перспективе глаза не вытекали. Потому как разметка шириной 250 символов (и это у вас еще примеры очень простые), десятки сущностей в одной строке без какой-либо подсветки синтаксиса, причем со спрятанными условиями на размер экрана и событиями, абсолютное отсутствие логической структуры в разметке, а в перспективе и необходимость внедрять дополнительный CSS откуда-то со стороны, не очень способствуют ее восприятию в целом. У такого подхода имеется некий предел сложности дизайна, после которого разметка превращается в полный винегрет и все же требует дополнительных действий для поддержания свежести.
Из практики скажу что tailwind.css + alpine.js это чудо позволяет создать красивые, адаптивные и быстрые интерфейсы без тонн скриптов. Большие объемы разметки легко разделяются на уровне шаблонизатора того же twig. Сперва конечно оттолкнул синтаксис и даже больше alpine.js но после реализации я приятно был удивлен результату. П.с я бэкендер
Слишком длинные кострукции заменяются на кастом классы через директиву @apply.
Например
<span class="inline-block bg-gray-200 rounded-full px-3 py-1 text-sm font-semibold text-gray-700 mr-2 mb-2">#тег1</span> Можно поменять на
<span class="my-super-class">#тег1</span>С указанием во входном css файле
.my-super-class {
@apply inline-block bg-gray-200 rounded-full px-3 py-1 text-sm font-semibold text-gray-700 mr-2 mb-2
}Интересно, что в самой документации они жирным выделяют don’t use @apply just to make things look “cleaner”. И дальше приводят список причин, почему так делать не рекомендуется. В основном аргументы на тему того, что все возвращается назад, к старому доброму CSS (ну или условному LESS/SASS с миксинами), теряется сам смысл Tailwind.
Действительно, можно использовать @apply. Если опустить тот момент, что сами авторы tailwind так делать не рекомендуют, то я не понимаю одного момента:
если я всё равно вынужден создать CSS-файл для использования
@apply, что идёт против HTML-first подхода tailwindесли я всё равно вынужден придумать имя класса для переиспользования, что идёт против идеи tailwind "не нужно придумывать классы"
если я вынужден в CSS-файле вместо деклараций, перечислить список классов со специальной директивой
@apply, что является не валидным синтаксисом CSS и для работы этого требуется специальный компиляторесли классы всё равно представляют собой сокращения для одного-двух-трёх CSS-свойств
если всё равно используется класс, в котором зашит целый набор свойств, что идёт против utility-first подхода tailwind
То выходит, что я умышленно отказываюсь как минимум от трёх главных идей tailwind, возвращаюсь к классическому подходу с селектором и списком свойств в фигурных скобках в CSS-файле, но записанных в придуманном синтаксисе и завязываюсь на сторонний пакет с компилятором. Зачем тогда tailwind? Ради коротких свойств-классов вместо более длинных деклараций? Так есть же emmet и пишут df Tab aic Tab и так далее.
Их "рекомендация" не делать так – всего лишь рекомендация, да и причины сильно надуманны (по-моему мнению). Способов использования TW дохера и больше, нам нравится @apply потому что позволяет:
Смиксить TW в HTML и TW в CSS через тот самый
@apply, то есть можно подверстать какой-то прототип быстро прямо в html, а потом при необходимости перенести все в исходник TW-CSS. Если хочется.Компилятор TW проверяет использование всех классов в исходных html/js файлах, на выходе не будет неиспользованных стилей. То есть в любом случае по html файлам надо генерить CSS компиляторов от TW. А если использовать полный TW-CSS со всеми фичами, это охереть какой раздутый CSS.
Как раз управление псевдоэлементами внутри исходного описания класса, и поведением на разных разрешениях тоже в одном этом месте. (написав в одном месте у класса
w-full sm:w-1/2 md:w-1/3мне надо копировать в каждый блок медиа все эти переопределения и т.п.)
TW дает упрощенную нормализованную систему базовых величин типа размера шрифтов, отступов и т.п. Плюсом темы с пользовательскими цветами например (по факту это тоже переменные). И для этого не надо вспоминать как там оно вообще устроено в CSS, не надо копаться в доке работает ли какая-то современная фича и где, никаких вендор префиксов и другой ереси для не профессионального верстальщика.
<span class="inline-block bg-gray-200 rounded-full px-3 py-1 text-sm font-semibold text-gray-700 mr-2 mb-2">#тег1</span>
Отвратительно выглядит всё это, сто тыщ классов, глазами ваще не парсится
Tailwind имба
Преимущество в том, что всякие псевдоэлементы и поведение можно указать прямо в коде элемента или класса, не создавая для этого хтрые портянки из классов в css
Например
.my-link {
@apply flex flex-row items-center color-blue hover:color-red hover:underline
before:block before:w-6 before:h-6 before:mr-2 before:bg-green
}И получим ссылку в которой сразу указано прведение при наведении, а еще у нее спереди зеленый квадратик в псевдоэлементе before
А что будет, если перемножить псевдоэлементы, псевдоклассы и медиа-запросы?
Из википедии: "Основной целью разработки CSS является ограждение и отделение описания логической структуры веб-страницы (которое производится с помощью HTML или других языков разметки) от описания внешнего вида этой веб-страницы".
По-моему разработчики tailwind, и ими восхищающиеся, просто не понимают, что HTML должен содержать минимум информации о визуальном представлении. Ни каких маржингов, размеров, цветов там не должно быть.
Наткнулся на эту заметку, потому что сегодня узнал про этот фреймворк из одного видео на ютубе. После прочтения ощущение, будь-то в начало 2000-х попал, где всё оформление было в виде атрибутов html, только теперь вместо этих атрибутов - классы css. Может автор материала не очень хорошо познакомился с фреймворком? В том же boostrap тоже есть классы, которые непосредственно на оформление влияют. Но там по большей части всё-таки более глобальные понятия в качестве имён классов, которые не относятся непосредственно к параметрам оформления.
Я занимаюсь фронтенд разработкой уже около 8 лет и был всегда ярым противником тайлвинда, до тех пор, пока не принял участие в проекте с ним. После этого мнение кардинально поменялось и теперь я его заношу в новые проекты с удовольствием.
Из минусов - длинные классы, сложно прочитать бегло а также то, что с некоторыми кастомными либами( по типу материал дизайн для тайлвинд) бывают конфликты (некоторые классы заявленные в доках перестают работать). Однако эти минусы с лихвой перекрываются плюсами на долгой дистанции, когда требуется в долгосрочной перспективе поддерживать и развивать проект не один год, когда приходят и уходят новые сотрудники, когда надо часть проекта переиспользовать в другом проекте.
Обзор синтаксиса Tailwind CSS