Как называть блоки в html

Соглашение по именованию

Для работы с БЭМ-сущностями необходимо ознакомиться с правилами их именования.

Основная идея соглашения по именованию — сделать имена CSS-селекторов максимально информативными и понятными. Это поможет упростить разработку и отладку кода, а также решить некоторые проблемы веб-разработчиков.

В качестве примера рассмотрим CSS-селектор menuitemvisible . Быстрый просмотр такой записи не дает возможности определить типы БЭМ-сущностей по имени.

menu-item-visible или menuItemVisible

В таком виде имя селектора явно разделяется на логические части. Можем предположить, что menu окажется блоком, item — элементом, а visible — модификатором. Однако в реальной жизни часто возникают более сложные и не столь однозначные случаи, решить которые помогает соглашение по именованию БЭМ.

БЭМ-методология предоставляет идею по созданию правил формирования имен и свой способ ее реализации — соглашение по именованию CSS-селекторов. Однако в мире веб-разработки существует ряд альтернативных схем, основанных на принципах БЭМ.

Соглашение по именованию CSS-селекторов

• Имена БЭМ-сущностей записываются с помощью цифр и латинских букв в нижнем регистре.
• Для разделения слов в именах используется дефис ( — ).
• Для хранения информации об именах блоков, элементов и модификаторов используются CSS-классы.

Правила формирования имен:

Имя блока

Имя блока формируется по схеме block-name и задает пространство имен для элементов и модификаторов.

Иногда к именам блоков могут добавляться различные префиксы. Подробнее о нашем опыте использования префиксов рассказывается в статье История создания БЭМ.

Пример

Имя элемента

Пространство имен, заданное именем блока, определяет принадлежность элемента к данному блоку. Имя элемента отделяется от имени блока двумя подчеркиваниями ( __ ).

Полное имя элемента создается по схеме:

Если блок имеет несколько одинаковых элементов, как в случае пунктов меню, то все они будут иметь одинаковые имена menu__item .

Важно! В методологии БЭМ не существует элементов элементов.

Пример

Имя модификатора

Пространство имен, заданное именем блока, определяет принадлежность модификатора к данному блоку или его элементу. Имя модификатора отделяется от имени блока или элемента одним подчеркиванием ( _ ).

Полное имя модификатора создается по схеме:

Для булевых модификаторов — owner-name_mod-name .

Для модификаторов вида «ключ-значение» — owner-name_mod-name_mod-val .

Модификатор блока

• Булевый модификатор.

Значение такого модификатора не указывается. Полное имя создается по схеме:

Пример

• Модификатор типа «ключ — значение».

Значение модификатора отделяется от имени одним подчеркиванием ( _ ). Полное имя создается по схеме:

Пример

Неверная форма записи

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

Модификатор элемента

• Булевый модификатор.

Значение такого модификатора не указывается. Полное имя создается по схеме:

Пример

• Модификатор типа «ключ — значение».

Значение модификатора отделяется от имени одним подчеркиванием ( _ ). Полное имя создается по схеме:

Пример

Пример использования соглашения по именованию

Реализация формы аутентификации в HTML и CSS:

Альтернативные схемы именования

Существуют альтернативные решения, основанные на соглашении по именованию БЭМ.

Стиль Гарри Робертса

Одним из первых, кто заговорил о БЭМ в англоязычном мире, был Гарри Робертс. В своей статье MindBEMding – getting your head ’round BEM syntax он рассказал о соглашении по именованию CSS-классов по БЭМ-методологии. Гарри Робертс предложил свою схему именования, основанную на принципах БЭМ:

• Имена записываются в нижнем регистре.
• Для разделения слов в именах БЭМ-сущностей используется дефис ( — ).
• Имя элемента отделяется от имени блока с помощью двух подчеркиваний ( __ ).
• Булевые модификаторы отделяются с помощью двух дефисов ( — ).
• Модификаторы вида «ключ-значение» не используются.

Стиль CamelCase

Данный стиль отличается от классического использованием CamelCase вместо дефиса для разделения слов в именах БЭМ-сущностей.

Стиль без подчеркиваний

• Для записи имен используется CamelCase.
• Имя элемента отделяется от имени блока с помощью одного дефиса ( — ).
• Для отделения модификатора используется два дефиса ( — ).
• Значение модификатора отделяется от его имени с помощью двух дефисов ( — ).

Стиль No-namespace

Основное отличие данного стиля в отсутствии имени блока и/или элемента перед модификатором. Такая схема накладывает ограничения на использование миксов, так как не дает возможности определить, к какому блоку/элементу относится модификатор.

Какой стиль выбрать

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

Помимо этого, БЭМ-методология не ограничивается использованием технологий HTML и CSS, рассмотренных в этом документе. Понятия блоков, элементов и модификаторов применяются при работе с JavaScript, шаблонами и файловой системой БЭМ-проекта. Инструмент bem-naming позволяет применять одинаковые имена БЭМ-сущностей во всех используемых технологиях реализации.

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

Ошибки именования в вёрстке

Именование — сложная задача как для начинающих, так и для опытных разработчиков. Выбор правильного названия элемента — залог читабельной вёрстки, при которой она понятна при одном взгляде на классы. Неважно, что вы используете в работе: БЭМ, OOCSS, SMACSS, или не используете методологий вообще — выбирайте имя с умом.

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

Смысл

Это одна из самых частых ошибок в именовании. Встретив в HTML класс section-top , можно запутаться:

• Это первая секция?
• Это область заголовка внутри секции?
• Это фиксированная секция?

Без изучения вёрстки и CSS узнать это невозможно.

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

Сейчас всё расположено логично, проблем не будет. Но вот приходит заказчик и просит поменять секции местами. Теперь вёрстка выглядит так:

Такое изменение изменило представление о том, как структурирована вёрстка. Если изменение месторасположения блока ломает логический порядок из-за названий классов, то стоит пересмотреть подход к именованию.

Опишите то, о чём секция, если в этом есть необходимость. Если секция содержит список цен, то класс pricing , pricing_section будет хорошим вариантом. Если стили этих классов совпадают, то имеет смысл создать отдельный класс, например container или section-wrapper .

Нотация

Разные подходы к написанию CSS породили разные варианты написания классов. Это могут быть:

• button-blue
• button_blue
• button—blue

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

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

Проблема именования распространена при использовании фреймворков, например, Bootstrap. Используя привычное именование, верстальщик применяет стандартные компоненты фреймворка и не думает о том, чтобы привести именование к единому знаменателю.

Такой подход создаёт проблемы для разработчиков, которые будут поддерживать проект в будущем.

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

Действие/вид/родитель

Большинство хороших именований описывают один из этих критериев. Вне зависимости от методологии, вы описываете что-то из этого списка:

• Действие. Часто классы, указывающие на действие применяются к элементам, с которыми можно взаимодействовать. Для кнопки в форме это может быть класс .btn-send , или класс slider-next для области переключения слайда.

• Вид. Такие классы иногда называют «класс-модификатор». Их цель состоит в точечном изменении элемента. Это может быть визуальный вид, состояние или поведение. Такие классы не одиноки, они всегда являются надстройками над классами. Если основной класс .btn , то классами-модификаторами могут быть .btn-green , btn-disable , btn-big .

• Родитель. Элементы с такими классами явно описывают то, чьими потомками они являются. Если кнопка лежит в форме с классом order-form , то кнопка может иметь класс order-form__button

Изучайте вёрстку на Хекслете В рамках профессии «Верстальщик» мы познакомим вас с базовыми знаниями и принципами работы с HTML и CSS, расскажем о современных подходах и инструментах вёрстки, включая Flex, Grid, Sass, Bootstrap. Первые курсы в профессии можно пройти бесплатно. Регистрируйтесь и начинайте учиться!

Количество

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

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

О чём можно подумать, увидев класс .catalog-item ? Скорее этот элемент отвечает за конкретную карточку товара, а не за группу товаров. Добавление множественного числа сразу решит эту проблему:

Теперь нет неоднозначности — класс чётко говорит о том, что внутри не один элемент, а группа элементов.

БЭМ нейминг для HTML верстки сайтов. Полная инструкция

HTML, CSS

БЭМ неминг — это методология именования CSS классов. Расшифровывается как: Блок, Элемент, Модификатор. Придуман в Яндексе, чтобы решить проблему именования CSS классов в больших проектах.

Какую задачу решает БЭМ нейминг

Если давать имена CSS классам не задумываясь, то вскоре можно обнаружить в проекте такие имена как text-1 , text-2 и text-3 . Или например button-1 , button-2 и так далее. Чем больше растет проект и чем чаще в проекте встречаются похожие, но с небольшими различиями элементы, тем сложнее придумать им название так чтобы в названиях CSS классов можно было легко ориентироваться. БЭМ нейминг решает эту задачу.

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

Идея БЭМ нейминга состоит в том чтобы с помощью имен CSS классов определить независимые блоки, обозначить их элементы и определить возможные модификации. Рассмотрим подробнее.

Примечание

В этой статье описывается альтернативный синтаксис БЭМ нейминга, который называется Two Dashes. Этот стиль визуально более выразителен и легче воспринимается для чтения. Описание стиля Two Dashes в официальной документации.

Правила формирования имен классов в БЭМ нейминге

• Имена записываются латиницей в нижнем регистре.
• В имени классов используются полные слова, без сокращений.
• Для разделения слов в именах БЭМ-сущностей используется дефис ( — ).
• Имя элемента отделяется от имени блока двумя подчеркиваниями ( __ ).
• Модификаторы отделяются от имения блока или элемента двумя дефисами ( — ).

Пример именования по БЭМ неймингу

Основные понятия БЭМ нейминга

Блоки

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

Классическим вариантом блока является карточка товара, карточка со статьей, отдельно секция с товаром или со статьей, шапка, подвал, и другие секции или целостные элементы страницы.

Имя для блока описывается одним или несколькими словами. Несколько слов в имени блока разделяются дефисом — .

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

Неправильно:

Правильно:

Элементы

Элемент — это составная часть блока. Элемент является частью блока и находится внутри него.

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

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

Рассмотрим пример с элементами внутри карточки.

Неправильно:

Правильно:

Модификаторы

Модификатор — это дополнительный класс который добавляется к html тегу с блоком или элементом. Модификатор — модифицирует (изменяет) отображение блока на странице. Модификатор не может использоваться на теге отдельно от блока или элемента.

Имя класса модификатора содержит в себе имя блока или элемента для которого он создается, далее идет разделитель в виде двух дефисов — , и в конце имя модификатора.

Например у нас есть блок карточки товара card , и нужно сделать модификатор для карточки товара по распродаже, который будет менять ее фон. Имя такого модификатора будет следующее: card—sale

Давайте придумаем модификатор для элемента. Например в карточке товара есть его цена. Цена это элемент блока card и имеет класс card__price . Модификатором для такого элемента будет класс card__price—sale , в котором мы сначала повторяем имя элемента, далее после двойного дефиса указываем имя модификатора.

Неправильные имена модификаторов:

Правильные имена модификаторов:

Использование модификаторов

Модификатор всегда применяется к блоку или элементу. Нельзя использовать на теге только модификатор, без класса блока или элемента.

Неправильное использование модификаторов:

Правильное использование модификаторов:

Выводы и пример разметки с БЭМ неймингом

Пример карточки с товаром. Блок — это карточка, её элементы это изображение, название, цена и ссылка «подробнее».

Пример карточки с товаром с модификатором. Модификатор sale установлен для блока карточки и для элемента с ценой.

Пример карточки с вложенными элементами. Зачастую вам могут потребоваться дополнительные обертки внутри блока. Они также будут являться его элементами. Важно помнить все элементы внутри блока принадлежат непосредственном этому блоку. Даже если они вложены друг в друга. Не бывает элементов от элементов. Элементы бывают только от блока.

Вложенность в БЭМ нейминге

Блоки. Блоки могут быть вложены друг в друга.

Элементы. Элемент который принадлежит к блоку может находится только в нем. Элемент не может находится за пределами блока к которому он принадлежит.

Элементы одного блока могут находится друг в друге. Элементы можно вкладывать друг в друга, потому как всегда могут понадобиться дополнительные обертки и структурные элементы.

Важно помнить, все элементы внутри блока принадлежат непосредственном этому блоку. Даже если они вложены друг в друга. Не бывает элементов от элементов! Элементы бывают только от блока.

Неправильно:

Правильно:

Несмотря на то что price и read-more вложены в details , они все равно являются элементами от блока card .

Исключения

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

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

Пример кода с вынесением в блоки кнопок и загловков.

Пример блока карточки товара. Кнопка — отдельный блок.

Пример блока секции. Заголовок header — отдельный блок. Карточки card и пагинация pagination — также отдельные блоки.

БЭМ и проблема наименования. Ускоряем и стандартизируем нейминг в HTML и CSS

Так как предыдущая статья оказалась довольно объёмной, дадим пару комментариев к использованным ранее подходам и поговорим об наименовании селекторов.

БЭМ (Блок, Элемент, Модификатор) — компонентный подход к веб-разработке. В его основе лежит принцип разделения интерфейса на независимые блоки. Он позволяет легко и быстро разрабатывать интерфейсы любой сложности и повторно использовать существующий код, избегая «Copy-Paste».

Формально БЭМ содержит множество инструментов для создания “умных компонентов”, но часто под БЭМ’ом подразумевают только именования CSS классов, что немного неверно. Если вы раньше никогда не слышали про БЭМ, то подробнее можно ознакомиться по ссылке.

БЭМ или не БЭМ, вот в чем вопрос.

Так как использовать весь БЭМ в Angular приложении не нужно (в фреймворке уже есть аналогичные инструменты для создания и использования компонентов), то поговорим о наименовании селекторов.

Отметим, что современные JS фреймворки, позволяют отказаться от создания классов, благодаря инкапсуляции стилей и компонентному подходу, но это работает только для небольших проектов. Данная статья приводит решения для enterprise, в котором есть множество проектов, которые взаимодействуют между собой (CRM, Accounts, Call center, Billing, …)

Разберём основы БЭМа на примерах. Есть HTML структура:

• post

• post__header
• post__title
• post__subtitle
• post__body
• post__footer
• post__link

• post_v1

Мы создали компонент, состоящий из 1 блока с модификатором, который содержит 6 элементов.

Теперь создадим модификацию данного блока, добавив модификаторы блокам и элементам.

Как можно увидеть, у блока post и элемента post__body_v1 появились модификаторы.

• Правила одного блока не должны влиять на внутренний мир другого блока
• Элемент должен быть расположен внутри блока
• Нельзя создавать элементы элементов вида: post__header__title

Проблематика БЭМ’а

Есть четыре основные проблемы, которые возникают при первом использовании БЭМ’а.

1. Name hell (Отсутствие требований к названиям блоков, который вводит в замешательство)
2. Злоупотребление вложенностью элементов (Создание монолитных компонентов)
3. Сильная связность компонентов (Монолит или множественные модификаторы)
4. Проблема выбора имени (Выбор имён блокам, элементам, модификаторам)

Name hell

Первая проблема сводится к классической задаче вёрстки, которая звучит следующим образом:

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

Задача: Нужно сверстать два блока, какие имена должны быть у post и event.

На практике, обычно сначала был только блок с новостями, потом добавили блок с событиями. Но блок с новостями уже свёрстан, а верстать новый блок с событиями с помощью копирования, запрещается DRY.

Есть несколько способов решения поставленной задачи:

Просто скопировать всю вёрстку одного компонента (или сверстать один компонент и продублировать). Тогда мы получим первую проблему:

Формально, ничего страшного нет, просто разошлись названия сущностей при оформлении. Проблема появиться потом, когда различий между post и event станет много, будет случай, когда добавление новых стилей в один из компонентов, будет затрагивать и второй компонент, но который не должен быть изменён.

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

Что в результате позволит получить следующее:

Злоупотребление вложенностью элементов

Данная проблема проявляется при создании очень больших компонентов:

И все вроде хорошо, но если вдруг потребуется использовать только часть данного блока, например:

То тогда будет необходимо изменить основной блок и разбить его на несколько маленьких.

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

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

Созданию новых БЭМ компонентов

Есть ряд рекомендаций к созданию маленьких и атомарных компонентов, которых придерживается автор, но которых нет в БЭМ’е:

1. Используйте элементы БЭМ’а тогда и только тогда, когда элемент не может существовать без блока в принципе.

Например, мы создаём кнопку с иконкой. И стили иконки на 99% зависят от блока, и шанс, что мы захотим использовать стили расположения иконки очень малы, и тут применение БЭМ’а оправдано:

Однако, рассмотрим пример выше, и перепишем блок с новостями:

Следующий вариант тоже будет хорошим решением:

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

Представим, что появились новые правки блока и теперь заголовок состоит из нескольких блоков — иконки и текста. Скорее всего, если вы использовали второй подход, то получится что-то вроде:

Теперь добавим иконку в описание, от которой должен быть фиксированный отступ:

И конечно, украсим вишенкой на торте, изменив размер иконки в заголовке:

Если мы откажемся от элементов, то получим:

Что тоже является БЭМ’ом, где каждый HTML элемент представляет блок.

Автор не призывает к отказу от элементов, а всего лишь хочет подчеркнуть, что чрезмерное употребление элементов ухудшает читаемость кода, лишая его изящности.

Сильная связность компонентов

Ещё один нюанс связанный с БЭМ’ом — темизация и изменение блоков.

Представим, что мы ведём проект несколько лет, и наш блок с новостями немного изменился. Добавились несколько различных видов, которые описываются так:

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

Однако, если вы будете использовать другие блоки, то такой подход уже не сработает.

Где помимо того, что был добавлен модификатор к post-box, также был добавлен модификатор к smart-title, так как модификатор может изменять только тот блок, к которому он применён и не может изменять блоки, которые вложены в него.

Решением данной проблемы является создание темизированных компонентов.

Заметим, что данная техника противоречит одному из правил БЭМ’а, что модификатор не может влиять на другие вложенные блоки. Если необходимо строгое соблюдение БЭМ’а, то вы не должны использовать темизацию.

Темизация — модификатор родительского блока, может переопределять текущие стили блока.

Разберём на примере. Необходимо создать две карточки, которые будут иметь 2 темы — светлую и тёмную. В светлой теме белый фон чёрный текст, в тёмной теме чёрный фон, белый текст.

Создадим разметку в строгом варианте БЭМ’а:

И соответствующие темы:

Так как у нас есть вложенные блоки в post-box, то для этих блоков, тоже нужны свои темы:

Полный вариант разметки:

Применим подход темизации, убрав темы для post-form на уровень родительского блока:

Тогда соответственно разметка станет:

Как можно увидеть, теперь оформление post-form зависит от модификатора post-box.

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

Для проверки можете создать блок, с двумя вложенными в друг друга блока ( A > B > C) и для каждого из блоков задайте по несколько состояний, например блок А имеет 2 состояния, блок B имеет 3 состояния, а состояние блока С определяется по выбранному состоянию блока А и блока B, т.е. как минимум 6 состояний (A1 + B1, A1 + B2, A1 + B3, A2 + B1, A2 + B2, A2 + B3), если сам C не имеет своих собственных.

Просто представьте форму регистрации с 40 полями, где некоторые поля связаны между собой (дата выдачи паспорта и дата рождения, где дата выдачи зависит от даты рождения, так как в РФ люди должны менять паспорта в определённые года), где поле может быть не заполненным, валидным и не валидным, плюс есть автозаполнение и т.д. Если вы будете писать действительно гибкие UI интерфейсы, а также полностью придерживаться БЭМ’а это увеличит код в несколько раз. Темизация позволяет снизить нагрузку на количество и контроль классов.

Для примера приведём стили для блоков без/с использованием темизации:

Как можно увидеть из примера, мы получили 2 монолитных компонента, в которых есть 2 темы.

Перепишем пример, используя темизацию:

Мы избавились от дополнительного класса в разметке, но лучше всё равно не стало.

Применим подход маленьких атомарных блоков. Разметка примет вид:

И соответствующие стили:

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

Проблематика имен

Используя разные методологии для задания имён, такие как БЭМ, всё равно остаётся один не решенный вопрос — какие имена выбирать.

Есть 2 критерия, которые позволяют определить, что вы неверно выбираете названия селекторам:

1. Если после завершения вёрстки и в процессе её интеграции или внесения новых правок приходится изменять более 25% используемых селекторов.
2. Если по окончанию работы есть желание отрефакторить проект.

Возьмём для примера, наш любимый блок новостей. Представим, что в вёрстке он используется в 3 местах: