Добрый день!

Очень часто сталкиваюсь с делемой, как мне классифицировать элементы в тексте, которые нужно как-то по особенному выделить, например сделать текст красным или сделать его больше? Например в такой конструкции:

<div class="block">
  <p class="block__text">Lorem <span class="">ipsum</span> dolor sit amet consectetur adipisicing elit. Sapiente voluptatum ipsam recusandae eum tempora quasi quae sequi modi illo dicta error animi quia, quibusdam odit praesentium ut assumenda? Iure, rem.</p>
</div>

Как мне классифицировать span по БЭМ? По документации, я не могу назвать блок как red-text. Отлично, тогда наверное это модификатор! Но вместе с модификатором, я также должен продублировать имя элемента, или блока... но я не могу для span'a, присвоить класс его родителя. Тогда как же быть? Не было бы проблем, если бы я мог просто написать:

<span class="block__text--red">ipsum</span>

Так как в этой ситуации поступить?

Ситуация: хочу чтобы в двух разных страницах загружались разные блоки, но блоки почему-то не подключаются.

Дано: блок logo-OC и logo-w-OC и код:

block("footer")(
    content()(function () {
      return this.ctx.content.map(function (item) {
        let footerLogo;
        if (item.footerLogoBlack) {
            footerLogo = [
                {   
                    block: "logo-w-OC",
                },
          ];
        }
        if (item.footerLogoWhite) {
            footerLogo = [
                {   
                    block: "logo-OC",
                },
          ];
        }

        return [
            {
                cls: "container",
                content: [
                  { 
                    elem:'row',
                    content: [
                      {
                        elem:'col',
                        elemMods:{mb:'md-20'},
                        content: [
                          {
                            cls: "row",
                            content:footerLogo,
                        ],
                      },
                    ],
                  },
                ],
              },
        ];
      });
    }),

  );

и, странно, что в html они добавляются, но блоки не подключаются.(классы logo-w-OC и logo-OC, но блока нет)

хотелось бы обойтись одним шаблоном, чем делать два разных блока, типа footer-1 и footer-2

Есть ли возможность заставить bem-xjst генерировать HTML в таком виде:

<button class="b-button b-button_size_large">Label</button>

вместо:

<button class="button button_size_large">Label</button>

Приветствую! Не понимаю. Подскажите пожалуйста, допустимо ли применение нескольких элементов БЭМ на одном теге?

.block-a
  .block-b
    .block-a__elem.block-b__elem

Ну, и попутно вопрос по вложенности. Допустимо ли такое:

.block-a
  .block-b
    .block-a__elem.block-c
      .block-b__elem
        .block-c__elem

Предположим, у меня есть блок header, в нем есть блок search, который, в свою очередь, содержит кнопку "закрыть". Данная реализация с такой кнопкой предполагается только в хедере и нигде более.

Отсюда вопрос:

1. Как мне оформлять данную кнопку с точки зрения БЭМ, как элемент блока header или как элемент блока search?
2. Допустимо ли во вложенном блоке использовать элементы блока родителя?

Заранее, благодарю.

<header class="header">
    <div class="search header__search">
        <form class="search__form" action="/" method="post">

                    <button type="submit" class="search__submit">
                        <i class="icon icon--search"></i>
                        <span>Найти</span>
                    </button>

                    <input class="search__input" placeholder="Поиск товаров" type="text" name="search">

                    <a class="search__extended" href="#">
                        <i class="icon icon--gear--outline"></i>
                        <span>Расширенный поиск</span>
                    </a>

                    <!-- Кнопка ЗАКРЫТЬ -->
                    <button class="header__search-close">
                        <i class="icon--cancel"></i>
                    </button>

                </form>
    </div>
</header>

Cuprite — ещё одно open-source решение, разработанное нашей командой. Это драйвер для Capybara, который позволяет использовать Ferrum без переключения между API. Ferrum + Capybara = Cuprite Cuprite — это драйвер для Capybara, который использует Ferrum — драйвер на чистом Ruby с минимальным количеством зависимостей для запуска headless Google Chrome.

О том, как:

• Начать работать с Cuprite
• Управление браузером
• Запуск теста в ограниченной среде
• Cuprite API

...читайте в статье на нашем сайте.

Репозиторий проекта и инструкции к инсталляции на Github.

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

Допустим, у меня есть такая структура:

...
<body>

<header class="header">
  <span class="header__logo">LOGO</span>
</header>

<h1>Its home page</h1>

<div class="some-block">
  <p class="some-block__text">Some stuff</p>
</div>

<div class="some-block">
  <p class="some-block__text">Some another stuff</p>
</div>

</body>
</html>

И CSS:

.header {
  background-color: orangered;
}

.some-block {
  background-color: orange;
}

.some-block__text {
  margin: 0;
}

Первый вопрос. Что если мне нужно для блока Header поставить margin-bottom: 10px? Так как это блок и я хочу его переиспользовать, то для него задать я не могу. В таких случаях идеально должны подойти миксы, те сделать Header элементом другого блока, НО какого?

...
.???__header {
  margin-bottom: 10px;
}

Второй вопрос. Вот у меня на этой странице есть 2 блока Some Block и для них мне нужно сделать margin: 15px, те мне опять же нужно сделать его элементом какого-то блока (какого и как я пойму из первого ответа) и опять же сделать:

...
.???__some-block (или?) {
  margin: 10px;
}

Но что если для второго такого-же блока мне нужно, чтобы правый внешний отступ был 20px: margin-right: 20px (и это исключительно особенность его расположения на этой страницы, как и внешние отступы по 10px, просто для второго такого-же блока правый отступ нужен в 20px).

Третий вопрос. Что если у меня появились еще 3 дополнительных страницы, например, About, Contacts и Policy на каждой из которых (КРОМЕ Contacts) у блока Header как и на странице Home margin-bottom: 10px, а на странице Contacts margin-bottom: 15px (это чисто дизайнерская особенность этой странице и этот отступ для блока Header в 15px зависит только от того, что он находится на странице Contacts).

Четвертый вопрос. На каждой странице, как в примере со страницей Home у меня есть заголовок (h1), который показывает на какой странице я нахожусь и стили которого я до этого момента оставлял базовыми, но вот теперь я решил задать, что на всех этих страницах он будет размером в 27px, те мне его нужно выделить в отдельный блок? Или же на каждой странице сделать его элементом какого-то другого абстрактного блока (какого я пойму из первого вопроса)?

И вот я выделил как-то этот заголовок, но что если на странице Home (что является особенностью этой страницы) этот заголовок имеет размер 30px и color: green? Что сделать в этом случае?

Всем привет!

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

Поясню на примере: Есть блок title

.title {
    padding: 18px 0;
    font-size: 36px;
    font-weight: bold;
}

который используется так

<h1 class="title">Some text</h1>

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

• Делать глобальный CSS-reset противоречит БЭМ (поскольку это глобальные стили и могут меняться от проекта к проекту)
• Сбросить внешние отступы в самом блоке я не имею права (поскольку это внешняя стилизация)
• Вариант который я сейчас вижу кажется мне очень костыльным

  <div class="title">
    <h2 class="title__text">Some text<h2>
  </div>
  

  .title__text {
    margin: 0;
    padding: 18px 0;
    font-size: 36px;
    font-weight: bold;
  }
  

  То есть сам блок это пустая обёртка а уже h1 или h2 - это элемент блока, который я могу стилизовать как мне нравится.

Очень хочу услышать ваше мнение поэтому поводу. Как правильно сделать это по БЭМ?

Анонимизация данных на лету на основе шаблонов

Как работать с персональными данными в тестовых средах?

В продакшене часто требуется хранить и использовать чувствительные данные, включая персональные данные (ПД). Разработчикам в работе на тестовых окружениях иногда бывают нужны данные, максимально приближенные к реальным, уже имеющимся в продукте. Несмотря на то, что в хранении пользовательских данных всегда применяются лучшие практики, такие регламенты и законы как ФЗ «О защите персональных данных», HIPAA, HITECH, CPRA или GDPR требуют, чтобы любые персональные данные хранились и использовались только там, где это необходимо и были защищены или анонимизированы при передаче.

Есть разные способы решения этой проблемы. Например, строгое разделение таблиц в базе данных: в каких-то хранятся персональные данные, в каких-то нет. Таблицы с ПД можно пропускать при экспорте или заменять их искусственными данными в системах разработки. Минус такого подхода — система должна быть изначально спроектирована с учётом такого разделения данных. К тому же искусственные данные хранятся достаточно близко с реальными прототипами, что может вызывать вопросы с точки зрения безопасности.

Другой способ — генерировать «чистый» дамп на стороне продакшена, в котором персональные данные скрыты или заменены несуществующими данными, похожими по формату на реальные. Разработчики могут сразу импортировать его, а риск утечки ПД при этом становится гораздо ниже.

Именно на таком подходе и основан Datanymizer.

Фейкеры, анонимайзеры и обфускаторы — существует много инструментов с открытым исходным кодом для анонимизации данных. Они работают давно и весьма успешно. Так почему бы нам не создать ещё один? Только поддерживающий глобальные переменные, ограничения уникальности, встроенные правила и другие крутые функции.

Конечно же, у нас были свои особенные требования к этому инструменту. Мы не хотели, чтобы анонимайзеру приходилось брать «сырой» дамп и мутировать его. Вместо этого нужно было отдавать уже анонимизированный дамп, без доступа к реальным данным. Конфигурация, которая определяет, как именно данные реальной системы будут анонимизированы, должна храниться отдельно от этих данных.

Ну и наконец, мы хотели сделать инструмент более гибким, поэтому встроили шаблонизатор, с помощью которого можно сгенерировать любые данные: не только предустановленные, но и произвольного формата.

Datanymizer: ваш новый помощник, сохраняющий конфиденциальность данных

Datanymizer делает всё вышеперечисленное. Вы определяете конфигурацию, которая указывает, что делать (и не делать). Затем он выгружает данные непосредственно из вашей базы данных, применяя заданные правила. Ещё в него интегрирован движок шаблонов Tera, чтобы можно было синтезировать произвольный формат значений.

На выходе у вас получается анонимизированный SQL-дамп, записанный либо в файл, либо непосредственно в стандартный вывод, готовый к импорту с помощью родных инструментов базы данных.

Начало работы

Есть несколько способов установить pg_datanymizer. Выберите подходящий для вас.

Предварительно скомпилированный бинарный файл:

# Linux / macOS / Windows (MINGW and etc). Installs it into ./bin/ by default
$ curl -sSfL https://raw.githubusercontent.com/datanymizer/datanymizer/main/cli/pg_datanymizer/install.sh | sh -s

# Or more shorter way
$ curl -sSfL https://git.io/pg_datanymizer | sh -s

# Specify installation directory and version
$ curl -sSfL https://git.io/pg_datanymizer | sh -s -- -b usr/local/bin v0.1.0

# Alpine Linux (wget)
$ wget -q -O - https://git.io/pg_datanymizer | sh -s

Homebrew / Linuxbrew:

# Installs the latest stable release
$ brew install datanymizer/tap/pg_datanymizer

# Builds the latest version from the repository
$ brew install --HEAD datanymizer/tap/pg_datanymizer

Docker:

$ docker run --rm -v `pwd`:/app -w /app datanymizer/pg_datanymizer

README содержит пример конфигурации, которую можно использовать в качестве отправной точки.

Теперь вы можете вызвать Datanymizer для создания изменённого дампа ваших данных:

$ pg_datanymizer -f /tmp/dump.sql -c ./config.yml postgres://postgres:postgres@localhost/test_database

Эти команды создают новый дамп-файл /tmp/dump.sql с нативным SQL файлом для базы PostgreSQL. Мы можете импортировать фейковые данные из этого дампа в новую базу данных с помощью команды:

$ psql -Upostgres -d new_database < /tmp/dump.sql

Фильтры таблиц

Вы можете определить список таблиц, которые никогда не будут включаться в дамп. Например, для дампинга только public.markets и public.users data:

# config.yml
#...
filter:
  only:
    - public.markets
    - public.users

А для игнорирования этих таблиц при создании дампа из остальных:

# config.yml
#...
filter:
  except:
    - public.markets
    - public.users

Также вы можете управлять фильтрами данных и фильтрами схем независимо.

Глобальные переменные

Вы можете определить глобальные переменные доступные из любого шаблона правил:

# config.yml
tables:
  users:
    bio:
      template:
        format: "User bio is {{var_a}}"
    age:
      template:
        format: {{_0 * global_multiplicator}}
#...
globals:
  var_a: Global variable 1
  global_multiplicator: 6

Встроенные правила

Datanymizer имеет встроенную поддержку («правила») для определенных типов значений, а также pipeline, позволяющий генерировать значения, применяя цепочки существующих фильтров для одного поля. Другие фильтры также включают параметры email, ip, words, first_name, last_name, city, phone, capitalize, template, digit, random_number, password, datetime и другие.

Ограничения уникальности

Уникальность поддерживается правилами email, ip, phone, random_number.

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

Вы можете менять количество попыток параметром try_count. Это опциональное поле, количество по умолчанию зависит от правила.

Планы на будущее

Вот какие функции мы хотим добавить в следующих обновлениях:

Pre-filtering: например, если необходимо выдавливать не всех пользователей, а тех, которые соответствуют определенным критериям (например, 100 пользователей, в возрасте 27 лет и старше, по имени Александр), с поддержкой произвольных SQL-запросов для фильтрации. Генерация данных: если вам нужно не анонимизировать существующие данные, а генерировать синтетические, основанные на определенных правилах. Поддержка других RDBMS: сейчас Datanymizer поддерживает только базы PostgreSQL, но в будущем добавится mySQL и MariaDB. Присоединяйтесь к разработке Datanymizer и предлагайте свои идеи!

Допустим, в моем проекте есть 2 уровня переопределения: "lib" и "project". На обоих уровнях присутствуют технологии "js" и "helper.js". Мне нужно, чтобы в итоговую сборку попали файлы "js" и "helper.js" из "project", и только "helper.js" из "lib". Т.е. что-то вроде этого:

const src = require('gulp-bem-src');

src(
    ['lib', 'project']
    [{ block: 'button' }],
    'js',
    {
        config: {
            'lib': {
                scheme: 'nested',
                techMap: ['helper.js']
            }
            'project': {
                scheme: 'nested',
                techMap: ['js', 'helper.js']
            }
        }
    }
)

Можно ли такое реализовать в gulp? В документации ничего такого не нашел, даже в методологии такие кейсы не описываются. Есть, конечно, gulp-merge и другие способы объединить потоки в gulp, но они будут замедлять сборку, т.к. придется заново вызывать gulp-bem-src, он будет заново разрешать зависимости т.д..

Здравствуйте. Использую бэм уже продолжительное время, но до сих пор иногда оказываюсь просто в растерянности в некоторых ситуациях Есть 2 кейса:

1. Первый кейс. У нас есть блок .contacts, который используется в header, footer и на странице контакты

.contacts
    .contacts__item
        .contacts__link

Во всех 3-х случаях его элементы выглядят и позиционируются немного по разному. Для позиционирования я делаю микс

.contacts.header__contacts
    .contacts__item
        .contacts__link

Но встает вопрос, как стилизовать элементы: Давать миксы header__item и header__link не вариант, т.к. в хэдере могут уже существовать эти классы вне контекста .contacts

1) Можно создать еще один пустой микс класс

.contacts.header__contacts.header-contacts
    .contacts__item.header-contacts__item
        .contacts__link.header-contacts__link

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

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

3) Можно сделать модификатор для блока и стилизовать каскадом

.contacts.contacts--theme--header.header__contacts
    .contacts__item
        .contacts__link

.contacts--theme--header .contacts__link {
}

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

2. Второй кейс. У нас есть базовый блок карточки

.card
   .card__img
   .card__inner
      .card__title
      .card__content
   .card__btn

Допустим она используется в каталоге. Но так же на странице с портфолио, но выглядит немного иначе. Создавать пустой микс класс .portfolio-card мне кажется плохой практикой, т.к. мы привязываемся к контексту. А что если эта модифицированная карточка будет еще на какой-то странице? Тогда само слово portfolio уже будет ни к селу ни к городу. Микс portfolio__img, portfolio__inner и т.д. тоже не жизнеспособны, т.к. нам нужно менять элементы именно в контексте карточки.

Я пришел к тому, что лучше всего будет давать карточкам абстрактные модификаторы

.card.card--type--1
   .card__img
   .card__inner
      .card__title
      .card__content
   .card__btn

.card--type--1 .card__img{
}

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

.card.card--type--1
   .card__img.card__img--hover--green
   .card__inner.card__inner--color--red
      .card__title
      .card__content
   .card__btn

.card--type--1 .card__img{
}

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

Был бы очень рад услышать аргументированную критику и ваши мысли на этот счет.

В bemhtml, правила replace и wrap при любых значениях что-то делают. Например, для значений null, undefined, true и false, в результате будут просто пустые строки. Вопрос в следующем: каким образом можно переопределить данные правила так, чтобы они не применялись в принципе?

Вот пример:

block('test')(
    {
        replace: '...'
    },
    mod('test-mod')({
        // Не убирает предыдущий replace, а меняет его на пустую строку
        replace: undefined
    })
);

// Будет пустая строка
{
    block: 'test',
    mods: {test-mod: true}
}

Допустим, есть нескольких однотипных секций.

section.header

section.about

section.footer

В каждой секции есть блоки с одинаковым видом(стили), т.е.

<section class="header">
   <div class="header__title">Заголовок</div>
   <div class="header__subtitle">Подзаголовок</div>
   <div class="header__text">Основой текст. Основой текст. Основой текст. Основой текст.</div>
   <div class="header__btn><a class="header__link" href="#">Ссылка</a></div>
</section>

Раз он(стиль) повторяется, можно ли(правильно ли, с точки зрения БЭМ) сделать такую модификацию?

1. Сделать микс с header, т.е. header fortext
2. Вместо элементов сделать модификаторы

<section class="header fortext">
   <div class="fortext_title">Заголовок</div>
   <div class="fortext_subtitle">Подзаголовок</div>
   <div class="fortext_text">Основой текст. Основой текст. Основой текст. Основой текст.</div>
   <div class="fortext_btn"><a class="header__link" href="#">Ссылка</a></div>
</section>

Чтобы fortext... применять для др. секций

Код правильный, с точки зрения БЭМ ?? Или может лучше, как-то по другому?

<div class="reg">
  <button class="reg__btn reg__btn_close">Закрыть</button>
  <button class="reg__btn reg__btn_reg">Регистрация</button>
  <button class="reg__btn reg__btn_login">Вход</button>
</div>

.reg {}
.reg__btn {
  border: 0px;
}
.reg__btn_close {
  position: absolute;
  top: 0px;
  right: 0px;
  background-image: url(images/icon_close.png);
}
.reg__btn_reg {
  background-color: red;
  background-image: url(images/icon_reg.png);

}
.reg__btn_login {
  border: 1px solid black;
  background-color: green;
  background-image: url(images/icon_login.png);
}

Или кнопки с значительными изменениями лучше обозначать отдельным элементом, например: reg__close-btn?

Добрый день. Добавляю к блоку header элемент inner в bemhtml

block('header')(
    tag()('header'),
    content()(function() {
        return {
            elem: 'inner',
            content: this.ctx.content
        };
    })
);

Указываю для этого элемента стили в

header/__inner/header__inner.css

При сборке вся разметка на месте