Jump to content
  • Sign Up
  • 0

BEM с человеческим лицом


nerv

Question

В статье BEM с человеческим лицом есть комментарий:

БЭМ — был полезен, но морально устарел. При современной компонентной разработке фронтенда, с возможностью инкапсуляции и байндинга стилей — вообще не нужен. Народ по иннерции пихает его куда можно и куда нельзя, но пора уже посмотреть на него свежим взглядом. Главная польза БЭМа в том, что в свое время он показал, что в стилях — должен быть порядок и за это ему спасибо.

кто что думает по этому поводу?

Link to post
Share on other sites

23 answers to this question

Recommended Posts

  • 0
58 минут назад, nerv сказал:

кто что думает по этому поводу?

Мое мнение не поменялось. БЭМ - шлак :D

Точнее, как почти всегда у яндекса, идея была неплохая, но реализация шлак. 

Link to post
Share on other sites
  • 0
1 час назад, nerv сказал:

кто что думает по этому поводу?

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

Link to post
Share on other sites
  • 0
1 час назад, alexriz сказал:

Мое мнение не поменялось. БЭМ - шлак

тогда, какой подход ты используешь? Например, согласной моей ссылке под альтернативой BEM понимаются css modules

http://www.sitepoint.com/understanding-css-modules-methodology/

http://glenmaddern.com/articles/css-modules

https://github.com/css-modules/css-modules

https://habrahabr.ru/post/270103/

Link to post
Share on other sites
  • 0

Я отделил тему про БЭМ, а то к теме что читают форумчане, это как-то не очень относится.

2 часа назад, nerv сказал:

тогда, какой подход ты используешь? Например, согласной моей ссылке под альтернативой BEM понимаются css modules

Скажем так, модульность появляется в любой методологии, сама собой. Просто потому, что это логично и естественно. Ну правда. Тот же БЭМ элементарно разбивается на модули, более того они прямо к этому призывают. 
Другой вопрос в самом подходе организации имен селекторов для компонентов. Хоть они упорно пытаются навязать, что это прям не так уж важно, и писать нечто подобное .block--element__mod - это норм, хотя это нифига не норм. Ну да черт с ним с самим синтакисом, это не так принципиально, при том, что по тому же БЭМ можно прикрутить и менее адовое именование. Да в статье правильно написано все, вцелом. Потому что в БЭМ и правда слишком много жести, надо быть гибче. Но в статье не описан один важный момент, как и во всех про БЭМ. Не нужно в понятие модификатора пихать все подряд. Я искренне считаю, что это слишком очевидно. По БЭМ модификатор это чуть ли не все, начиная от просто чуть другого цвета фона в элементе, заканчивая какими-то опциональными вещами, вроде отображения элемента. А всего-то нужно разделить понятия модификатора на модификатор (mod) и состояине (state). Так жить становится на много проще.
Это что касается моего отношения к БЭМ.

Что касается меня, то у меня тут свой подход в организации css. Кстати, похож на OPoR. Но свой вариант я вывел намного раньше чем узнал об OPoR, честно :)
У меня есть следующие понятия:
block, element, mod, state и js-*

Никаких лишних префиксов не нужно. Использую только .js-*, для навешивания js функционала, но это как отдельный слой. 
В частности тот же SASS позволяет избавиться от необходимости писать в HTML всякого рода дублирования вроде
class="block-element block-element_mod", а просто class="block-element_mod". Потому что всей компановкой занимается SASS и мне не нужно об этом задумываться вообще.
В SASS это выглядет примерно так:

.block {
    $root: &;
    some: css;
    &-element {
        some: css;
        &_mod {
            @extend #{$root}-element;
            some: css;
        }
        &.state {
            somestate: css;
        }
    }
}

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

Относительно состояний в моем понимании могут быть глобальные состояния, вроде .hide, .show и тому подобное, и некоторые индивидуальные специфические для какого-то рода компонентов. Тогда они описываются внутри этого компонента, как показано выше.

Так же в статье есть речь о том, что нужно под каждый компонент выделять свою ноду в html. В общем я с этим согласен. Кроме ситуаций с иконками. К ним я отношусь по разному, в большинстве случаев, я стараюсь вешать их на ПЭ, а не как отдельную ноду. Ну если уж другого выхода нет, то тогда это отдельная нода, хотя меня это невероятно бесит :)
Для иконок у меня есть отдельный компонент, например .icon. И чтобы добавить к чему-то иконку просто достаточно добавить .icon_iconame

<div class="block-element icon_iconame">Some Text</div>

Но так как в самом .icon описано самое базовое поведение конки, можно выполнить уточнения в следсивии слияния двух компонент.

.block {
    $root: &;
    some: css;
    &-element {
        some: css;
        &_mod {
            @extend #{$root}-element;
            some: css;
        }
        &.state {
            somestate: css;
        }
        &[class^="icon_"], &[class*=" icon_"] {
            somechange: forelem;
            &:before {
                somechange: foricons;
                change: size;
                some: color;
            }
        }
    }
}

Да это несколько нарушает понятие инкапсуляции, но все таки: "Сейчас к людям надо помягше. А на вопросы смотреть ширше." :)

Вот в общем-то мои мысли по поводу БЭМ, модульности и вообще подходу к css. Для меня это работает, вероятно для кого-то нет, по каким-то причинам. Но тут уж я ничего поделать не могу :)

  • Like 1
Link to post
Share on other sites
  • 0
40 минуты назад, alexriz сказал:

Никаких лишних префиксов не нужно.

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

  • Like 1
Link to post
Share on other sites
  • 0
2 минуты назад, wwt сказал:

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

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

  • Like 1
Link to post
Share on other sites
  • 0
18 час назад, alexriz сказал:

и писать нечто подобное .block--element__mod - это норм

Так это ересь какая то а не БЭМ )))

18 час назад, alexriz сказал:

В SASS это выглядет примерно так:

Хорошо, а в чём принципиальное отличие от БЭМ подхода, кроме неосмысленного именования (block)? И что мешает использовать модификатор d БЭМ, аналогичным образом ? Собственно &--mod  и &--state .

 

Link to post
Share on other sites
  • 0
55 минут назад, andrey7287 сказал:

Так это ересь какая то а не БЭМ )))

Ну открой соглашение по именованию в БЭМ и посмотри...
Модификатор элемента: .block-name__elem-name_mod-name
 

55 минут назад, andrey7287 сказал:

кроме неосмысленного именования (block)?

Неосмысленное именование. Это пример вообще-то :facepalmxd:

55 минут назад, andrey7287 сказал:

И что мешает использовать модификатор d БЭМ, аналогичным образом ? Собственно &--mod  и &--state .

ничего не мешает, в БЭМ так и есть да. Но это неудобно.

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

  • Like 1
Link to post
Share on other sites
  • 0
1 час назад, alexriz сказал:

Ну открой соглашение по именованию в БЭМ и посмотри...
Модификатор элемента: .block-name__elem-name_mod-name

Да, только модификатор сейчас через "--" делается, по этому приведённая запись и вызвала недоумение. 

2 часа назад, alexriz сказал:

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

Мне интересно. По сути у тебя тот же БЭМ, только в профиль. Хотя идеи возможно и полезные, возьму на заметку.

Link to post
Share on other sites
  • 0

Я согласен с этим утверждением на все сто. БЭМ дал главное - научил людей избавляться от мусорной свалки в CSS. А ещё я считаю, что все эти ваши SASS, SCSS и т.п. вместе с переменными должны умереть. Как только везде заюзают Web Components всё это станет ненужно. Вот тогда и наступит верстальческий рай :)

  • Like 2
Link to post
Share on other sites
  • 0
3 минуты назад, Great Rash сказал:

А ещё я считаю, что все эти ваши SASS, SCSS и т.п. вместе с переменными должны умереть.

Согласен. Я сам люблю css таким какой он есть. SASS начал использовать больше для внесения разнообразия в работу) Я его использую минимально, только то что позволяет компоновать селекторы в стак, где нужно. Мне об этом просто думать не нужно и тратить на это время. А большую часть того что предлагается, я не использую, по факту, просто нет надобности.

7 минут назад, Great Rash сказал:

БЭМ дал главное - научил людей избавляться от мусорной свалки в CSS.

только добавил свалки в html xD

  • Like 2
Link to post
Share on other sites
  • 0
55 минут назад, andrey7287 сказал:

Да, только модификатор сейчас через "--" делается, по этому приведённая запись и вызвала недоумение. 

модификатор ваще то через одно подчеркивае, а елемент либо __, либо --. Так в доках написано. А как кто делает это уже его личное дело.

  • Like 1
Link to post
Share on other sites
  • 0
1 час назад, alexriz сказал:

только добавил свалки в html xD

На самом деле нет. Просто надо уметь его готовить :) Товарищи из яндекса писали, что у них иногда по дню уходило просто на проектирование разметки (без написания кода). Т.е. наверное треть времени уходит на то чтобы просто понять как разбить макет на БЭМ-элементы.

Опять же БЭМ идеально подходит только для больших порталов где есть 100500 повторяющихся элементов с разными скинами.  Для лендингов БЕМ бесполезен чуть менее чем полностью.

  • Like 1
Link to post
Share on other sites
  • 0
9 минут назад, Great Rash сказал:

На самом деле нет. Просто надо уметь его готовить :)

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

<div class="block-name__elem-name block-name__elem-name_mod-name block-name__elem-name_mod-state">Some Text</div>

То есть прописать целых три класса вместо одного.
В итоге на выходе в коде получается какая-то нечитабельная помойка

  • Like 1
Link to post
Share on other sites
  • 0
21 минуты назад, alexriz сказал:

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


<div class="block-name__elem-name block-name__elem-name_mod-name block-name__elem-name_mod-state">Some Text</div>

То есть прописать целых три класса вместо одного.
В итоге на выходе в коде получается какая-то нечитабельная помойка

Ты так пишешь будто длинные названия классов - это что-то плохое. Ну и что, что их три? Главное ведь не длина атрибута class, а понятность чтения кода. Не понимаю чем это хуже той лапши на SASS, которую ты привёл в пример. Особенно забавно получается если приходится разбираться в таком коде, не имея исходников (был у меня такой случай).

UPD:

Дополню справедливости ради, что я тоже не в восторге от системы модификаторов, предложенной яндексом. Сам то я примерно так пишу:

<div class="block-name__elem-name _mod-1 _mod-2"></div>

философия БЭМ сохраняется, но код при этом читабельней. Однако это только потому, что ИЕ6 помер наконец. А ведь БЭМ придумывали ещё в эпоху актуальности ИЕ6, в котором (сюрприз-сюрприз) в CSS не работала запись такого вида:

.block-name__elem-name._mod-1 {
  /* ... */
}

Именно оттуда растут ноги такого длинного объявления модификаторов.

  • Like 2
Link to post
Share on other sites
  • 0
33 минуты назад, Great Rash сказал:

Ты так пишешь будто длинные названия классов - это что-то плохое. Ну и что, что их три? Главное ведь не длина атрибута class, а понятность чтения кода.

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

33 минуты назад, Great Rash сказал:

Не понимаю чем это хуже той лапши на SASS, которую ты привёл в пример. Особенно забавно получается если приходится разбираться в таком коде, не имея исходников (был у меня такой случай).

У меня как раз лапши и не получается, в html подобный пример я бы записал максимум так:

<div class="block-elem_mod state">Some Text</div>

Ничего лишнего, сразу понятно, что за элемент, к какому блоку относится, какую модификацию имеет, в каком состоянии находится.

.block {
   padding: 10px;
}
.block-elem,
.block-elem_mod {
    margin: 5px;
}
.block-elem_mod {
    color: #800;
}
.block-elem.state {
    background: #080;
}

Так примерно css будет выглядеть. .block-elem_mod стакается вместе с базовым block-elem, т.к. расширяется от него, дальше уточняется индивидуально mod версия. .state может быть как глобальным, так и индивидуальным, как в данном случае. 

Все вполне понятно.

На sass это вообще будет выглядить цельным блоком

.block {
    $root: &;
    padding: 10px;
    &-elem {
        margin: 5px;
        &_mod {
            @extend #{$root}-elem;
            color: #800;
        }
        &.state {
            background: #080;
        }
    }
}

На чем писать это уже выбор каждого (конечно на css)

33 минуты назад, Great Rash сказал:

Особенно забавно получается если приходится разбираться в таком коде, не имея исходников (был у меня такой случай).

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

  • Like 1
Link to post
Share on other sites
  • 0

Ну собственно твоя реализация ничем не отличается от классического БЭМ. Вопрос вкуса как писать модификаторы, через 2 подчёркивания или через одно. Например в твоей реализации элементов придётся в CSS использовать camel case, про который тоже куча народу скажет своё "фи". Так что вкусовщина всё это.

Почему в яндексе твой подход не прокатил бы я уже написал собственно.

  • Like 1
Link to post
Share on other sites
  • 0

Я очень часто замечаю, что многие фукают на БЭМ, но по сути используют его принципы в какой-либо интерпретации. 

БЭМ не умер и никуда не денется, даже после появления CSS Modules с его неймспейсами. Он позволяет писать css стили модульно и в этом его преимущество, особенно для внедрения в различные стеки по типу Angular 2 или React based архитектуры.

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

Edited by Svatov
  • Like 2
Link to post
Share on other sites
  • 0
15 минут назад, Svatov сказал:

БЭМ не умер и никуда не денется

Целый mdl на бэме. В гугле, вроде как не глупые ребята.

  • Like 1
Link to post
Share on other sites
  • 0
В 3/24/2016 в 15:09, Great Rash сказал:

Я согласен с этим утверждением на все сто. БЭМ дал главное - научил людей избавляться от мусорной свалки в CSS. А ещё я считаю, что все эти ваши SASS, SCSS и т.п. вместе с переменными должны умереть. Как только везде заюзают Web Components всё это станет ненужно. Вот тогда и наступит верстальческий рай

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

а) с одной стороны очень прохоже на то, что с приходом неймспейсов в css (css_modules/web_conponents) БЕМ станет не нужен

б) с другой, неймспейсы требуют javascript, без которого можно обойтись в ряде случаев

Link to post
Share on other sites
  • 0

JS есть абсолютно на любом современном сайте ибо он необходим как минимум для аналитики. Так что это фигня, пара лишних килобайт - не большая цена за удобство разработки.

Link to post
Share on other sites
  • 0
12 часа назад, Great Rash сказал:

JS есть абсолютно на любом современном сайте ибо он необходим как минимум для аналитики. Так что это фигня, пара лишних килобайт - не большая цена за удобство разработки.

даже разработчики браузеров уходят от практики "выключения js", к примеру в Firefox убрали из настроек отключение скриптов, оно осталось только через about:config,

Link to post
Share on other sites
  • 0

 

26.03.2016 в 12:33, Great Rash сказал:

JS есть абсолютно на любом современном сайте ибо он необходим как минимум для аналитики. Так что это фигня, пара лишних килобайт - не большая цена за удобство разработки.

Как минимум JS необходим, но для аналитики не обязателен, Можно чисто на PHP написать аналитику, которая даже время пребывания на странице будет показывать и ни какая метрика не нужна станет. 

Я вот большой не сторонник транспайлеров и препроцессоров(пусть сдохнет еще и TS с React и VUE). БЕМ мне начал нравится года два назад. Раньше я на OOCSS работал обычно, но на форуме даже ни одной темы. БЕМ реально хороший.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • 3 Опрос

    You do not have permission to vote in this poll, or see the poll results. Please sign in or register to vote in this poll.
  • Обсуждения

    • klierik
      Здравствуйте. Попробуйте начать с этого примера:
    • Bignoob
      Требуется сделать строку ввода в которые вписывается опреленная ссылка(любая) например:"https://htmlforum.org/forum/123"  Нужно, чтобы по нажатию кнопки в веденной ссылке менялась половина до опреденного домена типа org с того что было например на "https://123htmlsuper.ru/forum/123" . То есть не просто с org на ru, а полностью от https до слеша перед org Дальнейший вывод этой ссылки или кнопки для перехода на эту ссылку  Нужно это для сайта в "блокноте" html css Help
    • Czar_dmitriy
      Почему при адаптиве налазят блоки друг на друга?
    • Romario1985
      Как правильно сделать оформить header используя только html и css  чтобы получилась как на этом макете Почему у меня правое меню постоянно плавает и как кнопку поиска правильно спозиционирорвать в самой форме чтобы она никуда не уезжала? Что не так в моем коде? https://jsfiddle.net/kjgydnfs/27/
    • Romario1985
      Спасибо!!!     А почему в этом задании перезаписав значение  для псевдоэлемента after на то что ниже по коду, он перекрыл другой псевдоэлемент before, соответственно убрав половину видимой области этого псевдоэлемента. Почему, например, не before выше чтобы перекрыть after?
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. See more about our Guidelines and Privacy Policy