button--positive, button--negative и button--neutral
В данном случае использовать булевы модификаторы плохо, потому что это даёт возможность добавить блоку все три эти модификатора одновременно.
Тут лучше использовать модификатор ключ-значение, потому что фактически может быть только один из этих модификаторов у конкретной кнопки, т.е. кнопка может быть или positive, или negative, или neutral.
Рассматривайте это как аналог атрибута type у input. Значение конкретного типа определяет каким именно будет этот input. Тут логика точно такая же.
Вёрстку делает один человек, а HTML потом в ходе жизни проекта меняет другой. А тот, кто делал вёрстку, делает уже другой проект и привлекать его к подправлению того, что сломалось — долго.
БЭМ родился исходя именно из этих условий, из промышленного производства сервисов, когда нет ни возможности, ни необходимости подправлять что-то в стилях при изменении разметки. А так же из необходимости делать компоненты, которые потом используются в произвольных местах, иногда самым неожиданным образом.
Простите, но это вы мне пишете «Так ещё круче», а не я вам.
Я вам оппонирую, что мы уже все возможные варианты рассмотрели и даже использовали это в продакшене. Потом отказались от «извращений» в пользу простых классов и простой схемы именования.
Например если есть .fancy-button, у которого внутри .fancy-button__label — не надо делать штуки типа ".my_panel .fancy-button__label { color: red }". Надо идти в fancy-button.css, и делать там модификатор fancy-button--important.
Лучше использовать миксы (https://ru.bem.info/method/definitions/#Микс), чем плодить модификаторы. В данном случае лучше сделать ".my-panel__button-label {color: red}" и использовать как «class='my-panel__button-label fancy-button__label'.»
С поправкой на то, что это именование классов для отладки, а по факту именование классов можно сделать любым, какой-нибудь другой фреймворк будет выдавать в сборке продакшна
«Какой-нибудь другой фреймворк» и БЭМ-классы может выдавать в таком же минимальном виде, разницы нет.
CSS классы с общими именами (без конкретики) допустимы только на последнем уровне вложенности
Вот есть у вас компонента menu, а ней логично есть item. А рядом есть navigation, а в нм логично тоже есть item.
И есть CSS:
.menu .item {}
.nevigation .item {}
И всё прекрасно работает, пока в какой-то из дней (обычно в пятницу перед сдачей проекта заказчику) меню не понадобится вложить в navigation. И вот тут начинается самое интересное.
Нет, menu-list__link не должно становиться .menu-list__full-article-link.
В этом примере menu-list__link это ссылка внутри блока menu-list и она смешивается с full-article-link. Блок menu-list это какое-то меню, которое ничего не знает, что в него вкладывают, его семантика — быть меню и показывать всё, что в него положат.
Ну и secondary лучше задавать для full-article-link: .full-article-link_secondary (хотя предполагаю, что абстрактное меню может иметь в себе ссылки разных размеров (оставим за скобками зачем это нужно) и _size_small указывает как раз на это, что может быть ещё normal).
Мы пробовали. Очень сложно привести код к такому состоянию, особенно если используются библиотеки.
Это было.
Вам это часто пригождается в вашей работе разработчиком интерфейсов?
Это шире, чем разработка, это проектирование. В ШРИ мы ставим целью научить, как эффективно именно вести разработку, как взаимодействовать в команде.
То, о чём вы пишете у нас есть в Мобилизации, она была в 2016 летом в Москве и будет в 2017.
Тут лучше использовать модификатор ключ-значение, потому что фактически может быть только один из этих модификаторов у конкретной кнопки, т.е. кнопка может быть или positive, или negative, или neutral.
Рассматривайте это как аналог атрибута type у input. Значение конкретного типа определяет каким именно будет этот input. Тут логика точно такая же.
И в FAQ поиск по «микс»: https://ru.bem.info/faq/
БЭМ родился исходя именно из этих условий, из промышленного производства сервисов, когда нет ни возможности, ни необходимости подправлять что-то в стилях при изменении разметки. А так же из необходимости делать компоненты, которые потом используются в произвольных местах, иногда самым неожиданным образом.
Я вам оппонирую, что мы уже все возможные варианты рассмотрели и даже использовали это в продакшене. Потом отказались от «извращений» в пользу простых классов и простой схемы именования.
http://habrahabr.ru/post/270075/#comment_8641681
https://ru.bem.info/forum/-68/
rscss это упрощённый вариант БЭМ, в котором введены дополнительные искусственные ограничения. Автору так нравится больше, вай бы и нот?
В случае БЭМ это было бы
Так работает всегда:
А как вы переверстаете? Как положено?
И есть CSS:
.menu .item {}
.nevigation .item {}
И всё прекрасно работает, пока в какой-то из дней (обычно в пятницу перед сдачей проекта заказчику) меню не понадобится вложить в navigation. И вот тут начинается самое интересное.
В этом примере menu-list__link это ссылка внутри блока menu-list и она смешивается с full-article-link. Блок menu-list это какое-то меню, которое ничего не знает, что в него вкладывают, его семантика — быть меню и показывать всё, что в него положат.
Ну и secondary лучше задавать для full-article-link: .full-article-link_secondary (хотя предполагаю, что абстрактное меню может иметь в себе ссылки разных размеров (оставим за скобками зачем это нужно) и _size_small указывает как раз на это, что может быть ещё normal).