В чем преимущество при использовании CSS-препроцессоров включения во вложенное имя стиля имени его родителя?

Question

[Станислав]

Объясню. Например, у нас есть footer. И нам нужно описать его стили. Есть условно два варианта, с которыми я встречался при использовании авторами Sass/Less препроцессоров:

1. Без включения имен родителей в имена потомков:

.footer_bottom
  display: flex

  .autor
    text-align: left

  .policy
    text-align: right

  .company
    text-align: right

Что в итоге дает нам такой код:

.footer_bottom {
  display: flex;
}
.footer_bottom .autor {
  text-align: left;
}
.footer_bottom .policy {
  text-align: right;
}
.footer_bottom .company {
  text-align: right;
}

2. С включением имен родителей в имена потомков:

.footer_bottom
  display: flex

  &--autor
    text-align: left

  &--policy
    text-align: right

  &--company
    text-align: right

И это в итоге дает нам такой код:

.footer_bottom {
  display: flex;
}
.footer_bottom--autor {
  text-align: left;
}
.footer_bottom--policy {
  text-align: right;
}
.footer_bottom--company {
  text-align: right;
}

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


При этом структура кода для такого компонента страницы выглядит примерно вот так:


Где корневой файл импортирует в себя все эти субкомпоненты:


Заметьте, что импорт происходит на уровне родительского элемента, в него и больше никуда, то есть, на мой взгляд, ничто не обязывает нас использовать в субкомпонентах именно такой код (см. на красную стрелку), который включал бы имя родителя в имена потомков:



Так вот, вопрос: есть какой-то практический смысл использования имен родителей в именах потомков при написании CSS? Кроме того, что кому-то, возможно, легче читать после этого готовый css. На мой взгляд, от этого становится только сложнее писать html под такой CSS и читать потом готовый код в браузере.

Answer 1

[dom1n1k]

Почитайте про БЭМ. Причем желательно не просто краткое объяснение методологии, а с историческими выкладками, откуда и почему он взялся. Ещё очень полезно послушать старые лекции Виталия Харисова на эту тему.

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

Comments

[Станислав]

Я в курсе, что такое БЭМ, но достаточно поверхностно. Ну и конечно же знаю, что именно в этом проекте он и используется. Тем не менее, вы хотите сказать, что этот подход подразумевает именно такое именование, как я привел в своем вопросе?

[dom1n1k]

Включение имени родителя - да.
Импорты - не обязательно.

[Станислав]

dom1n1k, спасибо! А не дадите ссылки на именно эту часть описания БЭМ где-либо?

[dom1n1k]

https://events.yandex.ru/lib/talks/95/

[dom1n1k]

Только нужно учитывать, что там ещё "старый" БЭМ, с чуть другим синтаксисом. В частности, там ещё есть префиксы b-, а модификаторы отделяются одним подчеркиванием (сейчас уже де-факто приняты два дефиса). Но основная суть от этого не меняется.

[Владимир Проскурин]

а модификаторы отделяются одним подчеркиванием (сейчас уже де-факто приняты два дефиса).

Может я отстал от жизни, но у них в доках написано одно подчеркивание

[dom1n1k]

Vlad_IT, потому я и написал де-факто, а не де-юре :) Когда БЭМ распространился на Запад, кто-то из тамошних разработчиков (не помню имя) предложил модификацию с двумя дефисами. Решение оказалось удачным, многим понравилось и его стало использовать большинство (по моим субъективным оценкам).

[Владимир Проскурин]

dom1n1k, это интересно, на getbem.com и большинстве англоязычных сайтов правда описывают через --. Спасибо за наводку, надо углубиться.

[Сергей delphinpro]

dom1n1k,

Решение оказалось удачным, многим понравилось и его стало использовать большинство (по моим субъективным оценкам).

Спорное заявление (обе части — и про «удачным», и про «большинство»). Холиварное, я бы сказал.
А все бэм тулзы по дефолту работают с подчеркиваниями.

[Станислав]

Сергей, Vlad_IT, dom1n1k, господа, огромное спасибо за ответы и обсуждение, но теперь у меня еще один вопрос - как определиться, какие именно подчеркивания и тому подобное более "выгодны" в той или иной ситуации? Какие инструменты могут их обрабатывать, что более понятно, стандартизировано и так далее.

[Сергей delphinpro]

Станислав, Большинство известных мне инструментов по дефолту используют нотацию .block-name__elem-name_mod-name_mod-value но имеют возможность настройки. Некоторые используют буржуйскую нотацию. Мне лично два дефиса для модификаторов тоже нравились, но в силу поддержки инструментарием ушел от них в классику.
Так что по большому счёту — дело вкуса.

PS Например, Emmet разворачивает строку .blk_small[tab] в <div class="blk blk_small"></div>

[Станислав]

Сергей, хм, попробовал сейчас в WebStorm - он развернул ее в <div className="blk_small"></div> все-таки.

[Сергей delphinpro]

Станислав, Может галочка не стоит в настройках?

[Станислав]

Сергей, и правда. Я как-то не подумал, что Emmet по умолчанию не с его синтаксисом работает.

Answer 2

[Anton Filippov]

такое вложение даёт некоторую "защиту" от того, что класс с подобным именем в другом родительском блоке переопределит такие стили, но это плохой код, так как двойные-тройные-энные селекторы замедляют рендер css, лучше использовать одинарные с БЭМ

Comments

[Станислав]

Да, вам тоже спасибо! Про рендер я уже узнал из видео, которое дали в комментариях к другому ответу, действительно ценная особенность, в больших проектах может серьезно повлиять на скорость. Про "защиту" - ну в целом это и так было понятно, правда у меня оставался вопрос, зачем эта лишняя защита, если мы будем использовать не селекторы, а какие-то классы, типа autor, company и так далее. Но если смотреть глубже и принять во внимание БЭМ, то становится понятно, что у компонента могут быть вложенные компоненты, где используются такие же классы внутри, и в итоге переопределение может стать реальной проблемой.

[Anton Filippov]

Станислав, часто на проектах, которые писали неопытные юзеры можно встретить неспицифично названные классы, например .popup, потом пишешь такой класс, а он весь изломанный, оказалось, кто-то его в другом месте неспецифично использовал, и чтобы не переписывать тот код(переписывание может поломать всё в других местах), проще изолировать свой .popup указав в селекторе родителя, например, .profile > .popup, так и появляются вложенные селекторы :)
Если изначально всё писать основываясь на методологии (БЭМ, SMACSS, etc), то таких проблем не возникнет

[Станислав]

flppv, это все понятно, меня вот и интересовал момент, почему не указывать явно таким или иным образом родителя, ограничивая применение такого вложенного класса конкретным местом. И если просто вложенность да, может в итоге принести проблем, то ">" - это по идее рабочий вариант, но не всегда удобный - замучаешься описывать так, да и не всегда можно/удобно указать непосредственного родителя через ">".