Начну с истории. :-) Первая версии Bootsrtap'а была мало привлекательна. Вторая версия уже предлагала готовую типографику и ряд компонентов. С учётом сумасшедшего пиара со стороны Твиттера (это их разработка), Bootsrtap стал самым популярным css-фреймворком. Третья версия стала доделкой второй — чтобы было понятно — это 2013 год. Нельзя сказать, что код Bootsrtap'а идеальный — там очень много «косяков» и архитектурных просчётов, но это всё нивелировалось хорошей документацией и, опять же, сумасшедшим пиаром.

Многие решили, что Bootsrtap 3 станет последней версией и всё к этому и шло, поскольку команда поддерживала только эту версию, а обещания выпустить следующую тонули в многочисленных альфа-версиях (4-я версия всё-таки вышла в 2018 году). Проблема состояла в том, что веб-вёрстка динамично развивающая отрасль и уже пошли серьёзные подвижки в HTML 5, CSS 3, а также развитие браузеров. То есть Bootsrtap 3 просто перестал нормально отвечать современных запросам. Скажем отсутствие поддержки единиц REM, хотя они уже полностью поддерживались в IE11, а частично в 9 и 10 версии.

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

Читать дальше...

Расскажу немного о Tailwind CSS, поскольку этот фреймворк позиционируется как утилитарный и мне интересен в сравнении и моими UniCSS и Berry CSS.

У Tailwind высокая популярность — почти 25 тысяч звёзд на гитхабе. На мой взгляд это очень круто — ребята хорошо вложились в раскрутку. :-)

Важный момент в том, что Tailwind написан на JS, то есть там нет css-кода как такового. Его идея в том, чтобы подключать нужные компоненты как js-модули, которые в свою очередь генерируют нужный css-код. Наверное именно поэтому его используют в js-фреймворках на node.js - сборка получается скопом, как там и принято.

Если абстрагироваться от самого сборщика, то идея генерировать css-классы ровно такая же, как и в моём UniCSS (и Berry). Я это реализован в конце 2014 года на Less (потом перешел на Sass), а Tailwind появился на 3 года позже со сборщиком на JS. В нём используется тот же самый подход, когда верстальщик сам указывает какие именно классы ему нужны.

Читать дальше...

Как правильно сгенерировать css-файлы, чтобы они положительно влияли на загрузку и при этом с ними удобно было бы работать? Такой вопрос неизбежно задаёт себе каждый верстальщик. Когда мы делаем какой-то свой личный проект, проблема не особо актуальна, но если речь идёт о чем-то публичном, то она обостряется.

За время работы с UniCSS и Berry я постепенно смог сформулировать основные идеи, которые позволяют достаточно неплохо решить данную проблему. Особенно она будет интересна тем, кто использует сторонние css-фреймворки, вроде Bootstrap'а.

Читать дальше...

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

Например в Bootstrap 4 есть такие классы:

.py-5, .pt-2, .p-5, .m-5, .my-1, .m-1, .m-n1, .text-reset

Понять их назначение невозможно без обращения к документации.

.p-5 {padding: 3rem !important;}
.m-n1 {margin: -0.25rem !important;}
.m-1 { margin: 0.25rem !important; }
.text-reset {color: inherit !important;}

Во некоторых случаях css-классы меняют свое поведение. Например в UiKit 3 есть классы .uk-padding, который задает padding: 30px;, но при @media (min-width: 1200px)становится уже 40px.

Проблемы бывают и более глобального уровня. Например в Bootstrap 4 было принято решение, что для всех компонентов и многих элементов используется нулевой верхний отступ (margin-top:0), а отступы между элементами следует делать с помощью нижнего отступа. Это глобальное поведение, которое сложно изменить. Но что делать, если нужно состыковать два блока непосредственно друг к другу или задать какой-то другой вариант, не предусмотренный во фреймворке?

Библиотека Berry как раз и призвана решать эти проблемы.

Читать дальше...

Интересное видео опубликовал Вадим Макеев «Прототип изоляции стилей для Shower на веб-компонентах», где затрагивается вопрос изоляции css-стилей при верстке. Само видео посвящено одной из попыток реализации, но сама по себе тема (изоляции) мне кажется интересна, поскольку с ней сталкиваются практически каждый верстальщик.

В чём суть проблемы? CSS-стили имеют глобальную обрасть видимости. Не важно где объявлен стиль, он будет применён сразу ко всей html-странице. Пока html-код небольшой, особых проблем не возникает, поскольку элементарно решается за счёт именования css-классов. Но, как только html становится побольше, то именование классов должно быть более осмысленным, иначе разобраться в коде будет проблематично.

Читать дальше...

В процессе обучения на html-курсах у меня постоянно возникает потребность оценивать качество html-верстки учеников. Данная тематика очень большая и неоднозначная: о неё спотыкались почти все, что так или иначе использует чужой код. Некоторые компании придумывают сложные чек-листы, чтобы хоть как-то форматизировать свои требования. Другие, наоборот, упрощают подход: сайт «не разваливается», уже хорошо. :-)

Обычно смотрят сразу на весь сайт, поэтому часто возникают требования имеющие лишь второсепенное отношение к html-верстке. Например использование H1-заголовка и SEO-оптимизация. В данном случае верстальщик не обязан знать всю контекстную составляющую сайта, а в большинстве случаев, это даже неизвестно. Например в шаблонах CMS наполнением занимается конечный пользователь.

Существуют и другие, совершенно «безумные» требования, вроде запрета использовать !importantв CSS. То что это стандарт CSS, автор требования, видимо, не в курсе. Или только один css-файл на все страницы. C учётом lazy-загрузки данное требование можно трактовать исключительно как «вредное»...

Читать дальше...

Спецификация по Grid Layout опубликована уже достаточно давно, но вебмастера всё ещё редко используются grid-вёрстку. Тут две основные причины. Первая — распространенность IE11 (по статистике около 2%), которая, к тому же поддерживает только старую версию спецификации. Вторая — реальная потребность в grid не очень высока: существующего flex хватает для 90% стоящих задач.

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

Читать дальше...