V
Кто будет юзать методологию которая запрещает псевдоклассы
Size: a a a
2019 December 12
AP
Бэм не только о именовании. + или ~ или > тоже не имя класса, но они определяют соседей или создают зависимости или могут изменить что-то вне блока, что будет нарушением методологии
модификатор связывает в равной степени, как и псевдокласс
AP
но добавляет накладные расходы в виде работы джса
АН
БЭМ ничего не запрещает. Она определяет правила и последствия их нарушений. Как и любая другая методология или паттерн. Например SOLID или любой другой подход к разработке
AP
минус, ты не можешь повесить _disabled, если указан только псевдокласс
AP
но ты можешь указать оба
V
минус, ты не можешь повесить _disabled, если указан только псевдокласс
Модификаторы через -- отделяются
AP
Модификаторы через -- отделяются
не только
V
модификатор связывает в равной степени, как и псевдокласс
Но писать под Ховер отдельный модификатор и в жсе этим оперировать - это полный бред
V
не только
Можно пример?
AP
Можно пример?
зайди в доку по бэму
EM
Можно пример?
в доке БЭМ-а несколько вариантов именования.
EM
еще и свой вроде можно придумать, если их не нравится
AP
Можно пример?
.block__elem_mod_value это официальный вариант
AP
-- это его интернациональная вариация
V
.block__elem_mod_value это официальный вариант
Показалось что у тебя 2 андерскора
V
.block__elem_mod_value это официальный вариант
Тем не менее, на практике никогда не видел его
AP
Тем не менее, на практике никогда не видел его
а в яндексе работал?
V
а в яндексе работал?
Нет
AP
тогда неудивительно