Как можно быть уверенным, что применятся именно стили модификатора?

Мне никак не дает покоя 1 вопрос. Если мы вот так опишим блок и модификатор для блока:

.button { color: red; }

.button_color_blue { color: blue }

Затем в HTML укажем class="button button_color_blue". .

Таками образом кнопка станет синей только потому, что стили модификатора в CSS идут после стилей самого блока. Скажите, возможны ли варианты, когда возможно нарушение порядка следования в CSS? Например после обработки минификаторами. Или например препроцессор SASS вдруг конструкцию .block { &--modificator {} } начнет разворацивать в обратном порядке, и напишет в CSS .block--modificator, а уже потом сам .block Ведь как я понимаю тогда все сломается и кнопка будет красной, несмотря на то, что класс модификатора на теге есть. Как можно быть спокойным за все это?

Заранее спасибо.

7 years ago

Realetive

За порядок отвечают декларации, из которых генерируются зависимости. Это массив, поэтому порядок так определён жёстко.

P. S. .button_color_blue — плохой пример модификатора. Название должно отражать состояние, а не содержание, например: .button_state_default, .button_state_primary, .button_state_error, .button_state_success и т. д.

7 years ago

dima117

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

Если нужно расположить код модификаторов раньше блока или задать определенный порядок для нескольких модификаторов, можно задать зависимость блока от модификатора (или одного модификатора от другого) в технологии deps.js.

Например после обработки минификаторами

Препроцессоры стилей не должны менять порядок, т.к. от него зависит результат применения CSS (даже если классы названы не по БЭМ).

Название должно отражать состояние

Если color - это синоним theme, то это ок, т.к. название модификатора отражает состояние.

7 years ago

qfox

А если skin это theme, а tone это color, то всё совсем запутывается :-(

7 years ago

sagorshkov

Спасибо за ответы.

Таким образом получается, что только лишь "Соглашение по именованию" БЭМ-а мало? В связи с отказом от каскадности то, что стили будут вести себя именно так как ты ожидаешь грантируется еще дополнительными тулзами(описаными выше)? Я еще обратил внимание на DoCSSa методологию (http://mlarcher.github.io/docssa/#components), там используется БЭМ соглашение по именованию, но получается, что ты должен предельно внимательно следить за порядком в твоем SCSS файле модификаторов и классов, отвечающих за состояние? Это лежит на плечах разработчика? Для ясности приведу пример:

`@mixin controlButton-skin-default($selector) {

#{$selector} {
    background-color: #13CD62;
}

#{$selector}_state_error {
    background-color: inherit;
}

} `

При таком подходе получается, что если разработчик поменяет местами (допустим случайно), селокторы #{$selector} и #{$selector}_state_error в миксене, то модификатор просто не будет работать.

7 years ago

tadatuta

Такое поведение вряд ли можно отнести к особенностям методологии. Это скорее просто принцип работы CSS — если в одноранговых селекторах есть пересекающиеся правила, порядок становится важным и ложится на плечи разработчика. А дальше ему решать, как следить за порядком: самостоятельно или с помощью инструментария.

7 years ago

qfox

А ещё можно сделать их разноранговыми: .button.button_state_disabled

Чтобы оставлять комментарии, необходимо авторизоваться.