С первых строк кода, каждый человек начинает понимать важность правильной его организации и оптимизации рабочего пространства в целом.
Не важно о какой отрасли говорить конкретно, но важно понимать что везде где есть код – должны быть правила его создания и хранения.
На первых парах конечно может показаться, что придерживание определенных правил и порядков лишь отнимает время, что на практике выглядит совсем иначе. Квинтэссенция любых принципов написания кода заключается в том, что мы не пишем его один раз и навсегда – мы постоянно возвращаемся к нему с целью редактирования и модификации.
Этот процесс может превратиться в настоящую проблемму, если там царит хаос и непредсказуемость. Эта проблемма может усугубиться если этот хаос был создан не тобой, а человеком с которым нет возможности установить контакт. Именно для устранения таких ситуаций и существуют методологии.
Если говорить о css, то с уверенностью можно сказать — каждый из нас пользуется определенной методологией, осознанно или нет. Даже если человек не использует определенные правила и стандарты, то у него все равно есть свои привычки и постоянно повторяющиеся приемы.
Способы написания кода не обязательно должны быть общепринятыми и стандартизированными, обязательным должно быть другое – они должны быть предсказуемыми.
Список методологий на которые стоит обратить внимание не так велик:
-BEM,
-Smacss,
-OOCSS,
-MCSS,
-Atomic CSS
Atomic CSS – пожалуй является самой необычной и даже в какой то мере пугающей методологией, что к счастью не мешает ей быть очень понятной и предсказуемой.
Что бы обосновать свой выбор я должен откатить немного назад.
Почти Атомарный CSS
Были времена, когда корневой каталог подавляющего количества проектов на стадии создания интерфейса выглядел как три файла и две папки:
>fonts
>img
-index.html
-style.css
-script.js
Но эта простота обманчиво может показаться удобной, на самом деле как в минимум в двух из трех этих файлов творилось нечто ужасное.
Меня всегда раздражало две вещи – беспорядок и отсутствие стиля. В Css под классификацию беспорядка попадает масса различных нюансов, но больше всех меня не устраивало постоянное повторение одних и тех же правил и свойст для разных селекторов.
Первым решением этой проблеммы были следующие действия:
- создание файла с названием “re-use.css”,
- создание в этом файле инструкций, которые в теории могут понадобиться больше чем одному селектору,
- дописывание разных селекторов к одной и той же инструкции.
Имело это следующий вид:
...
.class { display: inline-block;}
.class { text-transform: uppercase;}
...и в последствии принимало следующий:
...
.menu-link, .primary-button, .form-button, .footer-link, .social-link
{ display: inline-block;}
...
Конечно это решение было очень не удобным и к счастью временным. Недолго помучавшись с бесконечным переключенем между файлами, и поиском нужного места в них, я пришел к выводу что гораздо удобнее будет создать отдельные классы, отвечающие за одну инструкцию каждый:
…
.inline-block { display: inline-block;}
.block {display: block;}
.uppercase {text-transform: uppercase;}
В html файлах теги с большим количеством классов выглядели странновато, но это решение мне показалось вполне приемлемым:
<aside class=”sidebar fixed left top w-30 h-100 main-fill”></aside>С одного взгляда достаточно что бы понять что это боковая колонка, с фиксированным позиционированием, с левой стороны экрана, занимающая 30% его ширины и 100% высоты, залитая главным цветом.
Все что касалось числовых значений, в основном это были внешние и внутренние отступы, я записывал в стандартном формате. Для этого каждому тегу, или группе тегов я добавлял отдельный класс идущий первым, на примере выше это класс “slider”.
Это был почти атомарный и почти удобный подход. Удобным ему мешало стать несколько недостатков, важнейшим из которых были следующие ситуации:
- при создании большого количества похожих тегов, например элементов списка, приходилось много копировать классы и это выглядело громоздко,
- при внесении любых правок, приходилось удалять и дописывать классы для каждого элемента отдельно,
- оставалось много неиспользуемых классов которые было сложно отлавливать.
И тогда на помощь пришли две вещи, которые помогли решить все проблеммы – это препроцессор и шаблонизатор.
С их помощью я модифицировал свою методологию и сделал верстку приятной и удобной.
Почти идеальный Css
Начну с препроцессора. Его выбор не принципиален, изначально я пользовался Sass, потом SCSS и в итоге перешел на Stylus, потому что уважаю минимализм, а Stylus был максимально минималистичен (в примерах ниже будет использован scss, по причине его популярности).
Итак, первое что я сделал это написал дополнительные классы которые с помощью директивы @extend выглядели как настоящие атомы:
.flex {
display: flex;
flex-wrap: no-wrap;
}
.flex-jc-center {
@extend .flex;
justify-content: center;
}
.flex-ai-center {
@extend .flex;
align-items: center;
}Мне понравилась идея, а директива @extend вызвала сходство с ядром атома, рядом с которым были дополнительные инструкции.
Я решил что идею надо развивать и создал отдельный файл для организмов. Организмами я называл классы включающие в себя несколько директив @extend:
.header {
@extend .fixed;
@extend .w-100;
@extend .main-fill;
@extend .left;
@extend .top;
@extend .flex-ai-center;
@extend .z-top;
}Создав небольшой “зоопарк” из различных организмов, я решил что то сделать с классами которые требуют числовых значений для отступов и размеров.
С этим снова помогли справиться возможности препроцессора, с помощью которых я написал некоторые функции и добавил переменные.
Сначала я детально изучил графические проекты которые мне достаются от дизайнеров и выявил ряд закономерностей:
- количество цветов для каждого проекта,
- количество шрифтов,
- количество разных размеров для текста и заголовков,
- повторяющиеся отступы (для секций, кнопок и тд.)
Первым делом нужно было написать функции и миксины для создания нужных классов:
//создаем функцию для пересчета px в em
@function em($pixels, $context: $browser-context) {
@return #{$pixels/$context}em
};// создаем массив с размерами для текста
$text-size: (
l: 18,
m: 16,
s: 14,
xs: 12
);@mixin emFonts($list, $n) {
//создаем миксин $list – массив, n – Число на которое требуется уменьшить шрифт для адаптивности.
@each $status, $size in $list {
//используя интерполяцию - создаем класс для каждого из размеров
&-#{$status} {
font-size: em($size - $n);
//присваиваем нужные числовые значения тексту
}
}
}Теперь мы можем вызвать эту комбинацию из миксина и функции в любом удобном для нас месте:
.txt {
@include emFonts($text-size, 0)
}И на выходе получим 4 класса для текста разных размеров:
.txt-m { font-size: 1.125em; }
.txt-s { font-size: 1em; }Аналогичным образом создаются и вызываются функции для размеров заголовков, цветов текста и заливки, шрифтов и тд.
То есть работа над каждым проектом начинается с заполнения значений для переменных, а сами классы и функции кочуют из одного проекта в другой.
Шаблонизатор.
Я думаю многие из вас пользуются шаблонизаторами, и скорее всего – это Pug(который раньше назывался Jade).
Для атомарной верстки он необходим благодаря 3 вещам:
- миксины
- переменные
- циклы
Pug полностью избавляет нас от громоздкого из за микроклассов HTML кода, так как мы можем превратить следующий код:
…
<ul class=”menu__list flex-ai-center w-100 relative “>
<li class=”menu__item m-color m-font txt-s inline-block bold-border”>first</li>
<li class=”menu__item m-color m-font txt-s inline-block bold-border”>second</li>
<li class=”menu__item m-color m-font txt-s inline-block bold-border”>third</li>
</ul>в удобный для редактирования:
-let menuItemClasses = ‘menu__item m-color m-font txt-s inline-block bold-border’
//создав переменную содержащую все класы мы можем менять их в одном месте
ul
li(class=`${menuItemCLasses}`) frst
li(class=`${menuItemCLasses}`) second
li(class=`${menuItemCLasses}`) third
...
</ul>или в другом варианте, с помощью цикла:
let menuItems = [‘first’, ‘second’, ‘third’]
ul
-for(let item of menuItems) {
li(class=”menu__item m-color m-font txt-s inline-block bold-border”)
-}Это не менее удобно, ведь строка с нужными классами не повторяется больше одного раза.
Последнее уязвимое место данной методологии заключалось в том что в коде оставалось большое количество неиспользуемых классов. Но эта казалось бы серьезная проблемма легко решилась добавлением в сборщик проекта плагинов удаляющих ненужные классы.
Заключение
В заключении хотелось бы сказать следующее:
перед тем как начать пользоваться “почти атомарной методологией”, я долгое время использовал smacss и потом BEM. В итоге от bem я оставил лишь названия для классов требующих описания отступов и размеров, и иерархию хранения файлов и папок. Набор готовых классов и функций, я подключаю к проекту в качестве библиотеки.
Важный момент который хотелось бы отметить – это удобство верстки станиц и отдельных ее секций целиком. Благодаря микроклассам достаточно легко создать “скелет” страницы или секции в шаблонизаторе и только потом перейти к написанию для нее стилей.
