Использовать AMCSS чтобы не валить всё в class

[viT-1]

А вы пробовали для своей методологии воспользоваться AMCSS? Например в таком виде: .block[elem='mod'] и .block[mixelem='mod']

[tadatuta]

1. Не пробовали
2. В том виде, который приведен в примере это невозможно: у блока/элемента может быть бесконечное количество модификаторов и миксов. При этом у модификаторов могут быть собственные значения, а миксы могут быть как другими блоками, так и собственными элементами (или элементами других блоков) с произвольными модификаторами.
3. Если по какой-то причине (какой?) не подходят классы, всю историю про БЭМ, разумеется, можно выразить и с помощью атрибутов. Только зачем? ;)

[viT-1]

_2. В приведённом мной варианте блок можно рассматривать только как объединяющий элементы контекст, который как у вас написано в методологии "Имя блока задает пространство имен и обеспечивает уникальность имен элементов и модификаторов." Бесконечное количество модификаторов и миксов и в данном примере возможно, никто ведь не ограничивает вас количеством атрибутов и количеством значений атрибутов, просто все модификаторы элемента группируется в своём атрибуте.

_3. Для порядка ;)

[viT-1]

_3. CSS правила [атрибутов] гибче, чем просто классов.

[tadatuta]

@viT-1 Как вот такой пример будет выглядеть в AMCSS?

<div class="my-component my-component_type_normal my-component_size_l my-component_theme_islands some-other-component__elem1 yet-another-component__elem1 yet-another-component__elem2 yet-another-component__elem2_size_l yet-another-component__elem2_theme_cool yet-another-component__elem2_hovered">

[viT-1]

Я подумаю над вашим примером, а пока вот вам для раздумий: http://codepen.io/viT-1/pen/VjXybd PS: ищу работу ;)))

[viT-1]

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

[viT-1]

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

[tadatuta]

Блоки нужны лишь как ограничение namespace'ов

Нет, конечно. Множество блоков отлично работают сами по себе и вообще не имеют элементов и модификаторов.

Темы так вообще, я считаю, должны быть реализованы не модификаторами, а включением/выключением отдельных css-шкурок.

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

[viT-1]

При этом нет никакой проблемы на одной странице иметь одновременно один и тот же блок, отрисованный в разных темах.

Спорить о недостатках такого UX-решения не буду =) тем более что есть богатый опыт с текучкой дизайнеров, каждый из которых рисовал свой дизайн, а мы по очень большому проекту не успевали их внедрять целиком на всех страницах, из-за чего местами в нём был интерфейс с единовременной поддержкой нескольких шкурок сразу.

Множество блоков отлично работают сами по себе и вообще не имеют элементов и модификаторов.

Не понимаю чем отличается работа блоков самих по себе от работы тех же элементов самих по себе. У вас БЭМ головного мозга, мыслите шире.

[viT-1]

Отвечаю на ваш вопрос о том каким может быть вариант в виде AMCSS:

<div my-component="type_normal size_l theme_islands" some-other-component__elem1 yet-another-component__elem1 yet-another-component__elem2="size_l theme_cool hovered"></div>

Всяко больше порядка ;) и модификаторы можно теперь не громоздить, и даже использовать одинаковые.

[viT-1]

Я понимаю, что bemtools реализацию БЭМ'а через AMCSS пока не поддерживает и разработка станет в человекочасы и потому вы будете держаться за костыль длинных имён до последнего, но вы всё-же здраво обсудите данный реквест с коллегами ;) и как еванглеист, подумайте над удобством понимания БЭМа через AMCSS вне контекста потенциально потраченных человекочасов на реализацию...

[tadatuta]

@viT-1 В целом такой вариант вполне рабочий.

Про человекочасы:

1. На самом деле bem-tools тут вообще никаким боком не участвует, там тупо нет ничего про финальную HTML-разметку.
2. Мы давно позволяем задавать произвольный нейминг на уровне https://github.com/bem-sdk/bem-naming и явно про это пишем: https://ru.bem.info/methodology/naming-convention/#Альтернативные-схемы-именования
3. У нас за то, какой HTML рендерить, отвечают шаблоны и там заменить генерацию классов на генерацию атрибутов — это вопрос изменения пары строк (чуть больше работы потребуется со стороны клиентского JS, где, очевидно, гораздо удобно проверять наличие модификатора просто проверив его наличие в classList вместо парсинга и перебора атрибутов, но тоже, думаю, дифф уложится строк в 50).

Но на самом деле при использовании шаблонизатора HTML писать руками в принципе нет смысла. И тогда исходный вопрос теряет смысл:

Если хочется задать блок, то нужно писать про блок: { block: 'header' }, если у блока есть модификаторы, то нужно явно писать, что это модификаторы: { block: 'header', mods: { type: 'main' } }. Если к блоку примиксованы другие блоки, то нужно явно написать, что это миксы:

{
    block: 'header',
    mods: { type: 'main' },
    mix: [{ block: 'b2' }, { block: 'b3', elem: 'e1', elemMods: { some: 'thing' } }]
}

Вот как это работает: http://goo.gl/NBV9qC

И вот так header _type_main b2 b3__e1 это же можно представить в синтаксисе http://tadatuta.github.io/bem-indent-syntax/

Более чем в 6 раз короче, чем вариант на AMCSS. Круто, да? ;)

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

[viT-1]

В актуальном состоянии вы только документацию на английском поддерживаете, верно?

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

Исходный пример реализации БЭМа в AMCSS = IAMCSS обновил, загляните туда ещё разок, он весьма выразителен.

_3. Это не важно какая технология используется для рендеринга (XSLT или BEM-XJST), тред о конечном результате.

Писать руками всегда есть смысл, если вы хотите "сделать всех счастливыми", то есть распространить прежде всего саму методологию вёрстки, а не инструменты. В ваш БЭМ не входят в том числе и потому, что хотят разобраться как он работает в виде нативных технологий. Чёрного ящика обвязки (инструментов и прочего) изучающий методологию человек старается избежать (он знает на данный момент HTML и CSS), набрасывая примерчики вручную.

Более чем в 6 раз короче, чем вариант на AMCSS. Круто, да? ;)

Извините, но это в определённом смысле херня, да и не исключает bem-xjst рендеринга в AMCSS ;) Когда требуется именно сверстать, то используют HTML, а все эти обёртки технологий в определённой степени можно назвать синтаксическим сахаром, которым вы пытаетесь накормить, хотя и надо отметить, что это у вас получается (про MDL я в курсе). Впрочем, смотрите абзац выше.

[viT-1]

Добавлю. Когда вы апеллируете к BEM-XJST и BEM-JSON то вам сложнее поправить то что на выходе (а там как раз методология as is, а не ворох инструментов), вы пользуетесь высокими абстракциями и настолько срастаетесь с ними, что перестаёте воспринимать проблемы "в нижних слоях", ведь у вас "сверху" всё хорошо и красиво.

[tadatuta]

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

[qfox]

но многие именно из-за сложностей с пониманием неймспейсов и привычке верстать элементами в конечном счёте совершают много ошибок

Именно потому, что та реализация БЭМа, которую вы приводите в примерах, назовём её "базовой", неудачна по сути

Писать руками всегда есть смысл, если вы хотите "сделать всех счастливыми"

В ваш БЭМ не входят в том числе и потому, что хотят разобраться как он работает в виде нативных технологий

Когда вы апеллируете к BEM-XJST и BEM-JSON то вам сложнее поправить то что на выходе

Когда требуется именно сверстать, то используют HTML

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

Извините, но это в определённом смысле херня

Вот с языка сняли, сударь.

[qfox]

По-поводу темы: нет никаких проблем запилить движок, типа BEMHTML, для bem-xjst, который бы отрисовывал шаблоны из имеющихся библиотек (bem-core, bem-components, и других) по нужным вам правилам с атрибутами вместо классов.

css можно пересобрать автоматически с posthtml в файлы am.css или просто технологию (функцию/плагин/enb-технологию) сделать, которая будет конвертировать «базовые» селекторы в нужный вам вид.

Таким образом, вы не будете «в чужой монастырь со своим уставом» ходить, и получите то, что вам нужно.

Относительно самого подхода в AMCSS — может быть он и хорош, но цена переезда на него настолько высока, что сообщество не может себе этого позволить.

Ну и не надо забывать, что с методологической точки зрения способ размечения БЭМ-сущностей на DOM-нодах не так важен. Важен факт размечения, чтобы рантайм (i-bem.js) мог связать DOM-ноды и БЭМ-сущности между собой, и запустил процесс их инициализации. А будут ли там классы или атрибуты — дело десятое. И стоит ради этого переезжать на атрибуты? Очевидно, что это мартышкин труд, и делать его, даже платно, мало кому захочется.

[viT-1]

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

Аргументация была проста: https://github.com/bem/bem-method/issues/455#issuecomment-234283603 отсюда происходит вся путаница на "пороге вхождения" в БЭМ. Пример наглядный приведён, ссылка есть. Какие аргументы вам ещё нужны?

Таким образом, вы не будете «в чужой монастырь со своим уставом» ходить, и получите то, что вам нужно.

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

Относительно самого подхода в AMCSS — может быть он и хорош, но цена переезда на него настолько высока, что сообщество не может себе этого позволить. Очевидно, что это мартышкин труд, и делать его, даже платно, мало кому захочется.

Собственно это и есть основной ответ. Ну что же, оставайтесь с костылями (по рендерингу в классы HTML/CSS), которые к тому же ещё и плодятся: http://csswizardry.com/2014/05/grouping-related-classes-in-your-markup/

[qfox]

Аргументация была проста

Это заблуждение, а не аргумент. И уже был дан ответ: https://github.com/bem/bem-method/issues/455#issuecomment-234291778

Пример наглядный приведён

Субъективно лучше и не наглядно (я, например, честно пытался и ничего не понял).

Забавно, что вы предлагаете вылить на новичка ушат из стека технологий БЭМа, в котором он будет разбираться, чтобы построить простые примеры, дабы попробовать саму методологию на вкус (стоит ли ему её использовать).

Позвольте, если вы, говоря про новичка, имеете ввиду себя, то откуда у вас такое огромное желание со всем спорить? Изучите для начала причины эволюционного пути CSS, BEM, а потом уже предлагайте то, что с вашей точки зрения кажется лучше, и сразу аргументируйте: «Тезис такой-то в таком-то виде не является верным потому что то-то и то-то». Я вот привел ряд ваших заявлений, и они мало того, что не имеют ничего общего с действительностью, так еще и являются набросами на вентилятор. Что вы хотите добиться таким образом? Если всё-таки конструктива, то нужно срочно менять способ ведения дискуссии.

Ну что же, оставайтесь с костылями

Опять за своё ;-)

[viT-1]

Как же вы не хотите понять, что всех, кто приходит попробовать БЭМ, вы встречаете жуткой одёжкой html-атрибута class?!

Понятно, что дальше, если закрыть глаза на эту громаду "имён фэнтезийного короля", то можно дойти и до BEM-XJST и ощутить всю прелесть абстрагирования до уровня блоков. Но до использования стека БЭМ-технологий будет доходить лишь малый процент, и всё только оттого, что ложка БЭМа (BEMCSS) слишком горька, вкусное раздаёте только неделимым целым.

[viT-1]

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

Себя образца 2012-го года =) Опираясь на те воспоминания, сейчас переживаю за других верстальщиков. Нынче до БЭМа я дорос, но пожалуй пока что буду использовать лишь его методологию.

[qfox]

Как же вы не хотите понять, что всех

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

что ложка БЭМа (BEMCSS) слишком горька, вкусное раздаёте только неделимым целым.

Я готов помочь, но не готов делать сам.

[viT-1]

Изучите для начала...

Это вы зря так. Про проблемы с каскадом и т.п. я в курсе, на своей шкуре испытал.

[viT-1]

Кроме того, стили во всём мире принято вешать на классы — это ли не повод писать классы и навешивать на них стили?

2016-й год на дворе, CSS3, aria-атрибуты и прочие плюшки для современных браузеров.

[tadatuta]

2016-й год на дворе, CSS3, aria-атрибуты и прочие плюшки для современных браузеров.

Действительно, 2016 год на дворе, есть css-modules, а кто-то может себе позволить shadowDOM. Проблема скоупинга в CSS уже более-менее решена.

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

Если кто-то пишет разметку руками и использует БЭМ нейминг для обеспечения скоупинга — прекрасно, он может смело использовать AMCSS, хотя HTML в результате будет невалидным, а в CSS-селекторах потребуется чуть больше букв.

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

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

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

[viT-1]

хотя HTML в результате будет невалидным

data-атрибуты вроде как валидны, не?

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

Подумайте ещё...

В строку класса можно навертеть чего угодно, тогда как разделение на class, attribute, attribute value здорово ограничит верстальщика и уменьшит шанс выстрела в ногу.

Когда народ костылит в class способы группировки классов при помощи скобок, это уже означает, что то, что вы породили (и что народ старается причесать у себя в своих реализациях БЭМа) нуждается в принципиальном рефакторинге. В данном случае AMCSS предлагает эту группировку это раз. IAMCSS предлагает вешать стили на элементы и ни в коем случае не на блоки, что приводит к более стройным мыслям про неймспейсы и реализации накопленной привычки верстать элементами, а не блоками это два.

Элемент (атрибут), он всегда есть, даже в DOM'е, а вот блоки и модификаторы это уже абстракции, и могут отсутствовать (в примере выше такие css-правила присутствуют). Таким образом верстальщику проще перейти с его привычками на БЭМ, и он не будет ваять конструкции типа block1_block2_el1 и block1_el1_el2, и в миксинах будет придерживаться атомарности по классам. Соответственно и с наименованием классов разберётся и первый порог вхождения будет преодолён. Но если вам это совершенно неинтересно, поскольку дорого в реализации, то я вас понимаю... БЭМ останется уделом избранных.

[qfox]

Но если вам это совершенно неинтересно, поскольку дорого в реализации, то я вас понимаю... БЭМ останется уделом избранных.

Я до сих пор не могу понять, зачем сводить обсуждение к угрозам?

[viT-1]

Я до сих пор не могу понять, зачем сводить обсуждение к угрозам?

Извините. Видимо принимаю слишком близко к сердцу.

[tadatuta]

data-атрибуты вроде как валидны, не?

Да, то так будет не менее громоздко, чем с классами:

<div class="block1 block2__elem">

VS

<div data-block1 data-block2__elem>

БЭМ останется уделом избранных

БЭМ на том уровне, когда важно разобраться с неймингом, уже да-а-авно не удел избранных. Это легко проверить.

[viT-1]

Да, то так будет не менее громоздко, чем с классами

Вы почему-то забываете про группировку модификаторов, имена которых вместе с блоками просто очень громадны. И это при том, что ваш пример мы уже разбирали: https://github.com/bem/bem-method/issues/455#issuecomment-234301921

[viT-1]

БЭМ на том уровне, когда важно разобраться с неймингом, уже да-а-авно не удел избранных

Я некорректно выразился, извините. А мысль заключается вот в чём: разобравшись с неймингом народ либо переходит к стеку технологий и его всё это наше обсуждение не беспокоит уже по определению (это в основном те, кто в frontend перешёл из js-программистов), либо колется но продолжает есть кактус, выдумывая группировку классов в атрибуте class (это в основном те, кто в frontend пришёл из верстальщиков), либо разобравшись они (верстальщики) разворачиваются и уходят (на bootstrap и прочие свои велосипеды).

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

[tadatuta]

Вот такая разница на несколько вырожденном примере точно того стоит?

<div data-my-component="type_normal size_l theme_islands" data-some-other-component__elem1 data-yet-another-component__elem1 yet-another-component__elem2="size_l theme_cool hovered"></div>

VS

<div class="my-component my-component_type_normal my-component_size_l my-component_theme_islands some-other-component__elem1 yet-another-component__elem1 yet-another-component__elem2 yet-another-component__elem2_size_l yet-another-component__elem2_theme_cool yet-another-component__elem2_hovered">

Ну и за это придется заплатить тем, что вместо

.my-component {
    &_type_normal {}
    &_size_l {}
    &_theme_islands {}
}

.some-other-component__elem1 {}

.yet-another-component {
    &__elem1 {}
    &__elem2 {
        &_size_l {}
        &_theme_cool {}
        &_hovered {}
    }
}

Потребуется либо явно писать

[data-my-component~="type_normal"] {}
[data-my-component~="size_l"] {}
[data-my-component~="theme_islands"] {}
[data-some-other-component__elem1] {}
[data-yet-another-component__elem1] {}
[yet-another-component__elem2~="size_l"] {}
[yet-another-component__elem2~="theme_cool"] {}
[yet-another-component__elem2~="hovered"] {}

либо сочинять какой-то свой инструментарий.

[viT-1]

Зачем вы меня грузите проблемами реализации BEM-tools? ;) Для меня, якобы "новичка", это совсем тёмный лес, уйду я от вас ;)

[tadatuta]

они (верстальщики) разворачиваются и уходят (на bootstrap и прочие свои велосипеды)

Звучит примерно как «не хотят разбираться с паттернами проектирования и уходят на Wordpress и прочие свои велосипеды».

Да, действительно, подход к разработке (скажем, ООП) предполагает разработку, а не только использование готовых библиотек. Если кому-то сейчас хватает кнопочек из Бутстрапа, значит, он столкнется с потребностью в чем-то более универсальном на следующем проекте.

Зачем вы меня грузите проблемами реализации BEM-tools?

Я же уже писал выше, что bem-tools здесь вообще никаким боком. То, что я написал — это про любой CSS-препроцессор и тут уж точно не про избранных речь ;)

[viT-1]

То, что я написал — это про любой CSS-препроцессор и тут уж точно не про избранных речь ;)

Сорри, в пылу жаркого разговора не распознал сразу. Без использования препроцессоров нынче действительно никуда. Это всё же проигрышная позиция отстаивать удобство вхождения в БЭМ вёрстку на уровне порога "байт-кода" (просмотра исходного кода страниц на сайтах внедривших БЭМ, и прочих примеров, там ведь не препроцессорный код).

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

[viT-1]

[data-some-other-componentelem1] [yet-another-componentelem2~="theme_cool"]

в IAMCSS чуть по другому .data-some-other-component[elem1] и .yet-another-component[elem2~="theme_cool"]

[tadatuta]

в IAMCSS чуть по другому

И вот когда такое счастье оказалось на одном DOM-узле, как из JS определить, что elem1 относится к блоку data-some-other-component, а elem2 — к yet-another-component?

[viT-1]

как из JS определить

А какую практическую задачу вы решаете? Зачем вам нужно определять принадлежность атрибутов к конкретному блоку/интерфейсу? Инициализируете абстракцию блока автоматически и собираете до кучи все его свойства, вдруг пригодятся?

Ваш вопрос и мой ответ напоминает анекдот про пьяного мужа вернувшегося домой поздно - "... ты же умная, придумай что-нибудь сама" =)

В JS структуру блока вы например можете декларировать JSON'ом, и никто не запретит вам использовать одни и те же атрибуты для разных интерфейсов (активно пользуетесь mixin'ами - значит понимаете что делаете). Проведите аналогию с множественным наследованием.

На Яндекс субботнике 2012-го года https://events.yandex.ru/lib/talks/327/ на 18-й минуте я задавал вопрос про то, как вы определяете иерархию родительских блоков, и был дан ответ, что в BEMе для этого используется декларативный конфиг. Не сомневаюсь, что и здесь для каждого блока информацию об используемых им атрибутах вы можете подобным образом задекларировать.

[tadatuta]

Ага, удобно будет ;)

[viT-1]

Не пойму вас. Сарказм?

Вы придираетесь только к количеству символов, я же помимо этого пытаюсь донести мысль о том, что

по IAMCSS, (который в данном случае лишь нижний порог вхождения или "байт-код") чёткая связь блока как нэймспейса чьё имя декларируется в атрибуте class (и повторяется для каждого элемента блока), элемент блока как пользовательский data-атрибут и модификатор как значение этого data-атрибута, упорядочит решения о том, как должен называться вложенный блок, где ставить модификатор к блоку или к элементу и т. п. Что даст возможность новичку легче переступить первый порог вхождения: https://github.com/bem/bem-forum-content-ru/issues/1090#issuecomment-238287104

[belozer]

@viT-1 Немного вмешаюсь в дискусс.

Прочитал весь топик... Всё крутится "за" и "против". Я тоже был новичком и тоже использовал разные подходы, чтобы облегчить жизнь.

Теперь мои аргументы на зацепившие меня высказывания.

Добавлю. Когда вы апеллируете к BEM-XJST и BEM-JSON то вам сложнее поправить то что на выходе (а там как раз методология as is, а не ворох инструментов), вы пользуетесь высокими абстракциями и настолько срастаетесь с ними, что перестаёте воспринимать проблемы "в нижних слоях", ведь у вас "сверху" всё хорошо и красиво.

А минификацией JS или CSS ты занимаешься (с BEM или без BEM, без разницы)? Хоть раз ты правил эти файлы? Там вопросов не возникает. Ты знаешь, что ты написал. И тебе по-барабану как оно дальше выглядит. Надо что-то править - правят исходники.

По поводу примеров с IAMCSS - они ужасны, прошу прощения за резкость.

Когда я начинал знакомство с BEM использовал следующую нотацию

в HTML

<div class="block --mod--val --mod2--val">

в CSS

.block.--mod--val {}
.block.--mod2--val {}

дабы избегать длинных классов. Не помню как такая нотация называется (shorts syntax BEM или как-то иначе), не я её выдумал.

но в конечном итоге перешёл на классический BEM.

До изучения BEM

Выбор делал между несколькими методологиями

• MCSS
• BEM
• SMACSS

Все они (кроме BEM) вносили путаницу в мою голову о реализации, о том как нужно писать CSS. BEM был понятен и прозрачен в этом вопросе.

На то, чтобы начать писать (а не пробовать) CSS и HTML по BEM у меня ушло около недели. И с того времени я больше ничего не использую, т.к. BEM решил мои проблемы на ~95%.

Я был 0 в BEM и смог его использовать уже через неделю (или меньше, точно не помню).

После изучения BEM

Я писал простые классы (состоящие из 1-4 селекторов). Основная проблема которая возникла потом, это не проблема "методологии"... А проблема внедрения "платформы". Я очень хотел сделать процесс разработки ещё проще. Мне нравилась платформа, но вот гайдов по внедрению полный нуль. Только какие-то обрывки на форуме. В итоге это и есть основная проблема.

Ответ получился длинный, но думаю содержательный.

П.Н.

BEM вертят как хотят, но есть хорошая база (платформа). Нужно просто показать как эту базу внедрять в проекты и ВСЁ.

[viT-1]

На всякий случай оставлю это здесь: пример перевода кода с BEM на IAMCSS - ревизии https://github.com/viT-1/larinayoga/commit/3e8194ff8ec55c79b74871185ea8b16e9ce3cfa5, https://github.com/viT-1/larinayoga/commit/3e1d0e124eb128201c0713007937baef79627ce8, https://github.com/viT-1/larinayoga/commit/83e8f825cc4056eec9028023fcbdacd04b0dbb5b, https://github.com/viT-1/larinayoga/commit/a7f60bc9333a1645acb7463f97849231715576f5 и https://github.com/viT-1/larinayoga/commit/265c7dda704bc21652aaaf077a10be6790380d78

[tadatuta]

Я бы не утверждал, что там до этого был БЭМ ;)

* {
    -moz-box-sizing: border-box;  
    -webkit-box-sizing: border-box;
    box-sizing: border-box;
}

body {
    text-align: center;
    margin: 0;
    padding: 0;
}

a img {
    border-style: none;
    display: inline-block;
}

menu
, menu li {
    list-style: none;
    display: block;
    margin: 0;
    padding: 0;
}

ul
, ol {
    margin: 0;
    padding: 0 0 1em 15px;
}

[viT-1]

Это что-то типа reset.css, странно что вы к этому придрались, наверное кроме БЭМа уже всё позабыли или даже и не знали.

Код касающийся БЭМа указан в ревизиях (см. изменения). Сразу буду переводить на IAMCSS. Внедряю его и это отделение класса iBlock таким образом, что прямо на него нельзя вешать селекторы мне очень нравится! Плюс необязательно заводить свои элементы/атрибуты, в некоторых случаях можно воспользоваться и существующими (как в iAnchor).

[viT-1]

Ещё нравится то, по IAMCSS нету модификаторов блока типа iBlock-mod, поскольку модификатор по сути относится к элементу, а не блоку. Например https://github.com/viT-1/larinayoga/commit/83e8f825cc4056eec9028023fcbdacd04b0dbb5b .iGallery-thumb120px .iGallery_thumb сменился на .iGallery[thumb = 'h120px']

[viT-1]

При переводе на IAMCSS обнаружил баг IE8: сложные селекторы перечисленные через запятую он не обрабатывает! (base.css https://github.com/viT-1/larinayoga/commit/265c7dda704bc21652aaaf077a10be6790380d78#diff-7e524e0d055c017b2f549b72c2e87879) CSS-минимайзеры могут сыграть злую шутку.

[viT-1]

@belozyorcev А вам отвечу, что решение из коробки это всегда удобно.

В контексте же данного топика идёт речь в том числе и о том, чтобы БЭМ'овцы смогли увидеть развитие своей методологии (следующую версию коробки для вас): вместо мешанины блок-элемент с нэймспейсом, строже отделяли неймспейс и фокусировались на элементе с модификатором (чему и следует IAMCSS).