nerv

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

Рекомендованные сообщения

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
58 минут назад, nerv сказал:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, nerv сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
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/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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. Для меня это работает, вероятно для кого-то нет, по каким-то причинам. Но тут уж я ничего поделать не могу :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
40 минуты назад, alexriz сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 минуты назад, wwt сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
18 час назад, alexriz сказал:

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

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
55 минут назад, andrey7287 сказал:

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, alexriz сказал:

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
3 минуты назад, Great Rash сказал:

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
55 минут назад, andrey7287 сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, alexriz сказал:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
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>

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
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 {
  /* ... */
}

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
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 сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Изменено пользователем Svatov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
15 минут назад, Svatov сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 3/24/2016 в 15:09, Great Rash сказал:

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
12 часа назад, Great Rash сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

  • Похожие публикации

    • Автор: artaka
      Работаю верстальщиком за небольшую плату (100-300руб в зависимости от работы) Связь со мной : 
      VK vk.com/artakagrand
      Telegram @artakagrand
      email fefsert@gmail.com
      Примеры работ:
      http://teslamodelx.epizy.com
      http://teslamodelx.epizy.com/infoblog/index.html
      http://teslamodelx.epizy.com/blog/index.php
    • Автор: ZAMPOREZKE
      Оцените верстку и скажите, что не так.Заранее спасибо.
      https://zamporezke.github.io/
    • Автор: Fich71
      Здравствуйте.
      Есть абсолютно спозиционированный элемент, во всех браузерах при адаптации все ок(хром, фф, ие), но у заказчика на сафари этот элемент немного поехал.
       Вопрос: Можно ли сидя на винде как то протестировать вёрстку в сафари?(в актуальной версии браузера)
      И ещё: что за баг с позиционированием если хром и сафари на одном движке?
  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.