Отличие микса от модификатора в данном примере BEM?

Vann Damm, нет, это тоже ошибочное суждение — обёртки, если использовать БЭМ, тоже становятся не нужны: https://github.com/bem-site/bem-forum-content-ru/i...

Про БЭМ лучше читайте на официальном сайте: bem.info, а если будет что-то непонятно — у нас есть канал в Телеграме и форум.

IE11 не видит классы начинающиеся с "--". Как исправить?

profesor08, c БЕМ — да, но тут речь про БЭМ: https://ru.bem.info/methodology/naming-convention/

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

r_g_b_a,

1) Да, всё верно — держать в голове или научить сборщик. БЭМ не даст ответ на этот вопрос.

3) Тут тоже нет однозначного ответа. Если представление компонента зависит от ширины родительского блока, то это выходит за понимание методологии — придётся использовать или CSS Container (Element) Query, или соответсвующие модификаторы.

P. S. Как любят говорить БЭМ-евангелисты: «Руководствуйтесь здравым смыслом» — БЭМ помогает напоминать о том, что полезно задумываться о том, какие CSS-свойства откуда проистекают, но best-practices не так много, потому что некоторые решения довольно специфичны. По себе могу сказать, наверное, только то, что это (в большей степени) приходит с опытом (за последние пару лет вёрстки я не встречал каких-то новых паттернов, кроме заведомо абсурдных).

Как правильно указывать пути для уровней - levels в БЭМ?

avprinciple, А, это… Пардон, да, ты прав. bem create создаст их автоматически:

bem create test__element.{bemtree, deps}.js -l src/blocks/modules/common

создаст test__element.bemtree.js и test__element.deps.js в каталоге src/blocks/modules/common/test/__element.

Как правильно указывать пути для уровней - levels в БЭМ?

avprinciple,

А в levels мы просто описываем какие технологии и т. п. нужно в той или иной папке создавать?

— Да, но bem create умеет выделять технологии из расширения файлов, например:

bem create test.{bemtree, deps}.js -l src/blocks/modules/common

создаст два файла: test.bemtree.js и test.deps.js в указанном каталоге по шаблону, не смотря на то, что написано в .bemrc. Я, собственно, именно этот способ всегда и использую, не полагаясь на конфигурацию по умолчанию.

как подружиться с двойным подчёркиванием?

— Вот тут не понял. По методологии названия сущностей (файлов, каталогов) не может начинаться с __.

Как правильно указывать пути для уровней - levels в БЭМ?

avprinciple, не, не получилось. Но как минимум я всегда использовал автокомплит по Tab для построения пути, так что особого труда не вызывало ¯\_(ツ)_/¯

Как правильно указывать пути для уровней - levels в БЭМ?

avprinciple, наверное, с помощью стандартных алиасов. Сам так не делал, сейчас попробую…

Как правильно указывать пути для уровней - levels в БЭМ?

level1 должен быть путём до этого уровня, т. е. тогда должно быть так: bem create anyBlock -l src/blocks/modules/common.

Как в bem-create создавать файлы?

Я же написал: «в корне проекта», т. е. в том же каталоге, где лежат все файлы проекта создать (если ещё нет) файл .bemrc по аналогии и указать в нём уровни и их структуру (flat/nested).

Правильно ли сверстано по БЭМ?

HunteR-VRX,
— Нет. Как я уже сказал, это лишь вопрос привычки. По умолчанию (как было всегда), для разделения модификаторов используется одиночное нижнее подчёркивание, а дефис как разделитель для модификаторов во-первых используется не один, во-вторых, эта схема имеет больше недостатков, чем даже camelCase (т. к. популяризировавший эту схему Гарри Робертс не дочитал документацию до конца и так и не узнал, что модификаторы записываются в формате «ключ-значение»).

Правильно ли сверстано по БЭМ?

@HunteR-VRX

то лучше прибегнуть к camelCase

— это не «лучше», а лишь один из вариантов, „вкусовщина“: https://ru.bem.info/methodology/naming-convention/...

Как вы в БЭМе используете повторяющиеся текстовые элементы?

Максим, если вы не можете гарантировать порядок подключения классов в CSS, то почему сразу костыль? Каскадность — это ключевая парадигма CSS, вопрос в том, умеете ли вы её контролировать (и как вы это делаете). В БЭМ-стеке этой проблемы не возникает — там каждый блок/элемент «знает», какие стили ему нужно (если нужно) перекрыть, поэтому он подключается позже (при этом сохраняя специфичность на уровне «плоской» вложенности).

Почему даже создатели БЭМа используют в своих проектах Atomic CSS, если большинство его ругает?

Максим, видимо, ничего лучше в тот момент не придумали, а сроки поджимали. Как правило при рефакторинге это решается, попутно группируя повторяющиеся свойства в новые классы.

Как вы в БЭМе используете повторяющиеся текстовые элементы?

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

Почему даже создатели БЭМа используют в своих проектах Atomic CSS, если большинство его ругает?

Максим, это просто совпадение. Смысл БЭМ не в том, чтобы у класса было много свойств, а в том, чтобы класс содержал как можно больше характеризующих его название свойств, не противоречащих другим состояниям (потому что они выносятся в модификаторы). Atomic никак не характеризует отношение вложенности и зависимости, в БЭМ для этого есть такое понятие как Элементы.Сверстав два блока с одинаковой разметкой, но разным внешним видом, Atomic-верстальщик никогда не поймёт, почему у них разный набор классов. А БЭМ-верстальщику потребуется пол-секунды, чтобы увидеть, что у обного блока block_theme_light и block_size_large, а у другого — block_theme_dark и block_size_small. Третий блок он скомбинирует, просто поменяв значение модификатора, а не будет колдовать с россыпью Atomic-классов.

Почему даже создатели БЭМа используют в своих проектах Atomic CSS, если большинство его ругает?

1) В вашем примере из вопроса — БЭМ.
2) В вашем примере из вопроса — не Atomic, Alex продемонстрировал пример ACSS.
3) БЭМ не запрещает, БЭМ рекомендует не использовать в модификаторах явные значения, потому что если, в модификаторе text_color_black изменится цвет (например, на серый), но изменить придётся не только свойство, но и разметку (переписать класс в разметке).
4) CSS-tricks знает про БЭМ не больше вашего («благодаря» Гарри Робертсу, который популяризировал БЭМ, прочитав документацию до половины, поэтому был вынужден придумать бесполезную адаптацию, потому что то, что он прочитал, не хватило для понимания основной идеи).
5) Это БЭМ, повторюсь, хоть в Яндексе БЭМ используется не повсеместно, некоторые подразделения категорически против этой методологии.
6) Судя по первому коммиту, Atomic появился на 8 лет позже БЭМ, поэтому БЭМ просто не может что-то заимствовать, скорее наоборот. Atomic пытается решить ту же проблему cascading hell, просто менее декларативно.

Как правильно изменять дочерний блок при наведении на блок-родитель в БЭМ?

Muvka,

.button {
  color: #123 !important;
}

.block:hover .block__button {
  color: #456;  /* не будет иметь эффекта */
}

Как правильно изменять дочерний блок при наведении на блок-родитель в БЭМ?

Не, вполне правильно. Точнее, это оптимальный способ. Нужно лишь быть уверенным, что специфичность изменяемого свойства .block:hover .block__button выше, чем у .button.

Правильно ли сверстано по БЭМ?

lamer350, не знаю, поможет ли, но цель доклада была именно такая — как упростить «дробление» на блоки-элементы-модификаторы: https://youtu.be/QArmhI33zwY?t=6669 (начало с 1:51)

В методологии БЭМ можно делать два класса?

А где вы узнали про БЭМ (вопрос без подвоха или издёвки)? Потому что в официальной документации это более-менее понятно расписано: https://ru.bem.info/methodology/quick-start/#%D0%B...