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

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

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

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

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

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

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

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и научитесь верстать современные сайты на HTML5 и CSS3

Узнать подробнее

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

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

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

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

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

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

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

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

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

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

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

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

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и научитесь верстать современные сайты на HTML5 и CSS3

Узнать подробнее

Работать с 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

Узнать подробнее

PSD to HTML

Практика верстки сайта на HTML5 и CSS3 с нуля

Получить

Метки:

Похожие статьи:

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

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

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

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

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

Я не робот.

Spam Protection by WP-SpamFree