Здравствуйте. Начал познавать методологию БЭМ, и буквально сразу возник вопрос, касаемо места классов сетки (не использую полный стэк, только методология). Что из этого более верный путь: примешивать класс размера блока к самому блоку в верстке:
<div class="block grid__col_3">
или примешивать миксином непосредственно в css (пример на less):
.block {
color: red;
.grid__col_3;
}
С одной стороны - блок должен быть Абсолютно Независимым, то есть его отображение не должно зависеть от того, какой класс сетки мы ему примешали - он должен выглядеть так, как описан в стиле - аргумент ЗА миксин в css. С другой - блок становится более транспортабельным, мы его можем таскать куда и как угодно, и задавать размер непосредственно в верстке - благодаря миксину в html классе блока мы можем растянуть его как угодно без вмешательства в стили - аргумент ЗА миксин в html классе.
Чутье подсказывает третий вариант: создание модификатора элемента блока. "Семантичненько", и все такое. Но тогда такой модификатор нужно создать для каждого элемента блока - этот оверхэд не окупится, в случае, если нужно изменить размер "контейнера" самого блока, и не более того.
Если я что то дико путаю - прошу поправить, и наставить на верный путь, поделиться своим опытом. Благодарю.
@vlad6085 я придерживаюсь методологии что внешние классы не должны влиять на поведение блока, чтобы задать блоку ширину, я создаю супер блок, называя его somename-page и миксую его элементы с блоками или это может выполнять блок grid
Вот хороший доклад по этому поводу https://ru.bem.info/talks/webcamp-odessa-2015/
Плюсую вариант
@tadatuta в обоих случаях вижу одну и ту же проблему, которую пока не знаю как решить. Допустим:
конфликт сетки и стиля блока - победит сильнейший. и допустим, нужно чтобы выполнились оба. как быть? единственным решением вижу выносить разметку сетки на уровень выше, как показывает @JiLiZART
случай конечно частный, и, вероятно, на практике это редкость, но все же.
@vlad6085 На самом деле случай не такой уж редкий. При использовании полного стека это решается за счет зависимостей — они позволяют гарантировать порядок склейки файлов.
Если использовать нашу сборку не хочется, но есть возможность подтюнить свою, то можно, например, исходить из того, чтобы сборщик учитывал порядок появления класса на DOM-узле (впрочем, это не всегда однозначно).
Если же решать эту задачу на уровне сборки не хочется, а порядок следования стилей в финальном CSS непредсказуем, я бы предложил повышать специфичность с помощью повторения класса:
@tadatuta решать на уровне сборщика - это тоже не панацея. не понял насчет повышения специфичности. как это будет выглядеть в верстке?
На уровне сборщика типа
ENB
— вполне себе панацея, мы так уже очень давно живем, полет нормальный.А про повышение специфичности я же кусок CSS привел выше. Если же вопрос про HTML, то речь все про тот же
<div class="block grid__col_3">
.@tadatuta разобрался, спасибо. @JiLiZART только что закончил смотреть доклад, который вы посоветовали. не совсем он "по этому поводу", точнее, совсем - обычный обзор методологии. единственное что по данной теме автор доклада вскользь предложил - раздавать блокам префиксы (l- для блоков лэйаутов/контейнеров, та же сетка, и b- для блоков-компонентов), что, в принципе, не сильно отличается от вынесения обычных классов сетки, как вы предложили.