Правила именования в БЭМ

[furtivite]

В вёрстке мы пришли к решению использовать БЭМ как правила в инфраструктуре и оформлении кода.

Необходимо прийти к решению о стилях оформления кода:

• Вариант принятый в Яндексе
• Альтернативный вариант Two Dashes

и другие.

Присоединитесь, пожалуйста, в обсуждение, чтобы мы пришли к единому мнению. Спасибо.

[lenaryan]

Для меня удобнее вариант с двумя дефисами - он визуально более понятный. Всё-таки дефис от нижнего подчёркивания отличить проще, чем два нижних подчёркивания от одного.

[monochromer]

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

Если попробовать записать БЭМ-компоненты в XML-стиле, то мы можем получить что-то такое:

<Theme color="dark" font="code">
</Theme>

Здесь должна быть сразу видна необходимость в нотации "ключ-значение". Также видно, что у атрибута может быть только одно значение, ведь вы же не будете писать так: <Theme color="dark" color="light">, так как не понятно, что применится. Но вот с "булевской" нотацией все уже не так очевидно: <Theme dark light>, <Theme color-light color-dark> или может так:

<Theme dark>
  <Theme light>
  </Theme>
</Theme>

Поэтому в Яндексе и отказались от нее.

Ещё пример (не имеет отношения к стилизации, но смысл должен быть понятен): как бы задавали атрибуты loading и его значения в разных нотациях для тега img:

<img loading="lazy">
<img loading="eager">

или

<img loading-lazy>
<img loading-eager>

Что проще понять?

[pepelsbey]

Важно относится к БЭМ, как к не просто методологии именования CSS-классов

Мне кажется, что тут не «важно», а «можно» ;) Если мы говорим про модификаторы простых блоков и элементов, то в моём опыте всегда хватает простых модификаторов, ключ-значение не нужно. А если не нужно, то зачем усложнять код?

Но тут снова нужно вернуться к тому, что я сказал выше:

К сожалению, у нас скорее спор привычек

[furtivite]

@pepelsbey можешь, на всякий случай (кажется я запутался, потому что у редко встречаю неяндексовую нотацию), как ты предлагаешь записывать:

• блок (у Яндекса так: .block)
• блок с модификатором (у Яндекса так: .block_modifier)
• элемент (у Яндекса так: .block__element)
• элемент с модификатором (у Яндекса так: .block__element_modifier)

[pepelsbey]

У меня созрел аргумент :) Представьте вот такой пример:

<tag lazy></tag>

Как и в XML-примерах выше, не очень понятно, что здесь происходит. Мы не знаем, что за тег, что это за лейзи. Но как только мы видим такое:

<input required>
<main hidden>

Вопросов уже нет: мы понимаем, что это значит по тегу. То же самое с блоками: если блок достаточно атомарен и понятен как input, img или main, то бинарные модификаторы прекрасно работают. Он либо есть, либо его нет — а то, что он делает, перечислено в ряду немногих модификаторов.

[furtivite]

если блок достаточно атомарен и понятен как input, img или main, то бинарные модификаторы прекрасно работают. Он либо есть, либо его нет — а то, что он делает, перечислено в ряду немногих модификаторов.

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

[igsekor]

Кажется, что европейская нотация легче воспринимается. Согласен с @pepelsbey. Кажется, что перегружать название классов и переменных не стоит. Да и зачем? Всё же и так понятно.

А зачем разделять понятия тема для шрифта и тема для цветов? Кажется, что слово theme в theme_color_light, theme_font_code в названии двух классов лишнее. Разве нет? Имена классов theme--light и font--code не понятнее ли (если font употребляется для общих настроек размеров или цвета, например)? У меня готового решения нет, но кажется, что много слов в некоторых частях нашего CSS является избыточным.

В то же время, пользоваться возможностями нотации Яндекса в тех случаях, когда это избыточно, но пользоваться приятно — это вкусовщина? Так же, как и желание использовать международную нотацию.

Плюсы международной нотации в том, что её используют за пределами Яндекса. Разве нет? Может нам важно делать так, чтобы ассоциироваться с сообществом даже в коде, а не с Яндексом, нотацию которого используют в основном в русскоязычном сообществе, да и то далеко не везде?

[igsekor]

Вот список всех классов не данный момент в нотации Яндекса из PR:

.base-list

.base
.base__body

.footer-nav-list
.footer-nav-list__item
.footer-nav-list__link

.footer
.footer__toggle
.footer__list

.link

.theme-toggle
.theme-toggle__input
.theme-toggle__desc
.theme-toggle__control
.theme-toggle__thumb
.theme-toggle__icon
.theme-toggle__icon_light
.theme-toggle__icon_dark

.theme
.theme_font_text
.theme_font_code
.theme_color_light
.theme_color_dark

.visually-hidden

Может каждый посмотрит на этот список и предложит свой вариант именования или согласится с тем, который уже есть?

[pepelsbey]

Предлагаю использовать следующую нотацию. См. дискуссию выше.

.block
.block--modifier
.block__element
.block__element--modifier

@furtivite вот так ^

[monochromer]

Как насчёт использования data-атрибутов в качестве модификаторов?

:root[data-dark-theme] {}

.avatar[data-size="small"] {}
.avatar[data-size="medium"] {}
.avatar[data-shape="round"] {}
.avatar[data-shape="rect"] {}

.dropdown[data-state="open"] {}

[monochromer]

Зато они как раз выравнивают специфичность, когда используются рядом с псевдоклассами типа :checked, :hover, :focus

[furtivite]

Зато они как раз выравнивают специфичность, когда используются рядом с псевдоклассами типа :checked, :hover, :focus

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

[monochromer]

Это .block .block__element противоречит методологии

[furtivite]

Это .block .block__element противоречит методологии

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

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

[monochromer]

Там написано, что можно с помощью модификаторов на "родителе" менять "детей"