Укрощение Cascade с помощью БЭМ и современных селекторов CSS
Как, иногда кажется что все технологии в мире фронтенд-разработки, в том числе написание CSS в формате БЭМ (writing CSS in a BEM format) могут вызывать противоречивые чувства. Но это — по крайней мере, в моем Twitter пузыре — БЭМ одна из самых популярных методологий CSS.
Лично я думаю, что БЭМ очень хорошая методология, и что все непременно должны ее использовать. Но я также признаю причины, по которым это иногда не возможно.
Независимо от вашего мнения о БЭМ, он предлагает несколько преимуществ, самым большим из которых является то, что он помогает избежать конфликтов специфичности в CSS Cascade. Это потому, что при правильном использовании любые селекторы, написанные в формате БЭМ, должны иметь одинаковую оценку специфичности (0,1,0). Я разработал CSS для множества крупных веб-сайтов на протяжении многих лет (это были правительственные проекты, университетские и банковские), и именно в этих более крупных проектах я обнаружил, что БЭМ действительно очень полезен. Написание CSS намного веселее, когда вы уверены, что стили, которые вы пишете или редактируете, не влияют на какую-либо другую часть сайта.
На самом деле есть исключения, когда добавление специфичности считается вполне приемлемым. Например: псевдоклассы :hover и :focus . Они имеют показатель специфичности 0,2,0. Другой – псевдоэлементы, например ::before и ::after , которые имеют показатель специфичности 0, 1, 1. Однако в остальной части этой статьи давайте предположим, что нам не нужна какая-либо другая специфичность. 🤓
Но на самом деле я написал эту статью не для того, чтобы продавать вам БЭМ. Вместо этого я хочу поговорить о том, как мы можем использовать его вместе с современными селекторами CSS — например, :is(), :has(), :where() и т. д. — чтобы получить еще больший контроль над Cascade.
Что такого в современных селекторах CSS?
Спецификация CSS Selectors Level 4 (CSS Selectors Level 4 spec) дает нам несколько новых мощных способов выбора элементов. Некоторые из моих любимых функций включают :is(), :where() и :not() каждая из которых поддерживается всеми современными браузерами и в настоящее время безопасна для использования практически в любом проекте.
:is() и :where() в основном одно и то же, за исключением того, как они влияют на специфичность. В частности, :where() всегда имеет показатель специфичности 0,0,0. Да, даже :where(button#widget.some-class) не имеет никакой специфичности. Между тем, специфичность :is() — это элемент в списке аргументов с наивысшей специфичностью. Итак, у нас уже есть различие между двумя современными селекторами, с которым мы можем работать.
Невероятно мощный реляционный псевдокласс :has() также быстро получает поддержку браузеров (и, по моему скромному мнению, это самая большая новая функция CSS со времен Grid). Однако на момент написания статьи поддержка :has() в браузерах еще недостаточно хороша для использования в рабочей среде.
Рассмотрим пример использования одного из этих псевдоклассов в БЭМ и…
/* ❌ specificity score: 0,2,0 */
.something:not(.something--special) {
/* styles for all somethings, except for the special somethings */
}
Упс! Видите этот показатель специфичности? Помните, что в БЭМ мы в идеале хотим, чтобы все наши селекторы имели показатель специфичности 0,1,0. Почему 0,2,0 плохо? Рассмотрим аналогичный пример, более подробно:
.something:not(a) {
color: red;
}
.something--special {
color: blue;
}
Несмотря на то, что второй селектор является последним в исходном порядке, побеждает более высокая специфичность первого селектора (0,1,1), и цвет .something–special элементов будет установлен на красный. Так как, если ваш БЭМ написан правильно и к выбранному элементу в HTML применены как базовый класс .something, так и специальный класс-модификатор .something--special.
При неосторожном использовании эти псевдоклассы могут неожиданным образом повлиять на Cascade. И именно такие несоответствия могут создать головную боль в будущем, особенно при работе с большими и сложными кодовыми базами.
Ну что теперь?
Помните, что я говорил о :where() и о том, что его специфичность равна нулю? Мы можем использовать это в своих интересах:
/* ✅ specificity score: 0,1,0 */
.something:where(:not(.something--special)) {
/* etc. */
}
Первая часть этого селектора (.something) получает свой обычный показатель специфичности 0,1,0. Но :where() — и все, что внутри него — имеет специфичность 0, что не увеличивает специфичность селектора.
:where() позволяет нам вложенность
Люди, которые не так сильно заботятся о специфичности, как и я (а таких людей, если честно, наверное, много), неплохо справлялись с вложенностью. С некоторыми беззаботными движениями клавиатуры мы можем получить такой CSS (обратите внимание, что для краткости я использую Sass):
.card { ... }
.card--featured {
/* etc. */
.card__title { ... }
.card__title { ... }
}
.card__title { ... }
.card__img { ... }
В этом примере у нас есть компонент .card. Когда это «популярная» карта (используется класс .card–featured), заголовок и изображение карты должны быть оформлены по-другому. Но, как мы теперь знаем, приведенный выше код приводит к показателю специфичности, несовместимому с остальной частью нашей системы.
Заядлый знаток специфичности мог бы сделать следующее:
.card { ... }
.card--featured { ... }
.card__title { ... }
.card__title--featured { ... }
.card__img { ... }
.card__img--featured { ... }
Это не так уж и плохо, верно? Честно говоря, это красивый CSS.
Однако в HTML есть обратная сторона. Опытные авторы БЭМ, вероятно, до боли знакомы с неуклюжей логикой шаблонов, необходимой для условного применения классов модификаторов к нескольким элементам. В этом примере шаблон HTML должен условно добавить класс модификатора –featured к трем элементам (.card, .card__title и .card__img), хотя, возможно, даже больше в реальном примере.
Селектор :where() может помочь нам написать гораздо меньше шаблонной логики и меньше классов БЭМ для загрузки, не повышая уровень специфичности.
.card { ... }
.card--featured { ... }
.card__title { ... }
:where(.card--featured) .card__title { ... }
.card__img { ... }
:where(.card--featured) .card__img { ... }
Вот то же самое, но в Sass (обратите внимание на амперсанды в конце):
.card { ... }
.card--featured { ... }
.card__title {
/* etc. */
:where(.card--featured) & { ... }
}
.card__img {
/* etc. */
:where(.card--featured) & { ... }
}
Следует ли вам выбрать этот подход вместо применения классов модификаторов к различным дочерним элементам, зависит от личных предпочтений. Но, по крайней мере с :where() сейчас у нас есть выбор!
Как насчет не-БЭМ HTML?
Мы не живем в идеальном мире. Иногда вам нужно иметь дело с HTML, который находится вне вашего контроля. Например, сторонний скрипт, который внедряет HTML, который вам нужно стилизовать. Эта разметка часто не написана с именами классов БЭМ. В некоторых случаях эти стили используют не классы, а идентификаторы!
И снова :where() поддерживает нас. Это решение немного хакерское, так как нам нужно сослаться на класс элемента где-то выше по дереву DOM, о существовании которого мы знаем.
/* ❌ specificity score: 1,0,0 */
#widget {
/* etc. */
}
/* ✅ specificity score: 0,1,0 */
.page-wrapper :where(#widget) {
/* etc. */
}
Однако ссылка на родительский элемент кажется немного рискованной и ограничительной. Что, если этот родительский класс изменится или по какой-то причине его не будет? Лучшим (но, возможно, столь же хакерским) решением было бы использовать :is() вместо этого. Помните, что специфичность :is() равна самому специфичному селектору в его списке селекторов.
Таким образом, вместо ссылки на класс, о существовании которого мы знаем (или надеемся!) с помощью :where(), как в приведенном выше примере, мы могли бы сослаться на созданный класс и тег <body> .
/* ✅ specificity score: 0,1,0 */
:is(.dummy-class, body) :where(#widget) {
/* etc. */
}
Вездесущее body поможет нам выбрать наш элемент #widget, а наличие класса .dummy-class внутри того же :is() дает селектору body ту же оценку специфичности, что и класс (0,1,0)… а использование :where() гарантирует, что селектор не станет более специфичным.
Заключение
В статье я постарался описать то как мы можем использовать современные функции управления специфичностью псевдоклассов :is() и :where() наряду с предотвращением конфликтов специфичности, которые мы получаем при написании CSS в формате BEM. И в не столь отдаленном будущем, когда :has() получит поддержку Firefox (в настоящее время она поддерживается с пометкой на момент написания статьи), мы, вероятно, захотим соединить ее с :where(), чтобы отменить ее специфичность.
Независимо от того, идете ли вы ва-банк в использование БЭМ-именовании или нет, я надеюсь, что мы можем согласиться с тем, что постоянство в специфичности селекторов — это хорошо!