Как правильнее использовать БЭМ в флекс верстке?

Question

[Adexs]

Решил попробовать сверстать страницу с помощью флексов, как правильнее здесь использовать методологию БЭМ? Делать дополнительные контейнеры/обертки (хз как правильно назвать) с флекс-свойствами или расширять уже существующие классами, типа .b-block .b-block_flex?

Answer 1

[dom1n1k]

Всё зависит от того, будут ли во флекс-ячейках элементы (используемые только в этом контексте) или блоки (могут быть переиспользованы где-то ещё).

В первом случае всё просто, приблизительно так:

<div class="container">
	<div class="container__header"> ... </div>
	<div class="container__body"> ... </div>
	<div class="container__footer"> ... </div>
</div

.container {
	display: flex;
	...
}
.container__header {
	flex: 1 1 auto;
}
.container__body {
	flex: 1 1 auto;
}
.container__footer {
	flex: 1 1 auto;
}

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

<div class="container">
	<div class="container__header">
		<div class="some-header-block"> ... </div>
	</div>
	<div class="container__body">
		<div class="some-body-block"> ... </div>
	</div>
	<div class="container__footer">
		<div class="some-footer-block"> ... </div>
	</div>
</div

В общем, в процессе верстки нужно задавать себе вопрос - этот блок может быть использован где-то ещё? Пусть не прямо сейчас, но хотя бы теоретически в будущем? Если да - делать обертки.

Comments

[Hyubert]

Разве не так?

<div class="container">
  <div class="container__header header">
    <div class="header__block"> ... </div>
  </div>
</div

[dom1n1k]

Hyubert, что такое header__block? Оформлено как элемент, но называется почему-то блок.
Если всё-таки элемент, то смиксовать container__header и header в принципе как бы и можно, но практика показывает, что это опасно и может быть чревато проблемами. Любое css-свойство, указанное и там, и там - будет перекрыто и затерто в труднопредсказуемом порядке.

[Hyubert]

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

[dom1n1k]

Абсолютно любое свойство. Если оно по каким-то причинам окажется указанным и для обертки, и для блока - одно из значений будет затерто, другое останется. Но какое именно - зависит от порядка стилей в файле/бандле, который даже автор часто не помнит наизусть, не говоря уж о коллеге, подключившемся в проекту позже. А если там это всё еще перекручено с медиа-запросами, например, найти баг будет ещё сложнее.

[Hyubert]

dom1n1k: что здесь перетреться?

.container
  prop: value // 1
  &__header
    prop: value // 2

.header
  prop: value // 3
  &__element
     prop: value  // 4

[Hyubert]

dom1n1k, вроде понял о чем вы
<div class="container__header header">
вы говорите о точ что.header может перетереть .container__header, тогда да, вы правы такой вариант возможет, и все зависит от того какой файл будет подключен последный.

[dom1n1k]

Да, зависит от порядка файлов и стилей в этих файлах.
А ещё может быть случай, что это свойство - font-size, задаваемое в em (то есть в единицах относительно предыдущего уровня). Тогда оно не перезатрется начисто, а унаследуется в непредсказуемом порядке.

[Hyubert]

dom1n1k, только в вашем варианте с обертка не понятно в какой файл прописивать эти класы .some-header-block?

[dom1n1k]

Ну это уже надо смотреть по вкусу и по ситуации. Кто-то выносит вообще все блоки в отдельные файлы. Кто-то описывает "родственные" блоки вместе. Это уже больше вопрос удобства организации workflow и принятых в проекте соглашений. Фишка в том, что конечный результат, который мы видим в браузере, от этого не зависит никак.

[Hyubert]

dom1n1k, тоесть .some-header-block можно отнести в файл header?
И в таком подходе может возникнуть проблема в с очень глубокой вложеностю, не?

[dom1n1k]

С точки зрения функционирования сайта нет никакой разницы, в каком файле описан блок. Это исключительно вопрос удобства разработки и (возможно) применяемых инструментов сборки.

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

Answer 2

[cssfish]

Можно и так, и так. Потому что БЭМ не про это.

Comments

[Adexs]

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

[cssfish]

повторю тоже самое другими словами: так же, как и с таблицами, флоатами и прочим

Answer 3

[Сергей]

Лучше писать на уникальные классы все флекс-свойства.

Если будите пытаться сделать свой "бутстрап" из флексов, рано или поздно запутаетесь и забросите эту идею. И тем более другие разработчки не поймут

Например .header__wrapper вместо .flex-wrap.flex-wrap--aic.flex-wrap--jcsb

Answer 4

[Alexander]

Да зачем оно надо там ? Создай базовые классы, я делаю это так:

.flex-container{
display: flex;
justify-content: center;
flex-flow: row wrap;
}
.flex-item{
margin: 15px;
}