Как быстро осуществлять нейминг css классов для разносортных секций?
С английским всё хорошо, но проблема не в нём, а в невозможности как-то грамотно и быстро классифировать разные секции, чтобы на выходе получался хорошо организованный css код. БЭМ эту проблему также не решает, он лишь предлагает структуру имён, а не сами имена.
Также хочу отметить акцент на том, что проблема не с компонентами, такими как кнопки, селекты, формы и тд и тп, для них все стили уже давно написаны и названия придуманы. Проблема именно с секциями, в которых эти компоненты конечно же включаются, где они требуются, но компонентным подходом всю боль нейминга не устранить, т.к. у каждой секции иногда есть какой-нибудь уникальный элемент или своя собственная анимация, а значит такой секции нужно всё равно отдельно где-то прописывать стили, а для этого в свою очередь ей нужно уникальное название.
Например: есть дизайн с количеством секций равным n. Решения для нейминга довольно очевидны:
1) Нейминг по заголовку секций. Но бывают проекты, где у каждой из них заголовок в духе lorem ipsum, а значит с помощью этих тайтлов уже не возможно придумывать css классы для таких секций. Или ситуация, когда на одной странице секция с заголовком "about us", а на другой странице секция с точно таким же дизайном имеет заголовок "best sellers", то в итоге именование по заголовку приводит к путанице. Отпадает.
2) Далее на ум приходит забить на всё и нумеровать секции классами в стиле "section section-1", "section section-2". Решение хорошее и разработка действительно ускоряется в разы, но потом, когда требуется поддержка проекта - это превращается в кошмар на самом деле. Становится очень сложно ориентироваться в коде, имея в названиях лишь голые цифры. Так что не вариант (но иногда, когда клиенту горит сделать ещё вчера, то именно это я использую, благо работаю один, но если кто-то должен будет поддерживать такой код - я ему не завидую).
3) В проектах, где секции повторяются и их структура примерно одинакова работает вариант нейминга в духе что вижу, то и пишу: "image-with-text", "call-to-action" и тд. Но когда проект расширяется, или дизайнер вносит правки, то и вариативность таких секций возрастает. Я имею ввиду, когда например на каждой странице появляется своя секция call-to-action со своим уникальным дизайном, или когда к имеющимся секциям, названным в духе Image-with-text добавляется ещё куча подобных, но опять же, со своим уникальным лейаутом, стилями, то опять возникает путаница. Тут вроде как на помощь должен прийти БЭМ и модификаторы. Но когда у меня в одном проекте банальная секция call-to-action обросла кучей модификаторов, т.к. для каждой нужен был уникальный дизайн, то это тоже было не очень хорошо, код на мой взгляд был запутанный, по прошествии времени сложно было понять где какой модификатор для какого дизайна должен применяться. Хотя конечно это уже лучше, чем использовать тайтлы или нумерацию для классов.
4) Юзать хардкорный атомик. Пробовал - не очень зашло, когда потребовалась поддержка проекта.
Как вы решили эту проблему? Впринципе я итак уже перечислил все варианты, которые встречал за всю свою практику, но может быть есть решение проблемы нейминга вне плоскости нейминга, то есть может есть какие-нибудь инструменты для инкапсуляции css классов, как в реакте, но для обычной вёрстки, а не spa приложений? Конечно есть встроенный в css механизм инкапсуляции и можно забить на всё и писать классы духе "page-contact call-to-action", "page-product call-to-action" или опять же, через модификаторы: "call-to-action--page-product" и это работает, но почему-то такой код кажется грязноватым, и чутка избыточным, не так ли?
Ну тут скорее не вопрос, а крик души, который можно поддержать.
По делу: да, проблема есть, именовать на больших проектах сложно. Решений нет.
Вернее, только те, которые вам кажутся "грязными", но других не завезли (и не завезут).
И те, которые не относятся к разработке (вроде "дать люлей дизайнеру, который не понимает, как это всё работает, и лепит каждый элемент как попало")
Тут просто надо несколько абстрагироваться и принять то, что абсолютно в любой объёмной системе, даже если её вдруг пишет один человек (что вряд ли), всегда есть место неочевидным вещам. Перфекционист внутри рыдает, но что делать.
Откройте любое масштабное решение - чёрт ногу сломит, не так ли? И требуется немало времени, чтобы вникнуть. Потом вникаешь - и становится проще, но всё равно много нагромождено. А если выпасть из контекста на месяц - потом опять заново вникать. Это норма (картинка с Малышевой).
Стоит просто выбрать для себя какой-то стиль и строго ему следовать. И расширять словарный запас, чтобы играть словами.
Совмещение ваших пунктов 1 и 3 в одно - вполне здоровый стиль.
Если секция, где всё очевидно: about, gallery, text-section, etc.
Если контент неоднородный - именовать по смыслу (как в 3).
Единственное что мог бы посоветовать - не смущаться добавлять новые компоненты, задавая им какой-то дополнительный неймспейс (contacts-header, contacts-about), а не пытаться всё упихать в один общий с помощью модификаторов - в поддержке будет проще.
Просто размышления от прочитанного:
1. Подходы 2 ("section-1", "section-2") и 4 (атомарщина) - в аду для таких "специалистов" стоит отдельный котёл. Ну вы и сами понимаете. Использовать нужно никогда.
2. Инкапсуляция имён ничего не даёт в этом отношении, так как это придумано для элементов внутри блока (а с этим и концепция БЭМ хорошо справляется), глобально вам как разработчику всё равно нужно иметь понятное "корневое" название блока.
Ещё можно поработать со своей головой, возможно, что такой крик души идёт от страха быть осуждённым. Браузеру-то всё равно, вы ему хоть .qwerty123 { ... } скормите - нормально отобразится.
Понятные имена - для разработчиков, и надо понимать, что ни один толковый разработчик в вас камнем не бросит за то, что вы дали блоку имя .contacts-footer-call-to-action, если у вас этот самый .call-to-action в каждой секции настолько разный, что в один компонент не умещается.
Иногда помогает, если есть прямой выход на клиента или ЛПР донести, что такой дизайн... Ну не самый лучший для поддержки, и обосновать почему.
А чисто технически - решений нет, ну, вот такая работа, чё делать.
Единственное что мог бы посоветовать - не смущаться добавлять новые компоненты, задавая им какой-то дополнительный неймспейс (contacts-header, contacts-about), а не пытаться всё упихать в один общий с помощью модификаторов - в поддержке будет проще.
Вот это в точку, с модификаторами код запутанный становится как я и описывал.
Насчёт головы - есть такое, страх перед тем, что если криво напишу проект, то правки могут занимать много времени, особенно если другой кто-то будет править. И я чувствую, что излишне налегаю на качество написания кода, но когда выработаю нормальное решение для нейминга, то это пройдёт.
Максим, да у вас уже всё нормально. Разметки не видел, да и не надо - для меня показателем является то, что такой вопрос (крик души) возникает.
Дополнительно могу посоветовать (это для головы) посмотреть, как сверстаны многие популярные решения.
Чтобы далеко не ходить - посмотрите на штатные темы вордпресса (тихий ужас), посмотрите на какой-нибудь quilljs (просто последнее, на кастомизации чего громко матерился).
Сверстано ужасно, но решения популярны, работают.
Ещё крайне полезно немного проконсультировать других людей и осознать, что у подавляющего большинства море проблем с гораздо более очевидными вещами.
Простой
