Хабрахабр

Атомарный CSS — порядок и чистота

С первых строк кода, каждый человек начинает понимать важность правильной его организации и оптимизации рабочего пространства в целом.
Не важно о какой отрасли говорить конкретно, но важно понимать что везде где есть код – должны быть правила его создания и хранения.

Квинтэссенция любых принципов написания кода заключается в том, что мы не пишем его один раз и навсегда – мы постоянно возвращаемся к нему с целью редактирования и модификации. На первых парах конечно может показаться, что придерживание определенных правил и порядков лишь отнимает время, что на практике выглядит совсем иначе.

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

Даже если человек не использует определенные правила и стандарты, то у него все равно есть свои привычки и постоянно повторяющиеся приемы. Если говорить о css, то с уверенностью можно сказать — каждый из нас пользуется определенной методологией, осознанно или нет.

Способы написания кода не обязательно должны быть общепринятыми и стандартизированными, обязательным должно быть другое – они должны быть предсказуемыми.

Список методологий на которые стоит обратить внимание не так велик:

-BEM,
-Smacss,
-OOCSS,
-MCSS,
-Atomic CSS

Atomic CSS – пожалуй является самой необычной и даже в какой то мере пугающей методологией, что к счастью не мешает ей быть очень понятной и предсказуемой.
Что бы обосновать свой выбор я должен откатить немного назад.

Почти Атомарный CSS

Были времена, когда корневой каталог подавляющего количества проектов на стадии создания интерфейса выглядел как три файла и две папки:

>fonts
>img
-index.html
-style.css
-script.js

Но эта простота обманчиво может показаться удобной, на самом деле как в минимум в двух из трех этих файлов творилось нечто ужасное.

В Css под классификацию беспорядка попадает масса различных нюансов, но больше всех меня не устраивало постоянное повторение одних и тех же правил и свойст для разных селекторов. Меня всегда раздражало две вещи – беспорядок и отсутствие стиля.

Первым решением этой проблеммы были следующие действия:

  • создание файла с названием “re-use.css”,
  • создание в этом файле инструкций, которые в теории могут понадобиться больше чем одному селектору,
  • дописывание разных селекторов к одной и той же инструкции.

Имело это следующий вид:

...
.class
.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”) -}

Это не менее удобно, ведь строка с нужными классами не повторяется больше одного раза.

Но эта казалось бы серьезная проблемма легко решилась добавлением в сборщик проекта плагинов удаляющих ненужные классы. Последнее уязвимое место данной методологии заключалось в том что в коде оставалось большое количество неиспользуемых классов.

Заключение

В заключении хотелось бы сказать следующее:

В итоге от bem я оставил лишь названия для классов требующих описания отступов и размеров, и иерархию хранения файлов и папок. перед тем как начать пользоваться “почти атомарной методологией”, я долгое время использовал smacss и потом BEM. Набор готовых классов и функций, я подключаю к проекту в качестве библиотеки.

Благодаря микроклассам достаточно легко создать “скелет” страницы или секции в шаблонизаторе и только потом перейти к написанию для нее стилей. Важный момент который хотелось бы отметить – это удобство верстки станиц и отдельных ее секций целиком.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»