Comments 32
UFO just landed and posted this here
Ни Яндекс, ни команда БЭМ не навязывают методологию, они делятся тем, что существенно упростило им жизнь.
Тому подтверждение, ставшая популярной на западе нотация именования классов с отделением модификатора через два минуса. Это просто подхватили, оно самостоятельно живёт, развивается и наносит пользу. Иначе бы этим не пользовались.
Тому подтверждение, ставшая популярной на западе нотация именования классов с отделением модификатора через два минуса. Это просто подхватили, оно самостоятельно живёт, развивается и наносит пользу. Иначе бы этим не пользовались.
Да, действительно. Возможно, все мы (Яндекс, Mail.ru, Google, Альфабанк, Adobe, Мегафон и еще много крупных компаний, которые используют БЭМ) ошибаемся, и никакой пользы от БЭМа никто никгда не видел :)
UFO just landed and posted this here
«Пастернака не читал, но осуждаю»?
Минута поиска приводит к такой вот ссылке http://www.getmdl.io/faq/index.html#css-naming-conventions
Минута поиска приводит к такой вот ссылке http://www.getmdl.io/faq/index.html#css-naming-conventions
Из последнего, кстати playbook.cio.gov/designstandards/getting-started
US Government recommends BEM too ;)
US Government recommends BEM too ;)
Пока яндекс не стал вкладываться в продвижение бэма это считалось плохими практиками, хорошим стилем было использование каскадных стилей и семантической разметки с классами не завязаными на расположении или цвете элемента. Я всегда знаю, что список будь то меню или пагинатор имеет одинакову разметку, отличаясь лишь контейнером и мне не искать какой класс прописывать, один и тот же шаблон можно использовать в разных проектах, а верстальщик всё изменит с помошью стилей, не меняя самой разметки.
А вот это ад, который могут себе позволить только большие бюрократезированные компании из вашего списка
А вот это ад, который могут себе позволить только большие бюрократезированные компании из вашего списка
<header class="demo-header mdl-layout__header mdl-color--white mdl-color--grey-100 mdl-color-text--grey-600">
вместо
<header class="demo">
Открыл я amdy.su, присмотрелся — и действительно.
На первом DOM-узле 42 класса (да-да, modernizr же), на body — айдишник и еще 3 класса (конечно, это все WordPress). Cтраница делает 25 запросов за JS-файлами.
Бедные разработчики из больших бюрократизированных компаний, конечно, не могут себе позволить таких простых человеческих радостей ;)
Но вот БЭМ вполне себе используют ребята-фрилансеры. Ну или вот немного результатов из англоязычного мира.
На первом DOM-узле 42 класса (да-да, modernizr же), на body — айдишник и еще 3 класса (конечно, это все WordPress). Cтраница делает 25 запросов за JS-файлами.
Бедные разработчики из больших бюрократизированных компаний, конечно, не могут себе позволить таких простых человеческих радостей ;)
Но вот БЭМ вполне себе используют ребята-фрилансеры. Ну или вот немного результатов из англоязычного мира.
Вот, вордпресовский шаблок как раз демонстрирует во что превращается разметка, когда не используешь возможности css, а придумываешь 100500 класов. Помимо кучи лишних классов, они ещё и глобально прописаны. Тоже полный БЭМ, можно было обойтись просто заметой стилей для стандартной разметки и без модернайзеров. Но и на том авторам спасибо, читать удобно.
Не вижу ничего супер удобного в стилях, основанных на куче вложенных селекторов, когда стиль зависит от структуры документа. Мало того, что это медленней для страниц с большим количеством элементов, так еще и создает проблемы с переиспользованием в более-менее крупных проектах из-за того что стили одних блоков зависят от других.
Так не надо использовать глобальные стили, есть блок-контейнер, внутри него стили, которые не лезут за пределы контейнера. Ну а с less-ом всё становится вообще прекрасно. Ну а скорость селекторов — это даже не смешно с современными мощностями даже в дешёвых смартфонах.
Причем тут глобальные стили? Грубый пример — есть кнопка, которая на странице A зеленая, если родительский элемент — div, и красная, если родительский элемент — span. Если я захочу сделать такую же _красную_ кнопку на странице Б в table, то мне либо придется следовать изначальной структуре (помещать ее в span), либо дублировать код стилей. С БЭМ у меня есть конкретный модификатор, который будет работать хоть в div, хоть в span, хоть в table. Насчет скорости — не вижу ничего смешного в том чтобы терять даже 500-100ms на ровном месте.
Также не буду говорить насчет того, что с тем же SASS можно удобно делать запись БЭМ-селекторов.
Также не буду говорить насчет того, что с тем же SASS можно удобно делать запись БЭМ-селекторов.
В том то и дело, что это абсолютно другая кнопка в другом блоке, которая покуда что выглядит так же. Потому ты просто пользуешься миксином или импортом, в дальнейшем миксин можно будет либо параметризовать, либо переписать, если вид кнопок разойдётся. При этом все изменения на уровне стилей в less не затрагивая класы в шаблоне.
Вот у нас проект с богатым клиентом на angular, логика отображения прописана во вьёхе и дерективах, она замешена на разметке и класах, а тут плюх кнопку решили сделать синей и меняют класс btn-color-red на btn-color-blue -color-text--green-600, валится директива, валятся тесты, верстальщик лезет в шаблоны и дай бог там ничего больше не заденет. И это я не теоретизирую, разве что немного гиперболизирую, но сталкивался на практике, активная реклама БЭМа яндексом делает своё чёрное дело.
Вот у нас проект с богатым клиентом на angular, логика отображения прописана во вьёхе и дерективах, она замешена на разметке и класах, а тут плюх кнопку решили сделать синей и меняют класс btn-color-red на btn-color-blue -color-text--green-600, валится директива, валятся тесты, верстальщик лезет в шаблоны и дай бог там ничего больше не заденет. И это я не теоретизирую, разве что немного гиперболизирую, но сталкивался на практике, активная реклама БЭМа яндексом делает своё чёрное дело.
Нет, это не абсолютно другая кнопка, это абсолютно та же кнопка. И вместо кнопки может быть целый независимый блок. И я не хочу писать в нескольких местах стили для одного и того же блока.
Насчет завязывания логики на классах — я бы вообще не рекомендовал завязывать поведение на модификаторах, которые обозначают свойства вроде цвета или размера. Кроме того если разрабатывать с использованием инструментов, которые предоставляет Яндекс, то там прямо в документации говорится, что нельзя вот так брать и напрямую менять модификатор на DOM-ноде.
Насчет завязывания логики на классах — я бы вообще не рекомендовал завязывать поведение на модификаторах, которые обозначают свойства вроде цвета или размера. Кроме того если разрабатывать с использованием инструментов, которые предоставляет Яндекс, то там прямо в документации говорится, что нельзя вот так брать и напрямую менять модификатор на DOM-ноде.
Если та же, так в чём проблема? Делайте её независимой от родительского блока, БЭМ же использует тот же CSS, только без фичи каскадности.
А по поводу модификаторов — отличная шутка, отказаться от ангуляра в пользу решения яндекса из-за загонов верстальщика.
А по поводу модификаторов — отличная шутка, отказаться от ангуляра в пользу решения яндекса из-за загонов верстальщика.
Так это не я, а вы предлагаете использовать вместо модификаторов каскады из вложенных селекторов (которые по вашему мнению удобнее) для модификации свойств. У меня то нет проблем.
Я говорю не о том, чтобы отказаться от ангуляра, а о том, что не надо бездумно менять классы в HTML-коде, даже не проверяя, что на них завязано в js, а потом удивляться, почему все сломалось. И просто привел ссылку, что на этот счет говорит официальная документация.
Я говорю не о том, чтобы отказаться от ангуляра, а о том, что не надо бездумно менять классы в HTML-коде, даже не проверяя, что на них завязано в js, а потом удивляться, почему все сломалось. И просто привел ссылку, что на этот счет говорит официальная документация.
Они не лезут вовне контейнера, но лезут внутрь, во вложенные контейнеры. Вы же можете использовать вложенные блоки (если использовать терминологию БЭМ). А что, если внутри этих блоков используются элементы с одинаковыми именами классов? Тогда CSS, примененный к элементу внешнего блока, будет влиять на элементы внутреннего блока, и вам придется бороться с этими стилями. Как вариант — использовать “>” в селекторе. Но тогда встает следующая проблема — если структура блока достаточно сложная, то вам придется использовать умопомрачительные конструкции типа > div > div > div > .element. Селекторы превращаются в жуть, и вы также завязываетесь на структуру блока. Модификация структуры блока будет означать необходимость внимательного и порой напряженного отслеживания отражения этой структуры в CSS.
С другой стороны, использование именования по БЭМ позволяет решить вышеописанную проблему изящным способом. У вас нет жуткой многоэтажной структуры селекторов, элементы вложенных блоков не влияют друг на друга, и бонусом — вы сразу видите, к какому блоку принадлежит данный элемент, когда, например, инспектируете страницу. А еще бонусом — ускорение рендеринга страницы (не нужно недооценивать — в некоторых сложных верстках весьма ощутимое).
Единственное, с чем я могу согласиться, что именование БЭМ выглядит довольно пугающе. Я решил лично для себя эту проблему тем, что именую блоки, элементы и модификаторы по-своему. Например:
Menu — блок;
Menu-item — элемент блока;
Menu--fixed — модификатор.
Я не использую bem-tools, а пишу код традиционно, поэтому для меня читабельные имена классов очень важны. И я пришел к такому компромиссу. Ну и в некоторых случаях действительно красивее и правильнее будет использовать просто вложенные селекторы — типа ul > li, table td и т.д., т.к. они не нуждаются в дополнительном именовании. Например, задавая типографику внутри контента статьи, да и порой в других случаях. Тут нужно смотреть по ситуации, без фанатизма.
Главное — понять, какие проблемы решает БЭМ и взять полезное из его методологии. Не нужно считать популярность БЭМа исключительно следствием продвижения его Яндексом и недооценивать сознательность использующих его разработчиков.
С другой стороны, использование именования по БЭМ позволяет решить вышеописанную проблему изящным способом. У вас нет жуткой многоэтажной структуры селекторов, элементы вложенных блоков не влияют друг на друга, и бонусом — вы сразу видите, к какому блоку принадлежит данный элемент, когда, например, инспектируете страницу. А еще бонусом — ускорение рендеринга страницы (не нужно недооценивать — в некоторых сложных верстках весьма ощутимое).
Единственное, с чем я могу согласиться, что именование БЭМ выглядит довольно пугающе. Я решил лично для себя эту проблему тем, что именую блоки, элементы и модификаторы по-своему. Например:
Menu — блок;
Menu-item — элемент блока;
Menu--fixed — модификатор.
Я не использую bem-tools, а пишу код традиционно, поэтому для меня читабельные имена классов очень важны. И я пришел к такому компромиссу. Ну и в некоторых случаях действительно красивее и правильнее будет использовать просто вложенные селекторы — типа ul > li, table td и т.д., т.к. они не нуждаются в дополнительном именовании. Например, задавая типографику внутри контента статьи, да и порой в других случаях. Тут нужно смотреть по ситуации, без фанатизма.
Главное — понять, какие проблемы решает БЭМ и взять полезное из его методологии. Не нужно считать популярность БЭМа исключительно следствием продвижения его Яндексом и недооценивать сознательность использующих его разработчиков.
Извините, но у вас не БЭМ. Вот можете ознакомится с выступлением по поводу такого же подхода youtu.be/kBgHdSOj33A
Посмотрел видео. Не понял, почему у меня не БЭМ. Буду вам благодарен, если вы будете более конкретны.
По поводу других вариантов именования блоков, элементов и модификаторов:
ru.bem.info/method/naming-convention/#Альтернативные-схемы-именования
Если вы про момент «ul > li, table td» — я также где-то в документации об этом читал, что в некоторых случаях это допустимо. Сейчас не могу найти. Если мне это вдруг показалось, поправьте меня. Или вы меня просто неправильно поняли? Смысл в том, что если я создаю блок-таблицу, в которой — я точно знаю — никаких других вложенных таблиц использоваться не будет, то будет избыточно навешивать на каждый tr и td дополнительный класс элемента, т.к. эти узлы уже связаны с родительским узлом, уже сами по себе семантичны, дополнительной семантики навешиванием класса не требуется. Возможно, это не суперстрого по суперстрогому БЭМ, но вполне допустимо при ручном применении БЭМ, о чем и была речь.
О типографике внутри блока докладчик также упоминает. Так в чем же не БЭМ?
По поводу других вариантов именования блоков, элементов и модификаторов:
ru.bem.info/method/naming-convention/#Альтернативные-схемы-именования
Если вы про момент «ul > li, table td» — я также где-то в документации об этом читал, что в некоторых случаях это допустимо. Сейчас не могу найти. Если мне это вдруг показалось, поправьте меня. Или вы меня просто неправильно поняли? Смысл в том, что если я создаю блок-таблицу, в которой — я точно знаю — никаких других вложенных таблиц использоваться не будет, то будет избыточно навешивать на каждый tr и td дополнительный класс элемента, т.к. эти узлы уже связаны с родительским узлом, уже сами по себе семантичны, дополнительной семантики навешиванием класса не требуется. Возможно, это не суперстрого по суперстрогому БЭМ, но вполне допустимо при ручном применении БЭМ, о чем и была речь.
О типографике внутри блока докладчик также упоминает. Так в чем же не БЭМ?
RSCSS посмотрите — тот же БЭМ по сути, но с сохранением семантики и без километровых имен классов.
Давайте всё же различать БЭМ как нотацию css-классов и БЭМ как фреймворк всего и вся. Второе нигде кроме Яндекса не используется, за редкими исключениями. Первое — используется наряду с другими нотациями много где.
>> Разве к настоящему моменту ещё не стало ясно, что оно мертворожденное?
Очень много старых верстальщиков (те что IE6 были вынужденны поддерживать) именовали классы таким же способом. Не так жестко, конечно, но все же. Вообще, додуматься до class=«list__item -mod» не надо большого ума. Если много верстаешь, то скоро приходит понимание, что копировать стили плохо и переопределать их, тот еще гемморой.
Очень много старых верстальщиков (те что IE6 были вынужденны поддерживать) именовали классы таким же способом. Не так жестко, конечно, но все же. Вообще, додуматься до class=«list__item -mod» не надо большого ума. Если много верстаешь, то скоро приходит понимание, что копировать стили плохо и переопределать их, тот еще гемморой.
Очень напоминает Ext.JS…
Расскажите подробнее о том моменте, когда вы решили изменить подход. Решение инициировал руководитель проекта? Были ли несогласные с тем, что нужно что-то коренным образом изменить подход?
Спасибо за БЭМ! Всегда следовал, не гласно, этим правилам. Хорошая практика.
Использовать адаптивную верстку не рекомендуется
Но почему?
Можно сформулировать так: если хватает ресурсов на разработку и поддержку двух специализированных версий, то, думаю, очевидно, что такие версии будут работать эффективнее. Если же ресурсов нет, то адаптивная версия, конечно, имеет право на существование.
Хотя есть и радикальные точки зрения.
Хотя есть и радикальные точки зрения.
Не использовать адаптив в смысле разделять адаптив и не адаптив и по сути поддерживать две ветки? Чем плох адаптив того же bootstrap?
Sign up to leave a comment.
19 принципов разработки по БЭМ, или что должен знать каждый разработчик библиотек