CSS: унификация классов и прототипирование (часть 1)
19-12-2014Время чтения ~ 6 мин.CSS, HTML, LESS, SASS 12437
В процессе работы с Landing Page Framework постоянно возникало желание как-то унифицировать используемые css-классы. Проблема именования классов до боли знакома каждому верстальщику. Любой, даже самый примитивный, чисто «технический» блок, потребует своего уникального класса, чтобы указать стили, даже если это всего одна строчка кода.
Избыток классов порождает проблему идентификации: чем top-header отличается от top-head2? Это знает только верстальщик.
Чтобы навести хоть какой-то порядок, стали придумывать различные методики: самая известная (хотя и очень спорная) BEM. Такой подход решает исключительно одну проблему — имя класса получает хоть какую-то осмысленность и вносит ясность для другого верстальщика, которому придется разбираться в коде в будущем.
Потихочечку я придумал свой вариант UniCSS. Формально это CSS/Sass-фреймворк, но на деле его можно считать простой методикой, которая семантична для вебмастера и годится для rapid prototyping (быстрое прототипирование).
UniCSS - старая разработка, которая трансформировалась в Berry CSS.
В UniCSS основная идея именования классов в том, чтобы предусмотреть различные префиксы, постфиксы и модификаторы так, чтобы они были понятны вебмастеру почти на интуитивном уровне. Ну или с первого раза. Например класс mar25-rl однозначно будет понят как margin-right: 25px; margin-left: 25px;. Единственная проблема с которой пришлось столкнуться — это длинные префиксы. Пришлось их сократить, чтобы немного уменьшить результирующий css-файл. Скажем иконки это i-, а не icon-, поскольку это сокращает файл почти на 2 Кб.
Второй важной особенностью UniCSS является его отличная способность к прототипированию сайтов.
Вообще, для тех, кто не курсе куда движется современная веб-верстка, отмечу, что основной тренд — rapid prototyping — то есть быстрое прототипирование и создание сайта. За последние годы наработана огромная база css/html-решений так, что теперь можно верстать чуть ли не copy/paste, поправив лишь мелкие детали. То есть уже никто не думает как сделать сетку в три колонки с адаптивностю — всё уже тысячу раз оговорено и разжевано.
Таким образом мировой тренд повернулся в сторону решений, которые помогут не только быстро сверстать сайт, но и сделать его красивым под какой-то предопределённый набор UI-элементов. Если над 1-й и 2-й версией Bootstrap все «веселились», то тройка демонстрирует уверенный рост и в качестве кода, и в симпатичных дизайнерских решениях.
Но если Bootstrap всё-таки на любителя, то Foundation5 демонстрирует куда более впечатляющие возможности. Мой же фаворит UIkit помимо отличного UI, содержит почти образцовый css-код. А особенно впечатляет в UIkit он-лайн кастомизация.
Такие CSS-фреймворки постепенно изменили и сам подход к верстке сайтов. Мне самому поначалу было сложно перестроить привычки, но сделав несколько сайтов по-новому, невольно начинаешь понимать, что это действительно быстро и удобно.
«Традиционный» подход к верстке требует именования каждого значащего блока (тэга, неважно) в HTML-коде, а вся работа по верстке происходит уже в CSS-файле.
«Новый» подход предполагает использование уже готового css-кода, а вся верстка (ну почти вся) происходит в HTML-коде путем расстановки предопределенных классов.
Например, в традиционном варианте для создания сетки потребуется придумать класс для контейнера и всех ячеек. После задать их стили в css-файле. В новом же, стили готовы, всё что требуется это указать нужные css-классы. Здесь можно вообше не обращаться к css-файлу.
CSS-фреймворки содержат свои варианты классов и, поскольку их много, должны быть хорошо документированы. В том же UIkit все классы начинаются с префикса uk-. Понятно, что идея в том, чтобы отделить классы фреймворка от любых других стилей. Но очень тяжело представить себе вебмастера, который решит на одном сайте использовать сразу два фреймворка. То есть чтобы использовать привычный clearfix нужно знать, что это uk-clearfix. Таких примеров будет много и здесь главная сложность в неявном именовании. То есть если это какой-то сложный toolbox, то это понятно, но совершенно неясно какой класс использовать для желтого цвета и зеленого фона.
Глобально проблему семантики пытался решить только один css-фреймворк Semantic UI, но по мне, так он «переиграл» сам себя: количество двойных-тройных и более классов просто зашкаливает. И это при том, что они между собой связаны.
Таким образом как бы не старались разработчики, css-фреймворками можно пользоваться только с подробной документацией или постоянно обращаясь к исходному коду.
Вторая особенность css-фреймворков — их «заточенность» под определенный дизайн и элементы. Это не плохо, когда нужно сделать быстро, но уже сложно, когда требуется что-то нетиповое. Например изменить цвет, размеры — всё становится уже не таким очевидным.
Скажем почему я должен использовать только 12-колоночную сетку с предопределенными промежутками и адаптивным поведением? Почему, например, нельзя сделать двуколоночную сетку 29% и 14% с промежутком 8% выровненным по центру, но смещенным слева на 50px? Подобные задачи css-фреймворки не решают, потому что у них есть базовый UI с типовым поведением. Это серьёзное ограничение. Не зря сайты, созданные на одном фреймворке, как правило, похожи друг на друга: цвета соврадают, характерные тени, скругления, градации, размеры, отступы и похожие элементы.
Одним из этапов верстки предполагается прототипирование. Это когда рабочий макет страницы постепенно приближается к требованию клиента. На этом этапе не так важны все тонкости и детали, но важно расположение элементов. Причем всё это нужно делать быстро и просто. Например верстается форма. Форма может быть ячейкой сетки, пусть 20% ширины. Пока форма делалась как «рыба», всё красиво смотрелось. Но тут клиент дал реальные данные. Теперь, чтобы всё красиво смотрелось нужно изменить ширину на 18% и дать дополнительные оступы. Потом ещё 26 разных правок...
CSS-фреймворки не предоставляют возможности выполнять такую правку, поскольку не содержат в своем составе нужных классов.
Данную проблему, как раз и решает UniCSS (сейчас это Berry CSS). Открою небольшой секрет как он создавался.
Изначально я набросал некий каркас, как мне казалось, подходящий на все случаи жизни. Но выяснилось, что мноих вещей просто не хватало. Например были классы mar-small (margin 5px — это настраивается через less), mar (обычный — 15px) и mar-large (50px). И выяснилось, что на одной странице может потребоваться не только 5px, но и 10px и 25px. Или на одном сайте mar-small был 5px, а на другом 8px. То есть mar-small — класс неопределенный и другой вебмастер просто не поймет сколько это в пикселах.
Поэтому я сделал простой шаг — стал писать с помощью inline-стиле. Это позволило точно понять какие классы для стилей действительно востребованы, какие лишние, а какие нужно ещё добавить.
Я не могу сказать, что UniCSS — это уже готовый фреймворк. Он меняется постоянно, но вся прелесть в том, что какие именно классы нужны решает вебмастер. Фреймворк написан на Sass. Часть кода для удобства вынесена в переменные. Типовые хелперы (собственно это и есть фреймворк) могут их использовать, что позволяет автоматически менять весь код. Например используемые цвета и бызовые отступы. Если какие-то классы не нужны, просто их удаляем или меняем на свой вариант. Скажем иконки FA можно заменить на другие.
Ну и по сравнению с другими css-фреймворками, здесь мало кода. Разобраться сможет даже новичок.
Чтобы двигаться дальше, заранее отвечу на типовые замечания вебмастеров.
«CSS-фреймворки плохи тем, что там много неиспользуемого кода». Это так. Но для браузеров это не проблема и не сказывается на производительности. Основная «сложность» для браузера это тени, анимация и прочие подобные дизайнерские решения в момент отрисовки. Парсинг же css-кода выполняется мгновенно. Неиспользуемые css-классы браузер даже не трогает. Он работает только с тем, что реально нужно.
«Фреймворки плохи тем, что размер css-файла очень большой». Если мы говорим о трафике, то ситуация довольно простая: нужно использовать gzip-сжатие сервера. Это позволяет уменьшить размер трафика для текстовых файлов во много раз. Посмотрите сами на результат: Uikit — 14Кб, Foundation — 18Кб, Bootstrap - 18Кб, Semantic — 36Кб. Или UniCSS (в моем варианте с типографикой и всеми иконками FA) — 10Кб.