Миксины .make-row() и прочие я использую, только чтобы сгенерировать альтернативную сетку. Например, параллельно стандартной 12-колоночной нужно использовать 5-колоночную с увеличенным гуттером.
В остальных случаях пишу классы «row», «col-*» и прочие бутстраповские сразу в вёрстке, мне так удобнее. Потому что нужно сбалансировать сложность в HTML разметке и сложность в CSS коде. Рассмотрим крайности.
1) Если каждому блоку в разметке писать уникальный класс, а потом в CSS миксинами накидывать rows, cols и прочие свойства из фреймворка, то в HTML сложность понижается, ведь у нас на блоке всего один класс, зато в CSS сложность резко вырастает: чтобы исправить баг, верстальщику придется бегать по миксинам, анализировать зависимости, чтобы не поломалось в другом месте. При этом растет размер CSS файлов: стили для модульной сетки повторяются в разных селекторах (дублирование кода), а верстальщику для каждого нового блока приходится придумывать новое уникальное имя класса. Два внешне похожих блока имеют 90% одинакового кода и этот код повторяется два раза. Такая ситуация называется «css bloating» (css наводнение).
2) Противоположная ситуация называется «html bloating»: когда в стилях создают простейшие классы типа .colorred, .fontsize14, fontweightbold, .padding20 и т.д., а в разметку на каждый тег кидают по 10-20 таких классов, пока блок не будет выглядеть как надо. В этом случае в CSS очень низкая сложность, нет никаких конфликтов, размер файла невелик. Но если дизайн хоть чуть-чуть поменяется, верстальщику придется переписывать классы на каждом тэге. Вся сложность из стилей ушла в разметку.
В первом случае (css bloating) у нас 100% отделение внешного вида от разметки. Это вроде бы хорошо, блоки выглядят независимыми, но достигается это высокой ценой: большой риск сломать что-нибудь, внося правки в миксины; повторения в коде и в результате обязательный gzip стилей. В чистом виде можно использовать, когда нет доступа к html-разметке: один и тот же виджет используется на разных сайтах и должен выглядеть по-разному, менять ему html опасно.
Во втором случае (html bloating) внешний вид смешан с разметкой (это лишь чуть-чуть лучше, чем инлайн styles) и даже самое маленькое изменение в дизайне влечет кучу тупой работы по перестановке классов в html, но зато в css конфликтовать нечему. Пожалуй, в чистом виде может встречаться в веб-приложениях, когда верстка генерируется через js-шаблоны (тупая работа автоматизирована). Отлавливать css баги в динамичной верстке приложений очень сложно, поэтому есть смысл увеличить прочность стилей, перенеся сложность в разметку.
Оптимальный вариант — распределить сложность примерно поровну между стилями и разметкой — «multiple classes». На каждый блок вешать 3-5 классов, которые отвечают за модульную сетку, геометрию, скин этого блока. Соответствующие классы можно переиспользовать в других блоках. Классы Bootstrap'а хорошо справляются с модульной сеткой и частично с геометрией, а скины и геометрию собственных компонентов верстальщик дописывает сам.
В БЭМ баланс сложности смещен в сторону css bloating: блоки должны быть независимыми, их нельзя смешивать, можно лишь вкладывать друг в друга, а значит увеличено количество повторений css кода.
В OOCSS баланс смещен в сторону html bloating: пишут больше мелких, но переиспользуемых конструкций, имена классов придумывать сложнее, т.к. они должны быть достаточно абстрактны, но всё ещё показывать, что этот класс делает.
Простой
