Ответы пользователя по тегу CSS
  • Актуальность префиксов БЭМ l- b- h- g- js-?

    @ilyarsoftware
    Из истории развития БЭМ https://ru.bem.info/methodology/history/
    2005 год... Классам блоков мы добавили префиксы (b-, c-, g-), чтобы отличать их от внутренних классов...

    Настоящие
    Исторически они появились в переходный период для того, чтобы отличать новый код, написаный по БЭМ, от старого. Со временем мы от них отказались.
    https://ru.bem.info/forum/158/ и https://ru.bem.info/forum/806/

    Соглашение по именованию/Имя блока:
    Иногда к именам блоков могут добавляться различные префиксы.


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

    Дополнительно процитирую заметку "Почему CSS-модули не могут заменить БЭМ":
    Часто слышу, как разработчики говорят «БЭМ не нужен, ведь есть CSS-модули». Это не так.

    Корень этого заблуждения кроется в том, что люди воспринимают БЭМ как CSS-методологию. На самом деле БЭМ это набор универсальных принципов, которые можно применять независимо от используемых технологий, будь то CSS, Sass, HTML, JavaScript или React. БЭМ решает множество задач, в число которых входят именование CSS-классов, подход к разделению интерфейса на независимые части и изоляция стилей для этих независимых частей.

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

    Эволюция выглядит так:
    /* Классический БЭМ с длинными именами классов для обеспечения изоляции */
    
    .shop-cart-button {}
    .shop-cart-button_size_small {}
    .shop-cart-button_size_large {}
    
    
    /* CSS-модули с неограниченной свободой творчества в именах классов */
    
    .button {}
    .small {}
    .large {}
    /* или */
    .button {}
    .is-small {}
    .is-large {}
    /* или */
    .button {}
    .size-small {}
    .size-large {}
    
    
    /* БЭМ и CSS-модули */
    
    .button {}
    .button_size_small {}
    .button_size_large {}

    Сразу отвечу на вопрос «а чем плох пример с классами .button, .small и .large?». Он плох тем, что классы .small и .large сами по себе не несут информации о том, к чему они относятся. Нельзя понять, стилизуют ли они отдельный элемент или описывают состояние существующего элемента. Также такие названия классов рано или поздно снова приведут вас к проблеме уникальности имён. Например, вы пишете стили для модального окна. Вам нужно стилизовать полупрозрачный оверлей поверх страницы и само модальное окно. Оба этих элемента могут быть в двух состояниях: виден или скрыт. Кажется, что класс .visible отлично подходит, но проблема в том, что для оверлея и для окна этот класс должен содержать разные стили. Можно придумать костыль в виде селекторов .overlay.visible и .window.visible, но это именно костыль, потому что вы увеличиваете специфичность. С БЭМом всё просто и без ненужного роста специфичности: .overlay_visible и .window_visible.
    Ответ написан
    Комментировать
  • Как правильней сделать в рамках БЭМ?

    @ilyarsoftware
    ...стилизовать немножко иначе...

    Это может означать очень разное, возможные варианты:
    1. положение — определяем во внешнем окружении т.е. сделать стиль блока зависимым от другого блока;
    2. геометрия, цвет и размеры — должно определятся в самом блоке, вариативность реализуется модификатором, но в зависимости от масштаба вариативности и здравого смысла тоже может быть определятся в другого блоке (в случае применения методологии такую специфичность легко отслеживать), если вариативность уникальная, сделать стиль блока зависимым от другого блока;
    3. типографика — сделать стиль блока зависимым от другого блока.

    В общем если вариативность ограничена и требуется в разных местах уместнее реализовывать модификатором.
    Применение миксов уместно на случай, когда надо совмещать реализации и их вариации.

    Дополнительно:


    P.S. Добавьте к вариантам свой случай в комментарии, дополню ответ.
    Ответ написан
    4 комментария
  • Усовершенствование BEM или "ненужно"?

    @ilyarsoftware
    Такой подход называется: "модификаторы через extend."

    Если не писать HTML руками, этот вопрос теряет смысл.

    Есть риск скатиться в императивное описание названий модификаторов.

    Повышает необходимую квалификацию специалиста, в практике этого подхода особенно критичным становится необходимость понимания: "что я делаю и какие могут быть последствия".

    Есть практики этого похода https://twitter.com/ihorzenich/status/776395453533...

    На БЭМ форуме этот вопрос периодически обсуждается, надо поискать.

    Думаю, не может быть однозначного ответа на этот вопрос.
    Ответ написан
    Комментировать
  • Что насчет JS и префиксов в БЭМ (BEM)?

    @ilyarsoftware
    Из истории развития БЭМ https://ru.bem.info/methodology/history/
    2005 год... Классам блоков мы добавили префиксы (b-, c-, g-), чтобы отличать их от внутренних классов...

    Настоящие
    Исторически они появились в переходный период для того, чтобы отличать новый код, написаный по БЭМ, от старого. Со временем мы от них отказались.
    https://ru.bem.info/forum/158/ и https://ru.bem.info/forum/806/

    Соглашение по именованию/Имя блока:
    Иногда к именам блоков могут добавляться различные префиксы.




    Пример: https://codepen.io/ilyar/pen/WZzzmP?editors=1010#0

    <div class="myBlock i-bem" data-bem='{"myBlock":{"param": "val"}}'>
        ...
    </div>

    modules.define('myBlock', ['i-bem-dom'], function (provide, bemDom) {
    
        provide(bemDom.declBlock(this.name, /* методы экземпляра */ {
    
                onSetMod: {
                    'js': {
                        'inited': function () {
                            this.domElem[0].innerHTML = this.__self.parseParams(this.params);
                        }
                    }
                }
    
            }, /* статические методы */ {
    
                parseParams: function (params) {
                    return '<pre>' + JSON.stringify(params, null, ' ') + '</pre>';
                }
    
            }
        ));
    
    });


    Еще есть реализация БЭМ + React.js https://github.com/bem/bem-react-core, пример https://scrimba.com/c/cQR4bTr и теория https://www.youtube.com/playlist?list=PLAmtJdts5To...
    Ответ написан
  • Правильно ли писать так (бем)?

    @ilyarsoftware
    header_logotype_link и header_logotype_image модификаторы блока («ключ-значение», если следовать Соглашение по именованию), а используются как самостоятельные единицы, их задача отражать модификацию именно блока: <section class="header header_logotype_image">, но данном случае будет мало смысла.

    Будет более верно для ссылки и картинки использовать самостоятельный блок, а для отражения специфичности модификатор, например:

    <!-- .header -->
    <section class="header">
      <div class="container">
        <div class="header__top">
          <div class="header__logotype">
            <a href="#" class="link link_type_header">
               <img src="_tmp/logotype.png" alt="Casino" class="image image_type_header">
            </a>
          </div>
        </div>
      </div>
    </section>
    <!-- /.header -->


    .header {
        &__top {}
        &__logotype {}
    }
    .link {
        &_type {
           &_header {}
        }
    }
    .image {
        &_type {
           &_header {}
        }
    }


    Или использовать микс (на мой взгляд, такой подход поддерживать проще):

    <!-- .header -->
    <section class="header">
      <div class="container">
        <div class="header__top">
          <div class="header__logotype">
            <a href="#" class="header__link link">
              <img src="_tmp/logotype.png" alt="Casino" class="header__image image">
            </a>
          </div>
        </div>
      </div>
    </section>
    <!-- /.header -->


    .header {
        &__top {}
        &__logotype {}
        &__link {}
        &__image {}
    }
    .link {}
    .image {}


    Еще стоит подумать на тем, что логотип может быть не только в шапке, т.е. он может потребоваться в другом контексте, значит его следует реализовать самостоятельным блоком (подробнее об этот тут «Как в принципе отличать, где блок, а где элемент?»).
    Ответ написан
    Комментировать
  • Как по БЭМ написать элемент в блоке с модификатором?

    @ilyarsoftware
    Добавив модификатор к блоку .container--parallax {} можно учитывать его наличие в реализации всех элементов блока .container--parallax .container__title {}.

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


    Добавляя модификатор для элемента .container__title--parallax {} мы сужаем область действия модификации только на элемент.

    Как как именно поступать решать вам, это зависит от потребностей, методология не решает подобные вопросы.
    Ответ написан
    Комментировать
  • Как собирать готовые блоки из компонентов Material Design Light, следуя BEM?

    @ilyarsoftware
    Библиотека MDL применяет БЭМ используя альтернативную схему именования т.н. «Стиль Гарри Робертса».

    Если следовать этой схеме, то надо заменить demo-card-wide на модификатор mdl-card--theme-demo:
    <div class="mdl-card mdl-card--theme-demo mdl-card mdl-shadow--2dp"/>

    Демонстрация

    Важно отметить mdl-card--theme-demo это булев модификатор, в этой схеме именования модификаторы вида «ключ-значение» не используются и они могут существовать отдельно от блока примиксовываясь к другим блокам как mdl-shadow--2dp из примера .
    Ответ написан
    Комментировать
  • Альтернатива html шаблонизотру от Bem?

    @ilyarsoftware
    Любой, а точнее в вашем случае с поддержкой JSON, например NANO, хотя, грубо говоря, ближе к BH/BEMHTML, можно назвать json2html, пример использования json2html с CSS из bem-components:

    var data = [
      {
        'text': 'BEM — BEM Easy Makeup',
        'url': 'https://ru.bem.info/',
      },
    ];
    
    var template = {
      tag: 'a',
      class: 'button button_theme_islands button_size_xl',
      href: '${url}',
      children: [
        {
          tag: 'span',
          class: 'icon icon_social_twitter',
        },
        {
          tag: 'span',
          class: 'button__text',
          html: '${text}',
        },
      ]
    };
    document.body.innerHTML = json2html.transform( data, template );

    Демо на jsfiddle

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

    На текущий момент мне не известно ничего удобнее BH/BEMHTML, но если такой шаблонизатор появится, его опубликуют в разделе bem.info/Проекты на БЭМ.
    Ответ написан
    Комментировать
  • Не перегружает ли style.css пространство имён классов по принципам БЭМ?

    @ilyarsoftware
    БЭМ не догма и только про css, как любой другой паттерн проектирования он помогает управлять сложностью, ограничение которые можно увидеть это субъективное восприятие наблюдателя.

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

    Дополнение по примеру, если nav-theme__name это модификатор со значением name, то следуя классическому наименованию правильно будет nav-menu_theme_name (block_mod_value).

    Соглашение об наименовании является конкретикой и в этом аспекте важно не отходить от договоренностей.

    Дополнительно рекомендую посмотреть https://ru.bem.info/forum/?labels=css

    И все таки использовать глобальные стили (normalize/reset) противоречит прицепу: "Блок — независимый компонент", подробнее: опыт и рекомендация.
    Ответ написан
    Комментировать