БЭМ (Блок-Элемент-Модификатор

[sigmaray]

Что вы думаете насчёт БЭМ?
Что конкретно из БЭМ вы используете, какое подмножество этого стандарта?
Есть ли у кого-нибудь из этой гуглогруппы опыт использования одних и тех же элементов в разных проектов (используя БЭМ)?
Кто-нибудь использовал bemjson?

Описание БЭМ:
https://ru.wikipedia.org/wiki/%D0%91%D0%AD%D0%9C

[Александр Костриков]

Что вы думаете насчёт БЭМ?

Продукт Яндекса для Яндекса. Иногда всплывает, но кроме Яндекса никому не нужен. Как бы его не пиарили.

[Alexander Oryol]

2016-12-12 14:19 GMT+03:00 Александр Костриков <alexandr....@gmail.com>:

Что вы думаете насчёт БЭМ?
Продукт Яндекса для Яндекса. Иногда всплывает, но кроме Яндекса никому не нужен. Как бы его не пиарили.

Коллега, смотря что понимать под BEM. Если набор tools, то пожалуй да.
Если правила организации CSS кода - то вы не правы.
Я уже даже и не знаю как поддерживать большие серьезные проекты без BEM, чтобы это не становилось CSS-hell.

 

On Monday, December 12, 2016 at 3:02:29 AM UTC+3, sigmaray wrote:

Что вы думаете насчёт БЭМ?
Что конкретно из БЭМ вы используете, какое подмножество этого стандарта?
Есть ли у кого-нибудь из этой гуглогруппы опыт использования одних и тех же элементов в разных проектов (используя БЭМ)?
Кто-нибудь использовал bemjson?

Описание БЭМ:
https://ru.wikipedia.org/wiki/%D0%91%D0%AD%D0%9C

--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на https://groups.google.com/group/ror2ru
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
 
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror...@googlegroups.com
---
Вы получили это сообщение, поскольку подписаны на группу "RubyOnRails to russian".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес ror2ru+unsubscribe@googlegroups.com.
Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/ror2ru/a6b03ae3-70b3-4903-9288-941d6f59e90b%40googlegroups.com.

Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--

Alexander Oryol <eagle...@gmail.com>

[Сергей Соколов]

Плюсую про распиаренный никому не нужный продукт. 

Видел от него только боль и старадание, застал его еще в самом начале. Человек, создавший сие чудо, не удосужился узнать, как переводится css, и почему они каскадные. 

Участвовал в 2 проектах с БЭМ. в обоих его взяли потому-что-популярный-о-чем-там-я-не-смотрел-верстать-не-умею. 

Из минусов, которые я ощутил тогда - людям надо быстро что-то переделать, добавить похожий блок - они просто копипастят и переделывают. Переписывать у каждого элемента классы и стили под них никто не хочет/забывает. В итоге ужасная каша, в которой километровые названия классов только путают. Более того, даже яндекс использует БЭМ далеко не повсеместно, даже в контексте одной страницы. 

Из плюсов - стандартизация, но в моем случае всегда хватало стандарта гораздо короче. 

Общие стили выноси в отдельные контролы с названиями .control_..., необщие в отдельных файлах на каждую страницу с ключевым классом на body - .page_... . Остальные определения уже внутри этих.

В некоторых проектах были вынесены еще темплейты отдельно. И все. Этого хватило уже не на один проект, ни одного файла даже близко к 1к строк не было, стили на другие страницы / контролы не аффектили.

PS весь ад CSS на проектах исходит из того, что люди вставляют свои определения не внутри какой-то сущности, а просто так, некаскадно. И на файлики не раскладывают, а поскольку в файликах с 3к+ строк искать очень трудно, новое просто подписывается вниз. Но это совершненно не значит, что надо делать огромные уникальные названия классов и отказаться от каскадности. Яндекс как-то рассказывал, что и на каждую страницу лучше отдельные приложения иметь, чтобы если там концерн сломался или что еще - все остальное не сломалось. 

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

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

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

12 декабря 2016 г., 15:09 пользователь Alexander Oryol <eagle...@gmail.com> написал:

Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/ror2ru/CAPGtWndWLHhiaCae%3Dnkm3qUscP2iUeBiSMvRM2aJeC8_LhEpTQ%40mail.gmail.com.

[Александр Костриков]

> Из минусов, которые я ощутил тогда - людям надо быстро что-то переделать, добавить похожий блок - они просто копипастят и переделывают. 

Я думаю, это основной минус. Можно делать супер проекты по БЭМ, но когда придёт время его поддерживать руками "не создателя", вылезут все непонятки с БЭМ. Все эти устные неформализуемые понятия без возможности накидать утилит типа flake, pep8, typescript умирают по одной и той же причине - не масштабируется, если у вас нет мощной мотивации гнобить за незнание неофитов. 

А если клиенту нужно сейчас или подешевле - БЭМ летит ненужным балластом со словами "мы потом починим". Тратить силы на постоянные выплаты технического долга никто не станет => настанет момент когда БЭМ вылетит окончательно.

Думаю, что БЭМ может жить в двух случаях:

1) Проект для себя или терпеливого заказчика и можно делать "красивую архитектуру". Которая неуникальна и можно придумать ещё кучу конвенций по именованию: таблица/ячейка, див/див/див, etc.

2) Проект шлёт заказчика и имеет мощное девелоперское лобби. Valve time, Yandex culture, etc.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес ror2ru+un...@googlegroups.com.

Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/ror2ru/a6b03ae3-70b3-4903-9288-941d6f59e90b%40googlegroups.com.

Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--

Alexander Oryol <eagle...@gmail.com>

--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на https://groups.google.com/group/ror2ru
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
 
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror...@googlegroups.com
---
Вы получили это сообщение, поскольку подписаны на группу "RubyOnRails to russian".

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес ror2ru+un...@googlegroups.com.

[sigmaray]

Мне bemjson на первый взгляд понравился. Можно не писать руками все шаблоны, а собирать шаблоны из кирпичиков, описывая страницы в JSON-е.

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

И да, в этом топике правильно написали, из БЭМ можно использовать только его подмножество - правила написания CSS-кода. Не обезательно использовать всё что есть в БЭМ.

[sigmaray]

Попробовал использовать БЭМ, без каких-либо утилит. Синтаксис выбрал такой: .block__child--modifier

К таким выводам пришел.

CSS specifity и каскадность по возможности лучше избегать. !important - зло

В проекте один разработчик вместо SASS-миксинов добавлял ко многим элементам служебные классы, описывающие повторяющиеся в разных элементах стили. Запретил эту практику. Сказал использовать миксины.

Модификатор стоит писать в конце после "--". Это мегаполезно, разделять название блока и модификатор.

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

Что не понравилось: запрет на вложенность на более чем одном уровне в названии класса. У меня сложилось мнение что стоит указывать название модуля (экшена, контроллера или jquery-плагина).

Если блок будет использоваться только в рамках одного экшена, писать .a-controller-action__block__child--modifier.

Если блок будет использоваться только в рамках одного контроллера в нескольких экшенах, писать .с-controller-block__child--modifier.

Если блок будет использоваться глобально, писать .b-block__child--modifier.

Если надо создать сложный плагин для jquery, писать .library-name-block__child--modifier.

Во первых мне не нравится что люди заявляют что БЭМ решает проблему с коллизией имен. Не решает. Я не знаю как сделано в bem tools, но если не использовать никакие утилиты, несколько разработчиков могут случайно сделать в разных модулях приложения 2 блока с одним и тем же названием. Часто бывает что один разработчик не знает что делает второй. Во вторых часто страница простая и полезно считать саму страницу блоком.

Я как и любой новичок в начале совершал типовую ошибку: писал названия классов с бесконечной вложенностью:

.block__child__grand-child__grand-grand-child--modifier. Так делать не надо. В классе не должна отражаться вся DOM-иерархия. Надо писать .b-block__grand-grand-child--modifier. Блоками делать только логически независимые атомарные сущности. Что попало не нужно делать блоком.

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

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

В проекте я начал использовать bem без префиксов (b-, a-, c-). Только js-префиксы использовал. В следующих проектах префиксы наверное буду использовать.

Сложилось мнение что фанаты БЭМ копченые шизофреники. Запрещают вложенность более чем одного уровня. Я считаю это безумием. Мне одинарной вложенности недостаточно, двойная вложенность с указанием модуля - самое то. И на сайте БЭМа ничего не пишут про CSS препроцессоры. Яндекс БЭМ в 2005 году начал использовать. Видимо с 2005 года у них всё осталось без изменений. Детский сад. Я пока использую SCSS/SASS (&__child, миксины, переменные). PostCSS не было времени изучить, но может быть перейду на него в будущем.

[sigmaray]

Мне пару недель назад прислали ссылку на PostCSS Modules: https://evilmartians.com/chronicles/postcss-modules-make-css-great-again
Мне это показалось полным безумием.
В больших проектах, например в гугле, наверно такие вещи рационально использовать. Насколько я понял у сервисах гугла названия CSS классов давнообфусцированы? Например в гуглогруппых в которые я прямо сейчас пишу эту телегу
Но в мелких проектах такое юзать слишком weird.

[CapeRatel]

Сам не верстаю, но недавно искал для себя стандарт. https://operatino.github.io/MCSS/ остановился тут

понедельник, 12 декабря 2016 г., 6:02:29 UTC+6 пользователь sigmaray написал:

[sigmaray]

Я подумал недавно. Я год назад писал бред. Не надо создавать множетственную вложенность блоков. Это типичная ошибка почти всех людей, начинающих использовать БЭМ.

Пока пришёл к такому варианту: с помощью префиксов указывать где используется тот или иной блок, таким образом всё распихивается по независимым скоупам, не нарушая принципов БЭМ. Если блок, который используется в одном конкретном экшене, нужно использовать в другом месте, то с помощью find and replace выкидываем `.a-companies-index-` и меняем его на `b-`.

============================

.a-companies-index # `.a-` prefix means that this block is related to specific action

  .a-companies-index__show-additional-info-link

  .a-companies-index__contact-button

  .a-companies-index-choose-company # This block is used few times withing the scope of one action

    .a-companies-index-choose-company__child

      .a-companies-index-choose-company__grandchild

  .a-companies-index-choose-company

    .a-companies-index-choose-company__child

      .a-companies-index-choose-company__grandchild

  .c-companies-rankings # `.c-` prefix means that this block is used few times withing the scope of one controller

    .c-companies-rankings__value 

  .c-companies-contacts

    .c-companies-contacts__contact

      .c-companies-contacts__button

  .b-info

    .b-info__row # `.b-` prefix means that this block can be used multiple times across entire application

============================

Подобные префиксы стоит использовать только для указания контроллера, экшена, jquery-плагина которые вы разрабатываете. Можно ещё префикс `l-` ввести для верстки layout-ов. В других случаях не надо злоупотреблять созданием длинных паровозов. Нужно ограничивать себя в вагоностроении.

В этой статье (https://ru.bem.info/forum/158/) пишут:

<< Типичная ошибка: Попытка вложить имя элемента в имя блока. Чтоб "схитрить" и "как-будто не вложить", написать не block__el1__el2 а blockel1__el2 или block__el1el2. Так нельзя. >>

Да, плохо, кроме тех случаев, которые я оговорил. В других случаях так делать не надо.

[sigmaray]

Через год я наверно снова напишу что я был тупым и всё надо делать не так.

[Илья Плотников]

Подобные вопросы у разработчиков как правило обнажают плохую работу архитектора. Это был камень в сторону Яндекса давно больного синдромом nih.

В настоящее время популярные фреймворки перешли на прекомпиляцию js компонентов, гарантируя уникальность стилей uuid метками. И это, на мой взгляд, есть единственный правильный путь.
За примером далеко ходить не надо, т.к. именно рельсы научили всех* прекомпилировать ассеты

*На конец 2017 года еще далеко не всех

26.11.2017 7:57, sigmaray пишет:

Через год я наверно снова напишу что я был тупым и всё надо делать не так.

--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на https://groups.google.com/group/ror2ru
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
 
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror...@googlegroups.com
---
Вы получили это сообщение, поскольку подписаны на группу "RubyOnRails to russian".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес ror2ru+un...@googlegroups.com.

Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/ror2ru/f7e66f40-9805-4825-9e58-0ff816ed03d4%40googlegroups.com.