Не вижу ничего плохого, когда надо спрятать элемент или привязать определенную ширину, например для сетки. (g-hidden, g-w200) Но можно увлечься и это начнет выглядеть как инлайн стили (marginLeft50)

@varya Такие модификаторы называются миксами ;)

@tadatuta, и все же практически везде в коде .block_disabled или .block_hidden. Почему это модифиаторы блока, а не глобальные миксы?

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

@dab Интуитивно понятно, но всё равно это какие-то общие слова. Примеры нужны: когда это плохо? Что может аффектить?

@varya С .block_disabled все просто: разные блоки по-разному реагируют на состояние disabled.

С невидимостью, предположу, что причина в API i-bem.js: у блока есть методы про модификаторы, но нет удобного способа работать с миксами: addMix(), toggleMix() и т.п. А методов таких нет, потому что они автоматически подразумевают необходимость одного блока знать о другом. И если конкретно для .hidden это более-менее безобидно, то почти для любых других случаев такое API станет источником плохой архитектуры.

Знаю место (alpari.ru / alpari.org, работал там), где в верстке бэм, а js - на основе бэкбона, но расширенного методами из i-bem.js, типа Backbone.View#_elem для поиска элементов блока.

Так вот, мы сделали возможность приписывать/убирать класс hidden для управления видимостью блока/элемента. Это оказалось настолько востребованным, что такую возможность просто получили в конце концов все вьюшки. Проблем не было с этим никаких.

Больше никаких миксов нам (в js) не понадобилось по большому счету. Думаю, можно считать это таким же особым случаем, как, например, required в правилах валидации.

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

@apsavin Отдельные блоки на одной DOM-ноде — это же и есть миксы ;)

@tadatuta ох уж эта терминология, что ни спор - все о ней)

Короче, итог такой: "глобальный модификатор" возможен только если это не модификатор, а микс двух блоков. Если глобальный модификатор невозможно представить абстрактным блоком, лучше его не делать.

@varya как это - "представить глобальный модификатор абстрактным блоком"? Так точно не стоит отвечать на "глупые вопросы")

"Представить" — в воображении.

А это и не ответ на глупые вопросы, это сбор материала :-)

hidden можно представить абстрактным блоком?

Нет, по причинам, которые Володя описал выше.

А тем не менее, это очень удобно и, как написал тот же Володя, безобидно. А api отсутствует, чтобы не соблазнять слабых душою)

Чтобы "экономить", есть миксы в препроцессорах. С ними сделать новый block_hidden ничего не стоит. Вообще все относительно, иногда и hidden можно. Я раскрою эту мысль при подготовке окончательного ответа.

попробуй объяснить верстальщику, почему в сжатом css файле должен быть такой код:

.block_hidden,
/* еще 100500 блоков */
{
   display: none;
}

это про миксы в препроцессорах

Про "все относительно" и гибкость методологии - согласен полностью, надо раскрыть.

На самом деле, конечно, есть случаи, когда сразу становится понятно, чем плох "глобальный модификатор" hidden. Например, у тебя два блока на одной дом-ноде, которая должна быть видима, только если оба блока не в состоянии hidden. a a_hidden b b_hidden - узел скрыт a b b_hidden - блок a поменял состояние, но нода все равно скрыта и a hidden b - узел скрыт a b - блок а поменял состояние, блок b - нет, но нода уже не скрыта.

Спасибо!

Прежде всего, нужно понимать разницу между глобальными модификаторами и миксами. Смешать несколько блоков на одной ноде — можно, но пользоваться этим надо аккуратно. С глобальными модификаторами (которые меняют какое-либо одно свойство или набор свойств, но блоками не являются) всё сложнее:

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

.block { /* ... */ }
.block_mod { /* ... */ }

При этом модификатор переопределит стили блока, т.к. при одинаковой специфичности идёт следом за ним. Стили всего блока независимо от вида сборки загружаются вместе и порядок правил сохраняется.

Глобальные модификаторы, если их загрузить вначале, могут быть "перебиты" правилами самих блоков, например:

.hidden { display: none }
/* ... */
.block { display: block }

<div class="block hidden">всё равно видно</div>

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

Второй вариант — загружать глобальные модификаторы в конце общей CSS-сборки. Но тогда не получится использовать lazy loading стилей компонентов — они будут загружаться после глобальных модификаторов и возникнет описанная выше проблема «гонки вооружений».

Следующая проблема — сочетание нескольких глобальных модификаторов на одном блоке. Здесь вы полностью теряете контроль — порядок включения глобальных модификаторов произволен, и если они конфликтуют по каким-то правилам, «разрулить» противоречия можно только на уровне блока, и ещё надо будет увеличить вес селектора или написать !important.

Вообще, в зависимости от реализации блока один и тот же модификатор может иметь «нюансы». Классический .hidden можно реализовать через display: none, visibility: hidden, position: absolute; left: -9999px и ещё несколько вариантов. Часто бывает нужно изменить реализацию блока, не занимаясь поиском всех 100500 мест, где этот блок может сочетаться с глобальным модификатором (в общем случае, этот поиск может представлять проблему, потому что эта связь вряд ли где-то явно описана). В случае локальных (зависящих от блока) модификаторов инкапсуляция нас спасает.

К плюсам глобальных модификаторов можно отнести «уменьшение объёма кода». Измеренная в реальных цифрах, экономия обычно оказывается не слишком значительной :(

@ingdir в БЭМ нет понятия глобальный модификатор, то, что ты описываетесь — это микс блоков. Проблемы специфичности решаются зависимостями.

@vithar конечно нету, но весь тред — про то, что многие новички этого не понимают и не понимают, почему это плохо. об этом и идёт дискуссия — как объяснить наилучшим образом, почему именно так. твой ответ рассчитан на профи, знакомых с предметом глубоко, а мне уже десятки раз приходилось это объяснять людям, для которых бутстрап — вершина технологий, а про css specificity они вообще не знают.