Семантические имена классов слишком общие?

Семантические имена классов слишком общие?

От автора: процесс именования в HTML и CSS обманчиво сложен, но и очень важен. Краеугольными камнями MaintainableCSS являются предписания о том, КАК и ЗАЧЕМ мы должны именовать модули. Не случайно это одна из первых глав в книге.

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

Даже если вы не будете использовать стилистические или поведенческие имена классов, вы все равно запутаетесь. Все ваши кульбиты с именованием будут или слишком общими или слишком специфичными.

Большинство разработчиков делают слишком общие имена. И это не просто так, по крайней мере, в теории. Они делают так, потому что чем расплывчатей, тем больше этот элемент можно использовать повторно. Но в жизни все не так просто.

Лучший способ показать это – разобрать пример вместе.

К примеру, вы создаете форму авторизации с полями email и пароль. Вы можете именовать эти элементы следующим образом:

<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>

Имена классов специфические, к тому же они используют модуль формы авторизации.

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

.loginForm,
.someOtherForm {
  /* Общие стили контейнера */
}
.loginForm-email,
.loginForm-password,
.someOtherForm-someField {
  /* Общие стили полей */
}

В зависимости от сайта стилей будет больше или меньше, что не очень приятно.

К примеру, компонентам .loginForm-email и .loginForm-password можно дать более общие имена типа .loginForm-field.

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

Мы можем абстрагировать эти компоненты в свой собственный модуль с названием .formField.

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

Возьмем этот общий, повторно используемый модуль .formField и найдем в нем возможные проблемы.

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

Тут нам поможет modifiers. Нужно всего лишь добавить еще один класс к элементу и внести требуемые правки.

<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

Источник: https://medium.com/

Редакция: Команда webformyself.

Практика HTML5 и CSS3 с нуля до результата!

Получите бесплатный пошаговый видеокурс по основам адаптивной верстки с полного нуля на HTML5 и CSS3

Получить

Метки:

Комментарии Вконтакте:

Комментарии Facebook:

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

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

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Я не робот.

Spam Protection by WP-SpamFree