Расскажу про одну методику, которая позволяет достаточно быстро перевести макет страницы в HTML-код прототипа.

Например у нас есть лендинг. Как правило на первом этапе происходит сбор информации, а потом рисуется графический прототип. Это может быть обычный Ворд, или гугл-документы, но часто это сервис wireframe.cc. Мне он очень нравится, поскольку не содержит ничего лишнего и прост для работы. Ну и бесплатный, что тоже важно.

Иногда работу в wireframe.cc выполняет сам копирайтер. Там он не только пишет тексты, но и размечает блоки, которые по его мнению можно скомбинировать определённым образом. Когда всё готово, этот макет получает html-верстальщик, который должен перенести тексты (это простое копирование) и разверстать блоки, только уже в HTML-код.

Здесь есть очень важный момент — первая версия вёрстки должна повторять макет wireframe.cc (это может быть любой другой сервис — я привожу его только как пример). То есть не нужно верстать в цвете, задавать все изображения, настраивать отступы: нет — это будет тоже черновой вариант, но только выполненный в html-коде.

Читать ➝

CSS-переменные всё больше используются при вёрстке, поскольку это довольно удобный инструмент, упрощающий работу. Если не оглядываться на IE11, то css-переменные хорошо поддерживаются браузерами. Во всяком случае все современные версии без проблем.

Концепция css-переменных очень проста, но судя по многочисленным публикациям, она создаёт определённое непонимание на уровне «а зачем они вообще нужны?». Как правило верстка выполняется с помощью препроцессоров (в первую очередь Sass). Но поскольку там уже есть свои переменные, то становится непонятно, зачем ещё создавать их на уровне CSS.

Ответ кроется в понимании того, для кого именно создаются css-переменные и какое у них будет назначение.

Читать ➝

Начну с истории. :-) Первая версии 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'а.

Читать ➝

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

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

Читать ➝