Какие свойства нужно прописывать для каждого из типов БЭМ?

Здравствуйте! У меня несколько вопросов по БЭМ, которые не дают покоя... Я неоднократно встречался с мнением, что блоку нельзя давать размеры. То есть получается, что ни один из блоков я не могу передвинуть (чуть-чуть) с помощью margin. Не могу задать padding и ширину? Отсюда вопрос: Какие свойства нужно прописывать каждому из типу БЭМ... Блоку, Элементу, Модификатору?
Второй вопрос: Хочу начать с того, почему решил перейти к БЭМ... Цель: Независимые блоки!!! Отсюда вопрос... Дело в том, что я хочу использовать БЭМ по минимуму, только в части именования классов. Но будет ли этого достаточно, для создания независимых блоков? И... я так понимаю, что без разделения свойств на типы, не обойтись... Это правда? ... Далее... Я не хочу заходить в миксы (я пока этого не понимаю) . Как-то рассматривался пример, когда div имел класс блока и класс элемента вместе... И когда элемент включал в себя блок (в моём представлении, только блок включать элементы ) . То есть это всё слишком заводит в БЭМ. Я не могу использовать всё это разом в новых проектах, запутаюсь! А особенно в части LESS и JS... Я слышал из одного курса, что там вообще, для каждого блока на сайте, создаётся LESS файл. Дело в том, что у меня уже есть готовый gulp-file для проектов. Получается, что из-за БЭМ, мне придётся всё переделать. По сути, учиться заново) А хочется писать по LESS нормально, без оглядки на блоки, а только на наименовании. Помогите пожалуйста разобраться!
P.S. Извините, за такой большой вопрос... В голове путаница... Спасибо!
  • Вопрос задан
  • 1201 просмотр
Пригласить эксперта
Ответы на вопрос 2
movasyl
@movasyl
semper tiro
Ну во-первых немного лирики: не существует никакого единственно правильного варианта использования БЭМ в том или ином случае. Так как БЕМ это не набор аксиом и алгоритмов, а идея (чит. Идеология, философия, взгляд под другим углом и тп ...). Кроме того БЕМ не единственная в своем роде концепция, из первого что приходит на ум - SMACSS, OOCSS, Atomic CSS. Если посмотреть обобщенно, одно и то же разными словами с незначительными расхождениями (краткий обзор). Важно не название, а суть. Ты сейчас (да и вообще каждый, кто делает первые шаги на пути джедая :)) наверное думаешь - "Блин, ну нафига они придумали этот вынос мозгов?", или - "За что они так со мной?". Можешь не отвечать, я все равно знаю что так :). А суть, как раз таки, кроется в противоположной плоскости. Для того чтобы понять сложные вещи написаны зачастую непонятными словами (исключительно для пафоса) нужно:
1. Из всего потока информации четко, по пунктам выделить для чего оно создано и какие трудности собственно должно решить.
2. Методом научного тыка, на практике, найти эти проблемы, увидеть своими глазами и понять что данный инструмент, это не наказание с неба, а молоток для гвоздей которые ты раньше забивал ручкой отвертки.
Чуть ближе к телу:
Программисты вообще не любят верстку. Потому что они привыкли работать с продвинутыми языками программирования где все поддается логике, а все шишки уже набиты предшественниками. А связка html / css очень трудно вписывается в эту картину. Отсюда и постоянное стремление придумать велосипед. Следующее, существует 1000 и один способ сверстать даже простейший элемент. Что уж говорить о современных интерактивних веб-приложениях... В результате на выходе ты получаешь тысячи строчек кода, которые не понятно как работают, еще и непонятным образом взаимодействуют между собой, да так что сам их создатель через день не может разобраться.
Ху из BEM:
Собственно БЕМ ни что иное, как попытка бородатых кодеров из Яедекса применить парадигму ООП (объектно-ориентированного программирования) на процесс верстки. А если более точно то подвид ООП - КОП (не мент, компонентно-ориентированное программирование). И должен признаться, полностью даже удачная попытка.

Что мы имеем:
БЭМ-сущность, она же блок, а он же объект, который также известен как компонент или модуль, отвечающий принципу абстракции ООП - А простыми словами, это часть нашей веб-страницы на которую мы разок глазом бросили и особо не задумываясь можем ее выделить как нечто самодостаточное. То, что можно описать одним словом. И слово это будет одновременно и названием, и не глядя на картинку сделает понятным как блок может выглядеть, да еще и ко всему этому опишет его функции и принцип его работы. Вместе с тем его можно переиспользовать в разных местах этой страницы, или на других страницах сайта.
Пример:
- Алло, Алекс, я зарегистрировался на тостере, как здесь задать вопрос?
- Да, проще простого, жмешь на кнопку 'Задать вопрос' спрашиваешь и жмешь кнопку "отправить".

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

- Эй, Алекс, а помнишь тот сайт который мы сдали на прошлой неделе?
- Ну да, еще даже исходники на рабочем столе валяются.
- Супер, заказчик просил кнопки в формах поменять из брендового-зеленого на более яркий зеленый, а то что-то ему в глаза не бросается. :) И ту кнопку, которая в шапке "Узнать больше" надо бы отцентрировать.
- Ок, три минуты, у нас же там все по less-bem, чики-пики.

В данном случае ни ты ни я не помним ни точной реализации кнопок ни реализации таблиц, нас вообще не интересует что там внутри, какие теги использовались, сколько там инпутов и тп. Мы абстрагируемся от более примитивного к более осмысленному. Соответственно, когда будешь редактировать, будешь делать это не методом - пальцем в небо. А попросту читая по названиям классов. Сначала найдешь клас header дальше в нем класс button.
Блок button - это кнопка в общем, он задает общий скелет, шаблон по принципу которого выглядят другие. В идеале туда попадают стили для ресета стилей браузера, ну и еще что-то, если оно присутствует во всех кнопок на макете.
(схема пример)
/* HTML types */

<a class='button' href='#'>Кнопа</a>
<button class='button' href='#'>Кнопа</button>
<input class='button' type="submit" value="Кнопа">
/* bem entity */

.button{
                                 // reset
  user-select: none;
  display: inline-block;
  text-decoration: none;
  touch-action: manipulation;
  
                                 // common
  padding: 0.5em 1em;
  border-radius: 2em;
  text-align: center;
}

/*        _MODS_       */
// SIZE (SCSS)
.button{
   &_size_s{
     font-size: 1rem;
     }
   &_size_l{
     font-size: 2rem;
     }
}

// COLOR
.button{
  &_primary{
    background: #607D8B;
    color: #ffffff;
    }
  &_secondary{
    background: #8BC34A;
    color: #ffffff;
    }
}

// PARENT__BLOCK
.header{
    &__button{
      display: block;
      width: 200px;
      margin: 0 auto;
     }
}

codepen.io/kovbassa/pen/ObrqZv?editors=1100

Дале нас просят изменить что-то в виде кнопок.
Какие - брендового цвета, какие нужно - ярко зеленые. Все что какой, какая, какие итп .. - это модификатор .button__mod-name, здесь и прямоугольные и колор и закругленные и большие и маленькие. Пример, сделаем книпкы в формах заметнее.
<button class="button button_accented button_xl">text</button>
             // common, color,            size

А теперь отцентрируйте кнопку в хедере.
.button - скелет всех кнопок, где его конкретный случай будет в шапке, ему все равно.
button_mod - одьожки кнопок, одна зеленая, другая красная, а там большая итд ..
Всповним как стоит задача: отцентрировать кнопку в шапке.
То есть шапка .header а у нее есть элемент .button, который должен быть по середине.
Отсюда:
<header>
<button class="button button_brand header__button" >text</button>
             //common, color,        local position
</header>

На конец - блоки могут состоять, как из меньших блоков так и из элементов. Элементы не могут иметь своих блоков, или элементов. Один DOM узел (html тег) может быть одновременно и блоком и элементом родительского блока.
Относительно размеров, лучше, когда размеры задает скелет страницы, тобиш сетка. Поэтому старайся делать блоки по максимуму резиновыми в ширину. Старайся оперировать относительными величинами (%, em, rem) а не абсолютными - px.
А вообще не так важно правильно ты используешь BEM или нет, важнее стабильность стиля. Если начал верстку в определенном стиле, старайся придерживаться его до конца. Например хорошей практикой вертикального позицонування элементов на странице будет использование только margin-bottom, или только margin-top. А не все в кучу и margin's collaps повсюду в итоге.
Ответ написан
ArsenyMatytsyn
@ArsenyMatytsyn
Руководитель frontend направления, предприниматель
Кратко и просто — блок не знает, что происходит вокруг, за него это делает родительский блок. Это просто однонаправленный поток данных.

Долго и с эпитетами — в документации.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы