Как правильно размечать структурно сложные, но одноразовые элементы: бем-блоком или бем-элементом родителя?

Вопрос 1: Предположим имеется какой-нибудь блок карты (card), который в принципе может переиспользоваться в других проектах. Но в разных проектах разные размеры шрифтов. Каким образом поступить: задавать какой-то размер по-умолчанию (например подходящий для текущего проекта) или создавать модификаторы для размеров (или еще как-то)?

Вопрос 2: Предположим есть блок кнопки (button), и в разных местах одного и того же проекта ему задаются разные размеры, это все нужно задавать через модификаторы?

Вопрос 3: Иногда требуется задать отступы от одного блока до другого, как это лучше реализовать (через модификаторы)?

Вопрос 4: Одна и та же кнопка в разных проектах имеет некоторые различия во внешнем виде, но часть стилей одинаковая, в стиль блока запихнуть только общее, а остальное сделать через модификаторы (_theme_a, _theme_b)?

P.S. Новичок в БЭМ, вопросов много, извините.

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

<div class="header">
    <!-- К блоку `search-form` примиксован элемент `search-form` блока `header`-->
    <div class="search-form header__search-form"></div>
</div>

Микс header__search-form добавляет некие стили форме поиска. Форма поиска у нас подключается программно модулем. Теперь решили, что форма поиска необходима и в футере. Описываем подключение модуля и там с тем же шаблоном. И у нас (если ни чего не менять) этот микс применится и в футере. Соответственно нам необходимо либо иметь два разных шаблона блока поиска, либо микс выводить по выполнению условия (скажем PHP формирует этот HTML). Что является по сути лишним. Гораздо более логично, понятно и чище будет обойтись без "миксов". Или, точнее, реализовывать их "обычным" способом каскадных стилей.

.header .search-form { color:red; }

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

В данном примере мы совместили поведение и стили блока search-form и элемента search-form блока header. Такой подход позволяет нам задать внешнюю геометрию и позиционирование в элементе header__search-form, а сам блок search-form оставить универсальным. Таким образом, блок можно использовать в любом другом окружении, потому что он не специфицирует никакие отступы. Это позволяет нам говорить о его независимости

В реальности действует если только это блок встречается один раз на странице. В противном случае код должен отличаться как раз таки заставляя вписывать эти миксы.

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

Предположим, есть блок button:

< div class="button" > < div class="button_ _icon" / > < /div>

.button_ _icon { color: yellow; }

Он является элементом для блока panel

< div class="panel" > < div class = "button panel_ button" > < div class="button _icon" /> < /div> < /div>

Предположим, мне надо поменять цвет у button__icon только в панели, но не задеть его в остальных местах. Как это сделать правильно?

1. Примиксовывать к button_ icon panel _button-icon. Это может привести к изменению кода блока button, если он не подразумевал возможность примиксовывать к иконке другие классы (например, мы используем React), что противоречит БЭМ.
2. Использовать вложенный селектор .panel .button_ _icon { color: red; }. Это увеличивает связанность компонент и зависимость от реализации button'а. Ну и в обоих этих вариантах panel в принципе не должен обращаться да и знать про элементы чужого блока.
3. Добавить модификатор button_ _icon_color_red для иконки. Опять же потребуется изменение кода для кнопки. И реализация сильно усложнится, если вложенность будет бОльшая - например, не во всех панелях у кнопки другой цвет, а только в панелях, которые лежат в header. Прокидывать модификатор через всю иерархию - напрягает. Как правильно?

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

Есть какие-то готовые решения, которые у меня не получилось загуглить? В какую сторону смотреть?

Всем привет ! Я только недавно начал глубже погружаться в БЭМ-методологию (до этого использовал только БЭМ-нейминг). Мне очень понравилась эта концепция и хотелось бы полностью внедрить ее в свой воркфлоу. Однако, т.к. у меня недостаточно опыта и я довольно поверхностно знаю JavaScript, мне не хватает знаний чтобы запилить свой "велосипед" для Gulp4 и/или Webpack4. А готовые решения вроде bem-tools, enb и других специфических решений мне не подходят из-за своей перегруженности и как мне кажется сложности. Я не говорю что это так и есть, это справедливо и субъективно лично для меня.

Хотелось бы иметь возможность подтягивать данные в pug-шаблоны из data.json-файла или аналогичного data.js, а также декларативно определять структуру БЭМ-боков с учетом соответствующих зависимостей.

Если совсем коротко, то нужно вот из такой структуры:

app
│   ├── assets
│   │   ├── fonts
│   │   ├── images
│   │   └── libs
│   ├── blocks
│   │   ├── common.blocks
│   │   │   ├── footer
│   │   │   └── header
│   │   │       ├── header.js
│   │   │       ├── header.pug
│   │   │       ├── header.scss
│   │   │       ├── img
│   │   │       └── nav-menu
│   │   │           ├── img
│   │   │           │   └── background.jpg
│   │   │           ├── nav-menu.js
│   │   │           ├── nav-menu.pug
│   │   │           └── nav-menu.scss
│   │   ├── desktop.blocks
│   │   └── touch.blocks
│   ├── pages
│   │   ├── about
│   │   │   ├── about.js
│   │   │   ├── about.pug
│   │   │   └── about.scss
│   │   ├── gallery
│   │   │   ├── gallery.js
│   │   │   ├── gallery.pug
│   │   │   └── gallery.scss
│   │   └── home
│   │       ├── home.js
│   │       ├── home.pug
│   │       └── home.scss
│   └── templates
│       ├── custom.pug
│       └── default.pug

получить на выходе вот такую:

.
├── about.html
├── assets
│   ├── fonts
│   │   ├── font1
│   │   └── font2
│   ├── images
│   │   └── sprites
│   │       ├── png
│   │       └── svg
│   ├── scripts
│   │   ├── about.min.js
│   │   ├── common.min.js
│   │   ├── gallery.min.js
│   │   └── home.min.js
│   └── styles
│       ├── about.min.css
│       ├── common.min.css
│       ├── gallery.min.css
│       └── home.min.css
├── gallery.html
└── home.html

Мне не принципиально на чем делать сборку, будь-то Gulp, Webpack или их совместное использование, главное получить ожидаемый и предсказуемый результат. Надеюсь, я доступно изъяснялся и смог донести свою мысль. Какие будут мысли на этот счет ? :) Заранее всем признателен.

з.ы. Естественно, прежде чем оставлять свой вопрос здесь я шерстил по сети в поисках готовых решений, однако в одних случаях разобраться мешало отсутствие документации, в других - неактуальность самой информации, в иных - не хватало моей профессиональной компетенции. з.з.ы. В Ютубе я натыкался на пару видео, но если честно, изложенная там информация расчитана далеко не на новичков. Пользуясь случаем, хочу попросить ответственных ребят из Яндекса обновить учебные видеоматериалы и записать воркшопы по сборке БЭМ-проектов на Gulp4 и Webpack4 с учетом реалий 2019 года. Я думаю, не одна сотня людей ждет подобного материала. Всем спасибо.

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

Решил создать собственный блок. Назвал его usual. Но при добавлении mod к нему ничего не происходит. Единственное, что применяется - это tag()(). Вот, что я пишу в usual.bemhtml(скрин) Вот что на выходе:

Следую инструкциям описанным в этой статье - https://habr.com/company/yandex/blog/251473/ При сборке и старте проекта(npm start или enb server) возникает ошибка в borshik'е При этом проект собирает все, но при изменении чего-либо в файлах не реагирует и не перезагружает страницу.

TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type undefined
    at assertPath (path.js:39:11)
    at Object.dirname (path.js:651:5)
    at res.__constructor (C:\Users\Admin\Desktop\currebt\secondproject\node_modules\borschik\lib\tech.js:87:47)
    at new res (C:\Users\Admin\Desktop\currebt\secondproject\node_modules\borschik\node_modules\inherit\lib\inherit.js:123:43)
    at res.createFile (C:\Users\Admin\Desktop\currebt\secondproject\node_modules\borschik\lib\tech.js:24:24)

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

<div class="page-main__banner banner">
    <section class="banner__content">
      <h1 class="banner__title">Быстрая доставка цветов</h1>
      <ul class="banner__advantages">
        <li class="banner__advantage banner__advantage--rose">
          Ежедневный привоз свежих цветов
        </li>
        <li class="banner__advantage banner__advantage--ruble">
          Низкие цены за счет больших поставок
        </li>
        <li class="banner__advantage banner__advantage--car">
          Быстрая круглосуточная доставка
        </li>
      </ul>
    </section>
  </div>

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

Дайджест новостей по БЭМ. Выпуск №15

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

Итак, главные новости полугодия:

БЭМ и React

Антон Виноградов пожелал всем добра и сообщил, что bem-react-corе v3 влита в master и с этого момента становится основной рекомендованной версией библиотеки для работы с БЭМ в React мире. А вот версии v1 и v2 больше поддерживаться не будут, но еще какое-то время будут доступны в ветках.

Репозиторий bem-react-core переименован в bem-react для соответствия с npm неймспейсом @bem-react, где находятся все пакеты библиотеки.

Инструменты

• Выпустили @bem-react/* пакеты.
• Опубликовали пакет enb-js-browserify в npm. Используйте его, чтобы получить commonJs в своем клиентском коде.

Документация

Обновили документацию к пакетам bem-sdk с живыми примерами в RunKit:

• walk
• naming.entity.parse
• naming.entity.stringify

БЭМ и DESIGN

• Опубликовали первую версию дизайн-системы Whitepaper.
• Собрали портал http://whitepaper.tools.
• Переехали в новую организацию на GitHub https://github.com/whitepapertools.

Все актуальные новости и анонсы ребята публикуют в Telegram канале whitepaper.

Мероприятия

• Провели митап по БЭМ, где рассказали о библиотеке bem-react-corе v3, которая помогает работать по БЭМ-методологии в мире React. На простых примерах показали, как использование библиотеки делает ваши React-проекты гибче и проще в поддержке. Для всех, кто пропустил, мы записали видео.
• Продолжили эстафету встреч для новичков: на этот раз провели два в дневных интенсива. Видео опубликовано на сайте событий Яндекса. Чтобы не пропустить следующий интенсив, подписывайтесь на новости БЭМ-сообщества.

Видео со всех встреч мы публикуем в канале bem.info на YouTube.

Всех с наступающими и наступившими праздниками! Stay BEMed!

Вопрос 1: Вроде DI штука понятная, но пока не понятны паттерны её использования. В частности одна из фичь, про которую говорят — дешёвые эксперименты. Но чтобы эксперименты были максимально дешёвыми (через di), то получается, что во всех блоках нужно отказаться от "классических" импортов и всё делать через di? (чтобы при приходе эксперимента не нужно было переписывать блок на di)

Вопрос 1.1: Где должен храниться код/реестры экспериментов? Внутри компонентов или лежать где-то рядом с компонентами?

Вопрос 1.2: Как правильно накатывать реестры и использовать версии экспериментов?

Вопрос 2: Следующее... В di правильно будет в качестве registry.id указывать имя блока или можно указывать и модификатор?

// ProductCard
new Registry({ id : 'ProductCard' })

ProductCard.registry/desktop.js
ProductCard.registry/mobile.js

// Product/_layout
new Registry({ id : 'ProductCard_layout_grid' })

ProductCard_layout_grid.registry/desktop.js
ProductCard_layout_grid.registry/mobile.js

@awinogradov @tadatuta

23 ноября в 19:00 о московском офисе Яндексе пройдет очередной БЭМап.

Регистрируйтесь скорее!

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

На этот раз мы хотим перейти от теории к практике и на простых примерах показать, как использование библиотеки делает ваши React-проекты гибче и проще в поддержке.

Мы рассмотрим все три пакета библиотеки:

• classname — для генерации имен классов в соответствии с БЭМ-нотацией
• core — для динамической работы с модификаторами
• di — для реализации концепции уровней переопределения с помощью паттерна Dependency Injection

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

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

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

Stay BEMed!

https://5minreact.ru/49-bem-react-core/ — слушайте на здоровье!

Уважаемые коллеги, подскажите, пожалуйста, как правильно переопределять стили блока, например:

.article__text {color: blue;} /* стиль текста именно в блоке article*/
.text {color: red;} /* общий стиль текста блока text*/

<div class="article">
    <p class="text article__text">Текст все равно красный!</p>
</div>

Стиль текста article__text все равно не меняется, потому что .text расположен ниже (сборка стилей в main.css происходит по алфавиту). Считаю, что использование !important или дополнительную вложенность элементов - это не метод БЭМ, так как же правильно обходить такую ситуацию? Следить за алфавитным порядком стилей в большом проекте также объективно не имеется возможности.

Или я неправильно понимаю использование миксов? Укажите, пожалуйста, на ошибку.

Добрый, посмотрел множество вебинаров по bem и bem-react-core, есть вопросы:

• посмотрел видео https://www.youtube.com/watch?v=pVzlkCidOYg, и теперь не пойму, v3 это улучшенная версия v2 или просто другой подход, в каких случаях нужно v2, в каких v3?
• если имеем react, то как я понимаю мы забываем о шаблонизации классического БЭМ (bemjson + bemhtml -> html)?
• кстати зачем нужен bemtree так до сих пор и не понял..
• нужен ли i-bem js со всей портянкой зависимостей в bem react проектах?

Кто знает, почему в десктопном input нет подписки на change у input__control, зато ставится таймер и по нему проверяется значение контрола? https://github.com/bem/bem-components/blob/v6/desktop.blocks/input/input.js

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

Добрый день, есть вопросы:

• как менять стили например control-group http://joxi.ru/J2bYWbxUXWeQgm их нужно переопределять ?
• И мне кажется что слишком много стилей выходит на выходе, просто подключил control-group - http://joxi.ru/5md5L41IkLQbX2 на выходе в CSS добавилось 550 строк стилей, потом добавил еще menu http://joxi.ru/1A5vBdLcn76Bnr дополнительно к стилям 200 строк. - это нормально ? может можно отключить стили ?
• Для чего тогда нужна Библиотека ?

Вопрос не про bem-components в целом про БЭМ:

• БЭМ по методологии не запрещает использовать after, hover, focus можно их использовать ?

Добрый день, где прописывать media запросы в БЭМ'e?

Всем доброго времени суток не могу понять почему не работает POST CSS и плагин autoprefixer

make.js и почему версии CSS не минимализированы http://joxi.ru/eAOG9BECxjWo6A

const techs = {
        // essential
        fileProvider: require('enb/techs/file-provider'),
        fileMerge: require('enb/techs/file-merge'),

        // optimization
        borschik: require('enb-borschik/techs/borschik'),

        // css
        postcss: require('enb-postcss/techs/enb-postcss'),
        postcssPlugins: [
            require('postcss-import')(),
            require('postcss-each'),
            require('postcss-for'),
            require('postcss-simple-vars')(),
            require('postcss-calc')(),
            require('postcss-nested'),
            require('rebem-css'),
            require('postcss-url')({ url: 'rebase' }),
            require('autoprefixer')(),
            require('postcss-reporter')()
        ],

        // js
        browserJs: require('enb-js/techs/browser-js'),

        // bemtree
        // bemtree: require('enb-bemxjst/techs/bemtree'),

        // bemhtml
        bemhtml: require('enb-bemxjst/techs/bemhtml'),
        bemjsonToHtml: require('enb-bemxjst/techs/bemjson-to-html')
    },
    enbBemTechs = require('enb-bem-techs'),
    levels = [
        { path: 'node_modules/bem-core/common.blocks', check: false },
        { path: 'node_modules/bem-core/desktop.blocks', check: false },
        { path: 'node_modules/bem-components/common.blocks', check: false },
        { path: 'node_modules/bem-components/desktop.blocks', check: false },
        { path: 'node_modules/bem-components/design/common.blocks', check: false },
        { path: 'node_modules/bem-components/design/desktop.blocks', check: false },
        'common.blocks',
        'desktop.blocks'
    ];

module.exports = function(config) {
    const isProd = process.env.YENV === 'production';

    config.nodes('*.bundles/*', function(nodeConfig) {
        nodeConfig.addTechs([
            // essential
            [enbBemTechs.levels, { levels: levels }],
            [techs.fileProvider, { target: '?.bemjson.js' }],
            [enbBemTechs.bemjsonToBemdecl],
            [enbBemTechs.deps],
            [enbBemTechs.files],

            // css
            [techs.postcss, {
                target: '?.css',
                oneOfSourceSuffixes: ['post.css', 'css'],
                plugins: techs.postcssPlugins
            }],

            // bemtree
            // [techs.bemtree, { sourceSuffixes: ['bemtree', 'bemtree.js'] }],

            // bemhtml
            [techs.bemhtml, {
                sourceSuffixes: ['bemhtml', 'bemhtml.js'],
                forceBaseTemplates: true,
                engineOptions : { elemJsInstances : true }
            }],

            // html
            [techs.bemjsonToHtml],

            // client bemhtml
            [enbBemTechs.depsByTechToBemdecl, {
                target: '?.bemhtml.bemdecl.js',
                sourceTech: 'js',
                destTech: 'bemhtml'
            }],
            [enbBemTechs.deps, {
                target: '?.bemhtml.deps.js',
                bemdeclFile: '?.bemhtml.bemdecl.js'
            }],
            [enbBemTechs.files, {
                depsFile: '?.bemhtml.deps.js',
                filesTarget: '?.bemhtml.files',
                dirsTarget: '?.bemhtml.dirs'
            }],
            [techs.bemhtml, {
                target: '?.browser.bemhtml.js',
                filesTarget: '?.bemhtml.files',
                sourceSuffixes: ['bemhtml', 'bemhtml.js'],
                engineOptions : { elemJsInstances : true }
            }],

            // js
            [techs.browserJs, { includeYM: true }],
            [techs.fileMerge, {
                target: '?.js',
                sources: ['?.browser.js', '?.browser.bemhtml.js']
            }],

            // borschik
            [techs.borschik, { source: '?.js', target: '?.min.js', minify: isProd }],
            [techs.borschik, { source: '?.css', target: '?.min.css', minify: isProd }]
        ]);

        nodeConfig.addTargets([/* '?.bemtree.js', */ '?.html', '?.min.css', '?.min.js']);
    });
};

Заранее благодарю!

Вопрос Не могу понять как это сделать по БЭМ

Я не так давно пытаюсь в сборку с помощью Gulp. Конфиг project-stub показался мне слишком сложным для понимания, вдобавок мне нужно было настроить сборку HTML из файлов pug, поэтому было решено затрайхардить и написать свой конфиг. В итоге решения основной задачи я с горем пополам вроде как добился, сейчас в сборку подключаются блоки, которые майнятся из pug файлов, но теперь появилась другая потребность - добавлять в сборку блоки с учётом зависимостей. Конкретный пример - для того, чтобы добавить блок filter в сборку, необходим jquery, который также реализован отдельным блоком jquery с одной технологией jquery.js. По логике вещей я должен создать файл filter.deps.js, зависимости из которого также будут добавлены в сборку перед целевым блоком.

Очевидно, этого не происходит, иначе бы я сюда не написал :)

Ниже приведён код соответствующего таска Gulp:

gulp.task('deps', () => {
   return gulp.src('bundles/**/*.pug')
    .pipe(pug(pugConfig))
    .pipe(tobemjson())
    .pipe(builder({
        css: bundle => bundle.src('css')
          .pipe(autoprefixer(), {
            browsers: ['last 2 versions'],
            cascade: false
          })
          .pipe(concat(`${bundle.name+'/'+bundle.name}.css`)),
        js: bundle => bundle.src('js').pipe(concat(`${bundle.name+'/'+bundle.name}.js`))
    }))
    .pipe(gulp.dest('dist/'));
});

Содержимое deps.js:

module.exports = [{
    mustDeps : 'jquery'
}]

В результате конечный BemBundle.decl содержит все нужные блоки, кроме jquery, который должен быть подключен в качестве зависимости.

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

Есть желание собирать css и из post.css и из .styl.

(По причине: (а) наличия legacy на stylus, (б) отсутствия в postcss жизненно необходимого вроде возможности проверить defined($variable) и nested-ancestors "сверху" -- от родителя -- stylus-аналог ^[0] etc, (в) всё-таки наличия большого кол-ва postcss вкусностей и полезностей.)

Сходу вижу вариант со сбором в отдельные промежуточные таржеты с последующей склейкой через file-merge. Будет не оч. хор., т.к. в итоге блоки с технолгиями stylus и postcss не смогут перекрывать друг друга в соответствии с уровнями переопределения. (С sourcemap file-merge вроде справляться должен.)

Есть ли иной способ?

UPD: enb/file-merge.js, похоже, всё-таки ожидает только js на входе. При попытке склеить css ругается на синтаксис. Т.е. всё пропало?

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

Чуть более года назад связался с БЭМ, до этого что-то умел в плане вёрстки сайтов, но знания были сумбурные. Фреймворк связал эти знания в единое целое и позволил заниматься этим более профессионально, а также подтолкнул к изучению NodeJS и npm. Конечно, путь был довольно тернист и первое время порог входа в БЭМ был слишком высок, но всё-таки преодолеть его удалось.

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

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

БЭМ штука довольно непопулярная, особенно если вы пытаетесь работать фрилансером. Порой часами приходилось объяснять горе-заказчикам что это за зверь и для чего нужен, а после полностью выполненной работы (простой лендинг) я получил деньги и отрицательный отзыв вроде "хотел немного стиль select поправить, а там куча непонятного CSS и длиннющие классы, а JS-код вообще огромен, что это?". И что теперь всех заказчиков-самоучек учить писать по БЭМ и развертывать среду разработки? Увы, получить БЭМ-фрилансеру адекватный заказ оказалось довольно сложно, так как у людей ещё Вордпресс в голове и PHP, перемешанный с HTML в одном файле.

Получается либо искать человека, который хочет сайт под ключ и ему плевать на чём этот сайт работает, либо отказываться от БЭМ и "приземляться" к народу на 5-6 лет назад. А кто-то ещё сталкивался с такой дилеммой?

P.S. Открыт к любым предложениям, связанным с БЭМ (ещё есть куда расти) P.P.S. Извините за многобукв :)

Всем привет! Запаситесь терпением, пожалуйста, но мне правда нужен совет Есть компоненты формы (select, input, textarea) Так вышло, что в зависимости от страницы у элементов меняется вид и я думал, все эти блоки разные (по типу функциональности), но группы элементов имеют одинаковый вид и я поступил так Создал блок form-element, единственное назначение которого быть миксином для стилизации групп сущностей, т.к. мне показалось странным создавать одинаковые стили для каждого компонента, DRY наше всё После этого я стал искать различия между элементами и вышло что-то невероятное

7 различных значений высоты компонента 7 различных значений размера шрифта компонента 5 различных значения bg, включая отсутствие bg 2 значения border-radius, 1 на 10px, другое на 16 Есть или нет рамки 2 значения толщины рамки 3 значения цвета рамки 3 разных значения расположения тени

Сидел, сидел и сЕдел и думал, как я "люблю" дизайнеров, но делать что-то нужно и создал я 5 модификаторов, а именно: form-elementboder(normal || bold) отвечающие только за толщину рамки form-elementrounded(md || lg) отвечающие за значения 10 и 16 form-elementshadow(md || lg), отвечающие за тень form-elementsize(много значений) отвечающие за высоту и размер шрифта form-elementtheme(много значений) отвечающие за цвет фона, цвет шрифта, цвет рамки

Создал отдельно блок input, в итоге код выглядит примерно так

<div class="
    input form-element
    form-element_theme_first
    form-element_size_md
    form-element_rounded_md
    form-element_border_normal
">
    <input type="text" class="input__field">
</div>


.input__field {
    padding: 0 16px;
    margin: 0;
    height: 100%;
    width: 100%;
    border: none;
    outline: none;
    background: none;
    color: inherit;
}

И всё было бы ничего, но пришло время создавать select, который сейчас выглядит так

<div class="
    select
    select_opened
    form-element
    form-element_theme_first
    form-element_size_md
    form-element_rounded_md
    form-element_border_normal
">
     <select name=""></select>
     <div class="select__header">
         <p class="select__value">Product</p>
         <span class="arrow arrow_bottom select__arrow"></span>
      </div>
      <ul class="select__body">
          <li class="select__option">Product</li>
          <li class="select__option">Product</li>
      </ul>
</div>

И здесь я понял, что мне конец, ведь в зависимости от модификаторов form-element, мне нужно менять элементы компонента select, а это неправильно, потому что будут селекторы вида .class .class, но хуже всего, что модификатор одного блока будет влиять на элементы другого блока, совсем не относящегося к нему. Что я имею ввиду, в зависимости от form-element_size_md должен меняться размер select__option, в зависимости от рамки добавляться или уходить она, также про border-radius, да вообще хоть про что, плюсом идут немного разные стили, когда select развернут. В итоге, я в тупике и не знаю как быть, мои варианты были такими, создать все компоненты отдельно select, input, textarea и тупо для каждого были бы свои модификаторы, НО они были бы идентичны, т.к. select_size_md, input_size_md, textarea_size_md означали одно и тоже, это плохо, одинаковые реализации. Дальше я подумал, а что если вынести select из всей этой кучи и добавить модификаторы для него, я получил бы что-то типа select_size_md для селектов и form-element_size_md для input и textarea, но тогда мы всё равно имеем 2 одинаковых реализации. Я бы мог написать их так select_size_md, form-element_size_md, но тогда смысла в создании form-element как отдельной сущности вообще не стало.

И вопросов у меня ровно 3 1) Правильно ли я разбил на модификаторы все различия между элементами, просто их вышло так много и они по 1 строчке почти все, что я сомневаюсь в правильности? 2) Как мне быть с особенностями select компонента (описанию проблемы отдана большая часть текста)? 3) Могу ли я использовать блок так

<div class="block">
    <div class="block__elem1"></div>
    <div class="block__elem2"></div>
</div>

.block {color: #fff; position: relative}
.block__elem1 {position: absolute; right: 0}
.block__elem2{position: absolute; left: 0}

А в другом месте так

<div class="block">
    <div class="block__elem1"></div>
</div>

То-есть, я могу написать хоть 100 стилей для элементов, а потом взять и в блоке только 1 элемент использовать, это нормально?

P.S. Возможно я не совсем корректно написал название вопроса, но моя голова кипит. Заранее спасибо