11 Matching Annotations
  1. Nov 2019
    1. С точки зрения БЭМ-методологии модификатор не может использоваться в отрыве от модифицируемого блока или элемента. Модификатор должен изменять вид, поведение или состояние сущности, а не заменять ее.Пример<!-- Верно. Блок `search-form` имеет модификатор `theme` со значением `islands`--> <form class="search-form search-form_theme_islands"> <input class="search-form__input"> <button class="search-form__button">Найти</button> </form> <!-- Неверно. Отсутствует модифицируемый класс `search-form` --> <form class="search-form_theme_islands"> <input class="search-form__input"> <button class="search-form__button">Найти</button> </form>

      <form class="search-form search-form_theme_islands"> <input class="search-form__input"> <button class="search-form__button">Найти</button> </form>

      <form class="search-form_theme_islands"> <input class="search-form__input">

  2. Jan 2019
  3. Sep 2015
    1. Nesting for BEM—or any other flavor CSS architecture—is helpful at first, but comes as a cost.

      Useful note on the pros and cons of using SCSS to simplify writing BEM-esque styles in CSS.

      The advice here is to just write out class names in full to make grepping easier.

    1. Useful article on how to apply BEM styling with SCSS as something to point people to.

    2. LESS (and now SASS as well) allow to use & within a single class name. There is no strict requirements on what should be the symbols before and after &. Thus, you can produce simple selectors instead of cascades.

      This is the approach I've started to take for H

    1. Harry Roberts also has a brilliant system for ensuring all CSS keeps to the right naming convention: he lints his CSS using scss-lint to ensure all team members stick to the convention correctly. As Harry put it, “It’s all well and good telling the team to use BEM, but it’s important to police it as well.

      Recommendation for a useful tool to enforce CSS class naming consistency

    2. “Use long, descriptive class names over short names that don’t document themselves.”

      And also when you have only crude tools for refactoring, this makes it easier to refactor CSS class names.

    3. In Yandex we usually separate styles per block, its modifiers, its elements and for their modifiers. But in reality it is very hard to support all these separations. That’s why in pet projects I and ex-Yandexers support a one-file-per-block structure

      One "block" === a "component" in other terminology - as explained on the main BEM site, so this translates to one-file per component

    4. Some useful notes on experiences with BEM-style CSS at scale

    1. This is the main reason we end up with bloated code bases, full of legacy and unknown CSS that we daren't touch. We lack the confidence to be able to work with and modify existing styles because we fear the consequences of CSS' globally operating and leaky nature. Almost all problems with CSS at scale boil down to confidence (or lack thereof): People don't know what things do any more. People daren't make changes because they don't know how far reaching the effects will be.
    1. Recommendations for how to structure blocks (ie. components) which fits in well with recommendations about how to structure components from other places.