Size: a a a

2019 January 23

AY

Alexey Yarrr (qfox) in БЭМ
Dmitriy Khraponov
привет. Вопрос такой. В доке есть раздел про расположение блока относительно других блоков. Тут всё понятно, добавляем соотвествующий элемент и пишем туда отступы. Но взаимоотношения между блоками не заканчиваются на отступах. Что если связь определена цветом? Например шапка имеет тёмный bg-color, соотвественно всё что там должно быть светлого цвета. Цвет фона определяющий. Имею ли я право  записывать свойство color для блоков внутри шапки в эти связующие элементы (аля header__logo, header__description, header___menu и так далее)? Или же принято ограничиваться только позиционированием?
Пока про это устойчивого мнения нет, но есть рекомендация делать как через CSS Custom Properties, и пользоваться чем-то вроде whitepaper.tools
источник

AY

Alexey Yarrr (qfox) in БЭМ
Грубо говоря, если шапка (читай, любая область) выделяется из общей темы страницы — проще (и, кажется, правильнее) всего сделать для неё отдельную тему, а компоненты писать таким образом, чтобы они знали про это (как это сделано в whitepaper) и адаптировались
источник

DK

Dmitriy Khraponov in БЭМ
да, логично. Почитаю whitepaper, ни разу про этот проект не слышал, но выглядит интересно. Спасибо
источник

DK

Dmitriy Khraponov in БЭМ
ещё небольшой вопрос. Есть у меня состояние (проще говоря — кнопка меню), которое я меняю через добавление класса-модификатора по событию клик. Однако, я хочу по изменению менять стилизацию на нескольких блоках. Но если придерживаться концепции один файл = один блок, то как поступить правильнее? Создать столько классов-модификаторов (например block__name- -active) сколько нужно и стилизовать их отдельно? БЭМ же вроде против вложенности, которая, казалось бы, тут так напрашивается.
источник

Р

Роман in БЭМ
Dmitriy Khraponov
ещё небольшой вопрос. Есть у меня состояние (проще говоря — кнопка меню), которое я меняю через добавление класса-модификатора по событию клик. Однако, я хочу по изменению менять стилизацию на нескольких блоках. Но если придерживаться концепции один файл = один блок, то как поступить правильнее? Создать столько классов-модификаторов (например block__name- -active) сколько нужно и стилизовать их отдельно? БЭМ же вроде против вложенности, которая, казалось бы, тут так напрашивается.
БЭМ совсем не против вложенности.

Допустим, у нас есть блок-кнопка, которая по клику меняет модификатор темы (цвет) нескольких других блоков.
1) Берём какой-то родительский блок всех этих блоков (например, блок page) и «слушаем» там событие смены модификатора кнопки (.button.button.button_active)
2) На изменение «собираем» зависимые блоки (page же родитель, значит можно искать вглубь) и добавляем/меняем им модификатор темы: .some-block.some-block_theme_light.some-block.some-block_theme_dark).

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

DK

Dmitriy Khraponov in БЭМ
Роман
БЭМ совсем не против вложенности.

Допустим, у нас есть блок-кнопка, которая по клику меняет модификатор темы (цвет) нескольких других блоков.
1) Берём какой-то родительский блок всех этих блоков (например, блок page) и «слушаем» там событие смены модификатора кнопки (.button.button.button_active)
2) На изменение «собираем» зависимые блоки (page же родитель, значит можно искать вглубь) и добавляем/меняем им модификатор темы: .some-block.some-block_theme_light.some-block.some-block_theme_dark).

Такой подход изолирует эту логику от самих блоков кнопки и зависимых блоков, которым меняем тему. Мы можем даже поместить эту логику в модификатор блока page и подключать его по необходимости.
спасибо, Роман! Звучит убедительно. С точки зрения поддержки тоже наверное удобней видеть всё что происходит при мутации в одном месте. У меня правда не цвета, а расположения меняются, но смысл тот же, по событию поменяю параметры у миксов внутри затрагиваемых блоков.
источник
2019 January 24

IT

Ivan Tolstov 😐 in БЭМ
Привет. Может кто-нибудь показать пример использования attach из Бэм компонентов?

Хотелось бы увидеть пример кода, который отправляет файлы на сервер. Сейчас компонент аттач при сабмите формы возвращает строку
C:\fakepath\KitsuneInaWalletBlue-04.svg


Значение забираю со всей формы непосредственно.
источник

VH

Vitaly Harisov in БЭМ
Ivan Tolstov 😐
Привет. Может кто-нибудь показать пример использования attach из Бэм компонентов?

Хотелось бы увидеть пример кода, который отправляет файлы на сервер. Сейчас компонент аттач при сабмите формы возвращает строку
C:\fakepath\KitsuneInaWalletBlue-04.svg


Значение забираю со всей формы непосредственно.
а форме задан multipart/form-data ?
источник

AY

Alexey Yarrr (qfox) in БЭМ
Vitaly Harisov
а форме задан multipart/form-data ?
А я не задаю никогда, байтики экономлю
источник

IT

Ivan Tolstov 😐 in БЭМ
Vitaly Harisov
а форме задан multipart/form-data ?
Да, задан
источник

EW

Eugeniy World in БЭМ
А как ты значение собираешь?
источник

EW

Eugeniy World in БЭМ
просто если явно value читать, то там всегда будет фейкпас
источник

EW

Eugeniy World in БЭМ
это типо в целях безопасности
источник

IT

Ivan Tolstov 😐 in БЭМ
Я использую bem-forms, метод getVal()
источник

IT

Ivan Tolstov 😐 in БЭМ
Собирает значения со всех полей формы
источник

IT

Ivan Tolstov 😐 in БЭМ
источник

IT

Ivan Tolstov 😐 in БЭМ
Так что никто форму с аттачем не использовал?
источник
2019 January 25

И

Илья in БЭМ
А можно делать блок / модицикатор / элемент?
источник

И

Илья in БЭМ
порядок менять на БМЭ?
источник

VI

Vadim Ivanov in БЭМ
Илья
порядок менять на БМЭ?
нет
источник