Мы всегда стараемся узнать что-то новое. Тем не менее, мы также пытаемся узнать способы усовершенствования привычного. Нам всегда хотелось улучшить CSS, что помогло бы и в нашей работе, и в побочных проектах. Всегда казалось, что мы довольно хорошо разбираемся, когда дело доходит до CSS, но иногда было попросту сложно прочесть его.
То, что мы пытаемся сделать – это выяснить, что создает хороший, читаемый, поддерживаемый CSS. Мы думаем, что придумали (и нашли) некоторые способы, чтобы сделать все это возможным.
Проблемы
Есть несколько вещей, которые беспокоят меня в CSS. Вот мои наиболее распространенные раздражители:
- повторение общего кода
- браузерные префиксы
- отсутствие комментариев
- сверхсложные селекторы
- плохие названия классов
Когда дело доходит до моих личных проектов, я беру на себя полную ответственность за код. Я редко комментирую свой CSS и часто рассматриваю это как дополнительное. Это неправильно.
В течение долгого времени я полагал, что мои названия классов “семантические”, и занимаюсь этим я, так что нет никакой необходимости объяснять код, или маленькие “хаки”, или что-либо другое.
Возвращение к коду давнего проекта быстро опровергло эту теорию.
Когда дело доходит до кода на работе, я не могу взять всю вину на себя. На самом деле, этим занималось определенное количество людей.
В настоящее время в нашей команде семь человек, которые в какой-то момент писали CSS для наших сайтов, и еще 6-8, которые приходили и уходили за последние годы. Каждый член команды имеет различные уровни знаний и умений относительно CSS.
Кроме того, как это часто бывает с давними проектами, что-то из кода устарело. Многое из этого это CSS3, или то, что было модным и интересным 5 лет назад. В обоих случаях, в то время существовали различные способы написания кода, а в некоторых случаях, естественное отсутствие знаний.
Я также узнал, что некоторые программисты утверждают, что их код “самодокументирующийся”. Если вы не знакомы с этим термином, он переводится как “у моего кода нет комментариев”.
Решения
Нет ничего совершенного, поэтому я считаю, что мы можем улучшить наш код, исправив некоторые вещи. Недавно я открыл для себя CSS Guidelines, написанное Harry Roberts. Оно действительно рассказывает о “советах и руководящих принципах высокого уровня для написания здравого, управляемого, масштабируемого CSS”.
Комментарии
В то время как CSS Guidelines дает спецификации стилей, я кое-что вставлю для будущего себя. Я начинаю каждый компонент с комментария, представляющим название и детали компонента.
При использовании препроцессора я задаю стиль, чтобы определенные комментарии либо включались в CSS, либо были пропущены препроцессором. Я все еще работаю над этой частью.
Объектная ориентация
Объектная ориентация – это парадигма программирования, которая разбивает большие вещи на маленькие.
Объектно-ориентированное программирование (ООП) – парадигма программирования, в которой основными концепциями являются понятия объектов и классов, используемые для взаимодействия друг с другом, чтобы разрабатывать приложения и компьютерные программы.
Когда дело касается CSS, мы называем это объектно-ориентированный CSS, или OOCSS. Основная концепция разбивает структуру элемента с его оболочки. Это означает, что мы можем легко повторно использовать любые повторяющиеся паттерны проектирования, без необходимости повторного использования определенных деталей реализации в то же время. OOCSS фокусируется на повторном использовании кода, что ускоряет процесс, и может сохранить размер нашего кода.
Я рассматриваю структурные аспекты, как скелеты; общие рамки, которые дают конструкциям объекты. Эти объекты являются простыми шаблоны проектирования, которые ничем не приукрашены. Мы извлекаем структуру из множества компонентов, чтобы получить общий объект.
Затем мы по желанию добавляем слой “оболочки” к нашей структуре таким образом, что мы можем придать абстракциям конкретный внешний вид. Например (взято из CSS Guidelines):
/**
* A simple, design-free button object. Extend this object with a `.btn--*` skin
* class.
*/
.btn {
display: inline-block;
padding: 1em 2em;
vertical-align: middle;
}
/**
* Positive buttons' skin. Extends `.btn`.
*/
.btn--positive {
background-color: green;
color: white;
}
/**
* Negative buttons' skin. Extends `.btn`.
*/
.btn--negative {
background-color: red;
color: white;
}Здесь мы видим, как класс .btn просто предоставляет структуру для элемента, но не приукрашивает. Мы можем расширить .btn со вторым классом, как .btn—positve, чтобы придать этому элементу более конкретный стиль:
<button class="btn btn--positive">OK</button>
Я предпочитаю использовать несколько классов в моем HTML, по сравнению с использованием чего-то вроде @extend в препроцессоре. Это дает мне больше видимости в моем HTML, позволяя мне быстро увидеть, какие классы применяются к моему элементу. Это также означает, что мои классы не тесно связаны с другими стилями в моем CSS. Это своего рода помогает OOCSS следовать концепциям инкапсуляции.
БЭМ
БЭМ (Блок, Элемент, Модификатор) является фронтенд методологией, разработанной в Яндексе. БЭМ на самом деле очень полная методология, и я, честно говоря, не копался во всех деталях, но то, что меня интересует это просто naming convention.
Я использую БЭМ-подобные naming conventions. Концепция та же, но точный синтаксис может незначительно отличаться.
БЭМ распределяет классы на три группы:
- Блок: корень или основа компонента
- Элемент: компонент внутри блока
- Модификатор: изменение или расширение Блока
Очень простая аналогия (не пример):
.dog {}
.dog__tail {}
.dog--small {}- каждый класс делает одну вещь – он делает это хорошо, он делает это правильно
Блок, Элемент, Модификатор (БЭМ) названия классов:
- Блок: .grid
- Элемент: .grid__item (2 подчеркивания)
- Модификатор: .grid–wide (2 дефиса)
Высоких конверсий!
