От автора: процесс именования в HTML и CSS обманчиво сложен, но и очень важен. Краеугольными камнями MaintainableCSS являются предписания о том, КАК и ЗАЧЕМ мы должны именовать модули. Не случайно это одна из первых глав в книге.
В этой главе я рассказываю о том, что вы должны именовать модули по факту, а не на основе того, как они выглядят или ведут себя. Проблема в том, что, даже зная это и используя логические имена, проблема никуда не девается.
Даже если вы не будете использовать стилистические или поведенческие имена классов, вы все равно запутаетесь. Все ваши кульбиты с именованием будут или слишком общими или слишком специфичными.
Большинство разработчиков делают слишком общие имена. И это не просто так, по крайней мере, в теории. Они делают так, потому что чем расплывчатей, тем больше этот элемент можно использовать повторно. Но в жизни все не так просто.
Лучший способ показать это – разобрать пример вместе.
К примеру, вы создаете форму авторизации с полями email и пароль. Вы можете именовать эти элементы следующим образом:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
<div class="loginForm"> <form> <div class="loginForm-email"> <label>...</label> <inputtype="email"> </div> <div class="loginForm-password"> <label>...</label> <input type="password"> </div> </form> </div> |
Имена классов специфические, к тому же они используют модуль формы авторизации.
Это можно назвать хорошим примером именования. На это есть две причины. Во-первых, вы можете стилизовать эту форму, не затрагивая другие формы. Во-вторых, если вы захотите, вы можете добавить в эту форму общие стили для всех форм на сайте. Сделать это можно с помощью нескольких селекторов через запятую или же с помощью миксина (если вы используете препроцессор):
|
1 2 3 4 5 6 7 8 9 |
.loginForm, .someOtherForm { /* Общие стили контейнера */ } .loginForm-email, .loginForm-password, .someOtherForm-someField { /* Общие стили полей */ } |
В зависимости от сайта стилей будет больше или меньше, что не очень приятно.
К примеру, компонентам .loginForm-email и .loginForm-password можно дать более общие имена типа .loginForm-field.
Как по мне, такое именование все еще довольно специфично, так как поля привязаны к модулю loginForm. Множество форм могут содержать такие поля с такими же стилями. В конце концов, последовательность – важная часть дизайна.
Мы можем абстрагировать эти компоненты в свой собственный модуль с названием .formField.
Интересно то, что все три класса именованы по принципам MaintainableCSS, но все по-разному влияют на обслуживание, масштабируемость и модульность кода.
Возьмем этот общий, повторно используемый модуль .formField и найдем в нем возможные проблемы.
Что делать в ситуациях, когда требуется слегка измененный модуль .formField с дополнениями? И что если всем полям с этими дополнениями нужны дополнительные или другие стили?
Тут нам поможет modifiers. Нужно всего лишь добавить еще один класс к элементу и внести требуемые правки.
|
1 2 3 4 5 6 7 8 9 10 11 |
<div class="someForm"> <div class="formField"> <label>...</label> <input type="text"> </div> <div class="formField formField-withHint"> <label>...</label> <p>The hint goes here</p> <input type="text"> </div> </div> |
В этом примере нужно внести немного изменений. Но что делать, если изменения более существенные, как поле с набором радиокнопок?
Работать с modifier проблематично, так как в нем низкое наследование. Когда мы думали о .formField, мы ведь не учли радиокнопки вообще, так ведь?
В принципе, это неплохо, во многих отношениях даже хорошо. Зачастую мы сталкиваемся с тем, что, не понимая требований к дизайну, мы не можем объединить разные вещи во что-то единое.
Чисто технически, все элементы можно назвать .item и все, но это не практично.
Набор радиокнопок отличается от текстового поля. У такого поля должна быть своя легенда, другой вид и ощущения. На деле же, поля настолько отличаются, что, несмотря на то, что это поля формы, их нельзя рассматривать, как что-то одинаковое. И это главное, над чем стоит задуматься.
Мы подошли к той точке, когда стало ясно, что название .formField слишком общее. Я точно не хочу обновлять стили для набора радиокнопок и заботиться о регрессе стилей в текстовом поле. Также я не хочу разрабатывать какие-то общие стили, чтобы уменьшить CSS код.
Так, где же остановиться?
Мы начали со слишком специфического именования и закончили слишком общим, а мы ведь так старались.
Если .formField – слишком обще, а .loginForm-email и .loginForm-field – слишком специфично, так в какую же сторону двигаться?
Разобрав эти проблемы детально, намного легче разработать лучший способ именования. Текстовые поля можно назвать .textField, а группы радиокнопок — .radioGroupField. Эти поля можно рассматривать, как отдельные модули.
Поля получились достаточно специфичными, чтобы мы могли что-то в них изменять, и достаточно общими, чтобы повторно использовать их в других формах без написания дополнительного CSS кода.
Реальная проблема заключается в том, что мы сталкиваемся с такими решениями все время. Мы должны часто и досконально рассматривать такие эти проблемы.
Вот почему я больше предпочитаю более специфичное именование. Я лучше напишу чуть больше CSS кода, чтобы иметь возможность гибко стилизовать элементы общими или разными стилями, чем попаду в ловушку, когда мне придется переписывать код. Я не говорю, что мой вариант идеален. Но именно по этой причине я лучше буду делать так и буду советовать его другим.
Создавая более специфичные имена, у вас есть время изучить страницу и понять, что нужно абстрагировать, а что нет. Вы можете прийти к тому, что поле .textField – слишком общее, так как текстовые поля бывают совершенно разных типов. В таком случае лучше, чтобы все текстовые поля были в своих модулях.
Что нужно вынести из этой статьи? Думать и задавать вопросы нужно часто и строго.
1. Что если модуль используется во множестве разных мест, но иногда он должен отличаться на основе положения, контента и т.д.?
В таком случае лучше использовать modifier.
2. Что если компонент может использоваться очень часто и в любом месте?
Абстрагируйте в модуль, но не давайте совсем общего имени.
3. А что если ты тратишь много времени на написание множества различных модификаторов или думаешь, что абстрагировать в общие стили?
Возможно, элемент имеет слишком общее название. Разбейте класс на отдельные модули.
Вывод
Процесс именования – задача сложная, но, как вы видите, преимущества или последствия именования далеко идущие. Плюс в том, что если с самого начала все продумать, то можно избежать проблем, которые будут появляться из-за либо слишком общих названий, либо из-за слишком специфических.
Автор: Adam Silver
Источник: //medium.com/
Редакция: Команда webformyself.
