Pull to refresh

Comments 22

Я считаю, что двойное нижнее подчеркивание должно появляться только однажды, в имени селектора.

Это очень важное правило, о чем написано в методологии. Т.е. делать элемент элемента вообще нельзя, а не просто не рекомендуется.
Если для повышения специфичности приходится использовать !important, то с кодом по определению что-то не так. По-хорошему за такое нужно давать по пальцам. Поддерживать код с кучей !important крайне сложно.

По поводу методологии БЭМ как таковой. Да, действительно, она позволяет решать проблемы с модульностью и переносимостью кода на больших и средних проектах.

В то же время она обладает и недостатками. Самый основной из них — это многочисленные классы с длинными названиями. Хорошо, если у класса сравнительно короткое имя c-card, как в примерах в статье, но если это будет какой-то c-front-page-slider или c-contact-information, то список классов у элементов может банально перестать вмещаться в окне редактора (80-120 символов чаще всего). Работать с таким HTML-кодом крайне проблематично, да и выглядит он не очень красиво.
Чем мне нравится SMACSS – если его правильно использовать, то он сохраняет все плюсы BEM, но при этом позволяет обходиться без очень длинных классов
UFO just landed and posted this here

В 9 пункте описано довольно неплохое решение для этой проблемы, можно использовать class^= и class*= и тогда это:


<div class="container container--shopping-cart">
  <div class="container__content container__content--special-offer">
    <h2 class="container__title">Title</h2>
  </div>
</div>

можно превратить в это:


<div class="container--shopping-cart">
  <div class="container__content--special-offer">
    <h2 class="container__title">Title</h2>
  </div>
</div>

используя вот это:


.container, [class^="container--"], [class*=" container--"] {
  border: 1px solid grey;
  padding: 10px;
  font-family: Arial, sans-serif;
}
.container--shopping-cart {
  border: 4px solid orange;
  background-color: #eee;
}
Вот как раз так по методологии БЭМ писать и не надо.

Я согласен, но, как способ избежать слишком большого числа классов, может пригодиться

Не как просто писать много классов. В первом варианте хотя-бы явно понятно где начинается блок, какой у блока модификатор. Где начинается элемент блока. Во втором варианте что вы написали это не явно, и не понятно.
UFO just landed and posted this here
Стоит это добавить прямо в статью, потому что я, когда читал этот пункт, вообще не понял о чём речь и пришёл в комментарии об этом написать.

Немного изменил этот пункт.
Добавлять в статью не вижу смысла, так как цель пункта только в том, чтобы сказать о том, что такой способ существует, а для более подробного чтения есть ссылка на статью об этом способе.

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

Представим, что вы написали блок стилей с селектором в виде .container, [class^=«container--»], [class*=" container--"]. По мере роста проекта какому-то из разработчиков захотелось использовать в селекторе конструкцию container--. И вот тут его ожидает сюрприз: к его стилям стали подмешиваться совершенно чужие правила. Если таких селекторов с классами будет много, то разработка и поддержка такого проекта быстро превратиться в пробежку по минному полю.
UFO just landed and posted this here
Просто вы рассматриваете БЭМ только как набор правил по именованию селекторов, поэтому на этом уровне фактически нет разницы в применении стилей к .container*, [class^=«container--»] или [class*=" container--"]. Но не нужно забывать, что БЭМ — это методология, и у нее есть инструменты для работы и на уровне JS (фреймворк i-bem.js). В нем, как раз, js-поведение DOM-элементу назначается на основе названия блока. Именно поэтому отдельный .container и необходим.
UFO just landed and posted this here
Еще хороший вариант — формировать интерфейс в bemhtml (т.е. не работать напрямую с html) — это устраняет все недостатки, связанные с количеством и названиями классов.

Очень хорошая статья. И во многих подходах я пришел примерно к таким же решениям. Пара замечаний


№1
Тоже немного колбасит, когда классы не совсем следуют структуре вложенности. Но я для себя решил что структура элементов должна быть плоской. Иногда по коду получается что block__elem2 вложен в block_elem1, но с этим можно жить и достаточно просто разобраться, потому что компоненты изолированы


№2
Не использую c-, l- префиксы. На мой взгляд это избыточно и немного мусорно. И последнее время все меньше использую хелперы, предпочитаю вставлять миксины.


№3
Тут речь почему-то идет не про настоящие врапперы, а просто про вложенность компонентов. Иногда реально нужна обертка, потому что дивов не хватает застайлить. Тогда название блока выношу наверх, а дальше использую &__inner.


№4
Тоже предпочитаю модификаторы, но имхо не стоит бояться называть по используемому месту, например, так вполне лучше .button--card-view, нежели абстрактные .button--small .button--round.


№6
Я больше склоняюсь к .block--active, по крайней мере обычно начинаю с него. Если действительно предстоит много манипулировать состояниями через JS в подобных компонентах, то .block.is-active будет проще.


№10
На мой взгляд не стоит бояться и делать различные ветки кода в зависимости от медиа-выражений. Т.е. у меня это выглядит примерно так


.block {
  @respond-to('mobile') {
   // стили мообилок
  }

  @respond-to('tablet-desktop') {
   // стили планшета и десктопа
  }
}

respond-to это миксин, который генерит медиавыражения в зависимости от ключевого слова.

З.Ы.


№9
На мой взгляд это надуманная проблема. Там не так уж много классов выходит. Гляньте как Ангуляр, к примеру, инпуты обвешивает, вот это уже реально перебор.

  1. "Не появятся ли у компонентов миллион классов?"


<button class="c-button--primary-huge  is-active">Click me!</button>

Слишком хрупко. Не понимаю, чего все верстальщики так за классы держатся. С атрибутами тут получается куда гибче, проще и наглядней:


<button my_button="primary huge" my_button_active="true">Click me!</button>

[my_button] { border: 1px solid steelblue; background: none; padding: .25rem }
[my_button*="huge"] { zoom: 2 }
[my_button*="primary"] { background: steelblue; color: snow }
[my_button_active="false"] { opacity: .5 }

my_button — блок
primary, huge — статические модификаторы
my_button_active — динамический модификатор

Вот тут ребята то же самое придумали: http://amcss.github.io/
Вот скажите, почему все используют в качестве разделителя для модификатора "--". Ведь в официальном соглашении по именованию используется "_" ru.bem.info/methodology/naming-convention/#Имя-модификатора. Я понимаю, что это альтернативная схема именования, но зачем отходить от официальной Яндекса? Чтобы было больше путаницы?

Этот стиль именования очень сильно популярен в англоязычной среде, думаю, что его популярность связана с тем, что автор этого стиля, Гарри Робертс, одним из первых заговорил о БЭМ в англоязычной среде. Советую прочитать вам оригинальную статью, там он многое объясняет.

Sign up to leave a comment.

Articles