Верстаю по методологии BEM, но получается сильно расширный блок. Использовать только элементы не получается, поэтому приходится разбивать блок на подблоки, зависимые части главного независимого блока . Поэтому хочу спросить, не противоречит ли такой код методологии?
.product
.product__title
.product__img
// первый служебный блок
.product-properties
.product-properties__img
.product-properties__desc
// второй служебный блок
.product-content
.product-content__desc
.product-content__price
.product-content__date
@hardyHSM нет, ни сколько не противоречат. Но когда вы начнёте их стилизовать, скорее всего вам понадобится как-то позиционировать
product-propertiesиproduct-content, а методология не поощряет наличие внешней геометрии у блоков. Поэтому, скорее всего, всё равно придётся использовать микс:Где
.product__propertiesи.product__contentи будут содержать стилиmargin'ов и прочиеposition.Спасибо, я сначала подумал, что таким блоком можно на прямую позиционирование ставить, ведь все-равно они зависимы, и в другом месте, кроме этого блока, их не будет.
@hardyHSM это только вы об этом знаете (помните). БЭМ-разметка позволяет точно указать принадлежности и отношения — если сущность нигде (даже теоретически) не существует за пределами своего «родителя» (не обязательно ближайшего, вложенность допустима), то это элемент, а «родитель» — блок.
@Realetive cпасибо большое за ответ, буду знать. Еще вопрос, где можно найти примеры хорошего БЭМ`a? В коде яндекса сложно разбираться, а на более мелких проектах от других разработчиках думаю легче. Может у вас есть какой-то проект написанный по методологии БЭМ? Буду очень признателен если что-то посоветуете.
Хороший БЭМ редко встречается за пределами стека — слишком велика вероятность (и допущение) ошибки: «выпадение» элемента из блока, одинаковые модификаторы на одном теге, дублирование кода и т. д. И проект(ы) вам не поможет — каждый разработчик решает свои задачи, у них свои контексты, условия и ограничения. БЭМ силён именно принципами, а результат — это скорее побочный продукт, учиться лучше с истоков, а не глядя на результат. Очень хороший тон, например, задают bem-components — с помощью них уже можно сделать, наверное, 70% всех сайтов в мире. Ещё один полезный принцип при использовании БЭМ — идти от частного к общему, а не наоборот. Т. е. деление на блоки должно происходить на самых «глубоких» уровнях вложенности, постепенно поднимаясь «наверх».
@Realetive Ты хочешь сказать , что в библиотеках блоки как правило должны быть мельче чем на проекте?
@compolom, нет, «размер» блока никак не зависит от области использования. Важен функционал, причем чем он более низкоуровневый, тем выше степень реиспользования. Хороший пример — блок list. Это может быть маркированный список, нумерованный, список определений или произвольных сущностей. Списки можно сортировать, указывать диапазон ввода и смешение (offset). Короче — весь функционал работы с массивами. Передаем списку массив картинок — получаем галерею, связываем два списка — пагинация.