Советы по структуре CSS для бизнес-сайтов (или любого другого в этом отношении)

CSS и HTML просты для понимания. Однако требуются годы практики, чтобы узнать о лучших архитектурных подходах при создании веб-сайтов (и приложений) таким образом, чтобы они были повторно использованы, поддерживались в будущем и оставались довольными разработчиками.

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

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

Создавайте с помощью компонентов, а не страниц

Это одна из основных частей, которую следует учитывать. Вы не должны использовать стиль в зависимости от страницы, на которой находитесь. Не используйте стили .homepage… {}. Если на вашей странице есть раздел, задайте для него стиль. При этом вы можете повторно использовать его и на других страницах. Если у вас есть кнопка, создайте для нее стиль, например .button {}, и используйте его в другом месте. Действует для всех просмотров.

Это наиболее распространенный совет и наиболее эффективный (пока) подход, который вы можете использовать.

Теперь, как вы справляетесь с различиями между страницами? Потому что это наиболее распространенная причина для постраничного стиля? Что ж, есть несколько подходов:

Используйте модификаторы.

В «БЭМ» буква «М» означает модификатор. Это вид модификатора .block__child. Даже если вы не используете БЭМ, модификаторы все равно существуют. Если есть вариант компонента или раздела, добавьте для него модификатор.

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

Стильные детские компоненты.

Другой подход - стиль, основанный на контексте. Кнопка всегда является кнопкой, у нее есть класс .button и все остальное, но вы все равно можете настроить ее, если она является частью другого компонента. Как правило, это не очень хорошая идея, поскольку создает несоответствия, но это также вполне реальный вариант использования. В противном случае вы получите 20 модификаторов со странными названиями.

Контекстно-зависимые стили - это стили для одного компонента, только если он является потомком другого. Возьмем, к примеру, карточку товара. По умолчанию он имеет свои стили. Но если это часть красочного раздела с текстом сбоку, дизайн требует, чтобы на карточке было несколько других элементов (например, анимированные фигуры и т. Д.).

В этом случае вы создаете стиль с помощью селектора .parent .card {}. Вам нужно будет перезаписать только несколько свойств, как если бы вы это сделали с модификатором. Когда вы это сделаете, сама карта не усложнит ее стили, но все равно будет вести себя правильно в этом конкретном пограничном случае.

Когда вы думаете об этом, вы также можете увидеть, как это можно применять для каждой страницы. Если в дизайне присутствуют какие-то странные крайние случаи и есть некоторые незначительные отличия от стандартных представлений компонентов (и того, как все они взаимодействуют друг с другом), вы можете стилизовать только это с помощью селектора .homepage {}. Только не забывайте использовать это экономно. По нашему опыту, такие стили редко превышают несколько строк кода.

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

Работа в разделах

Большинство бизнес-сайтов (как и многие другие в этом отношении) разделяют контент на разделы. Каждый раздел представляет собой отдельный компонент с классом-модификатором, определяющим различные свойства. Одно из предложений по структуре классов:

• section.section-container - это может быть «имя компонента», если хотите, которое содержит согласованные отступы / поля или все, что необходимо.
• section.section-border-top - это модификатор. При этом БЭМ не используется, но при необходимости вы можете «перевести» его в раздел-контейнер-границу.
• section.section-welcome - имя раздела.

Соглашение об именах здесь снова не имеет значения. С такими разделами вы получите свободу настраивать стили для многократно используемых компонентов в крайних случаях, созданных проектом (будь то из-за несоответствий, которые необходимо соблюдать, или просто из-за более сложных представлений).

Разделение файлов

Скорее всего, вы воспользуетесь Sass или другим подобным препроцессором. Что касается разделения файлов, существует много подходов, но тот, который мы используем, следует следующей общей структуре:

• Общие - Общие обычно состоят из кода настройки, такого как создание сетки, стилей для тегов HTML, сброса / нормализатора, некоторых стилей, специфичных для CMS, и тому подобного.
• Страницы - стили страницы, как описано выше. В идеале вам следует хранить здесь очень мало кода.
• Компоненты - ядро ​​сборки - здесь находятся различные компоненты. Один совет заключается в том, что у вас могут быть «элементы» или «разное», которые поместили бы более мелкие фрагменты компонентов в один файл вместо 80 файлов. Конечно, в идеале большие файлы должны храниться в отдельных файлах.
• Макет - глобальные стили, например, для макетов верхнего и нижнего колонтитула, а затем страниц, модификаторы сетки и т. Д.
• Плагины - что-либо внешнее, созданное из плагина, расширения или чего-то еще. Приятно разделить их, так как затем вы можете повторно использовать их в других проектах.

Держите селекторы в чистоте

Хороший признак чистого кода - это то, насколько он прост. Никаких необычных свойств, все имеет свое предназначение, небольшой отступ. «Умные» селекторы, когда они не нужны, не делают ваш код «крутым». Если вы можете заменить что-то вроде #container> .row div [rel = ”something”] на .rel-something (представьте, что это значимое имя класса), тогда вам следует просто немного обновить разметку. Цель состоит в том, чтобы все было проще.

Держите углубления низкими. Вам редко нужно проходить более трех уровней. Давайте посмотрим, например, на класс .entry:

.entry {...}
.entry-title {...}

Убедитесь, что нет необходимости делать отступ .entry-title внутри .entry. Позже, когда вы добавите модификатор в файл, у вас могут быть .entry-modifier {} и .entry-modifier .entry-title {}

При таком подходе в будущем будет намного проще перезаписывать стили. Давайте посмотрим на другой распространенный пример: у вас есть разметка nav.site-nav> ul.list-menu> li.list-items * 5> a (emmet)

Теперь для стиля все, что вам нужно, это:

.site-nav {} - компонент 1

.list-menu {} - компонент 2
.list-menu .list-item {}
.list-menu a {}

Если у вас внутри было больше компонентов, например, дополнительные выпадающие списки, вы можете вложить их прямо в .list-menu. Вам не нужно писать .site-nav .list-menu .list-item .dropdown {} (4 уровня в глубину), если у вас может быть два уровня .list-menu .dropdown {}

Напишите больше имен абстрактных классов для модификаторов

Это касается ремонтопригодности. Типичный пример, который вы можете найти в подобных сообщениях, - это не устанавливать для переменной цвета значение $ red, вместо этого вы должны установить значение $ primary или $ secondary.

Причина в том, что, когда требуется изменение в строке, переменная $ red будет выводить синий цвет. Более логично, что вы хотите изменить свой основной цвет, а не красный , верно?

То же самое касается других типов цветов и свойств. Допустим, у вас есть строки, разделяющие некоторый контент (например, тег <hr>). Вы назвали этот .line-dash, потому что он штриховой. Имеет смысл. Но затем наступает перемена, и ее нужно расставить точками. Вы идете и переименовываете его в .line-dotted? Это не модификатор, это компонент. Вместо этого вы можете назвать его .line-separator. А затем, если вы хотите быть конкретным, вы можете добавить модификатор для .dotted или .dashed. Этот тип именования часто занимает больше всего времени при создании сайта.

В итоге

Есть бесчисленное множество хороших и плохих практик. Один из способов добиться лучших результатов - определить правила и следовать им. Сложно придумать такие правила, поэтому одним из хороших предложений было бы поискать в Интернете и попытаться собрать всю возможную информацию об архитектуре, такую ​​как соглашения об именах, передовые методы, как писать поддерживаемый код и многое другое.

Чтобы создать хороший код, требуется много времени и сотни тысяч строк кода. Делая все это, всегда спрашивайте себя: «Будет ли эта шкала?», «Могу ли я использовать ее повторно?», «Я слишком много перезаписал?», «Имеет ли смысл называть ее так?». Чем больше вы это делаете, тем более оптимальными станут ваши решения и тем больше улучшится ваша скорость работы.

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