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

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

Ну во-первых немного лирики: не существует никакого единственно правильного варианта использования БЭМ в том или ином случае. Так как БЕМ это не набор аксиом и алгоритмов, а идея (чит. Идеология, философия, взгляд под другим углом и тп . ). Кроме того БЕМ не единственная в своем роде концепция, из первого что приходит на ум - SMACSS, OOCSS, Atomic CSS. Если посмотреть обобщенно, одно и то же разными словами с незначительными расхождениями (краткий обзор). Важно не название, а суть. Ты сейчас (да и вообще каждый, кто делает первые шаги на пути джедая :)) наверное думаешь - "Блин, ну нафига они придумали этот вынос мозгов?", или - "За что они так со мной?". Можешь не отвечать, я все равно знаю что так :). А суть, как раз таки, кроется в противоположной плоскости. Для того чтобы понять сложные вещи написаны зачастую непонятными словами (исключительно для пафоса) нужно: 1. Из всего потока информации четко, по пунктам выделить для чего оно создано и какие трудности собственно должно решить. 2. Методом научного тыка, на практике, найти эти проблемы, увидеть своими глазами и понять что данный инструмент, это не наказание с неба, а молоток для гвоздей которые ты раньше забивал ручкой отвертки.Чуть ближе к телу: Программисты вообще не любят верстку. Потому что они привыкли работать с продвинутыми языками программирования где все поддается логике, а все шишки уже набиты предшественниками. А связка html / css очень трудно вписывается в эту картину. Отсюда и постоянное стремление придумать велосипед. Следующее, существует 1000 и один способ сверстать даже простейший элемент. Что уж говорить о современных интерактивних веб-приложениях. В результате на выходе ты получаешь тысячи строчек кода, которые не понятно как работают, еще и непонятным образом взаимодействуют между собой, да так что сам их создатель через день не может разобраться.Ху из BEM: Собственно БЕМ ни что иное, как попытка бородатых кодеров из Яедекса применить парадигму ООП (объектно-ориентированного программирования) на процесс верстки. А если более точно то подвид ООП - КОП (не мент, компонентно-ориентированное программирование). И должен признаться, полностью даже удачная попытка.

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

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

А теперь отцентрируйте кнопку в хедере. .button - скелет всех кнопок, где его конкретный случай будет в шапке, ему все равно. button_mod - одьожки кнопок, одна зеленая, другая красная, а там большая итд .. Всповним как стоит задача: отцентрировать кнопку в шапке. То есть шапка .header а у нее есть элемент .button, который должен быть по середине. Отсюда:

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

📎📎📎📎📎📎📎📎📎📎