Code Monkey home page Code Monkey logo

bem-forum-content-en's People

Contributors

a-lexxx avatar tavriaforever avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

bem-forum-content-en's Issues

Недочеты на главной

  1. EN, RU, UK
    Я подумал : "Чем, интересно в Яндексе UK english отличается от US ?" и нажал. Получил украинский 0_о. Украинский это UA.

  2. Не уверен, но вероятно в UK/US english все таки надо поставить определенный артикль the перед словом domain в фразе в футере:
    Jadwiga and Jacek Duniec thank you for domain!
    У нас конкретный домен вот этого сайта. Он есть, он один и о нем мы пишем благодарность.

  3. Совсем не уверен но если у Яцека фамилия пишется Duniec и он не из UK и не из US и даже не из UA а скорее всего из восточной европы, то U читается как У. [Дунец ?]. Яб спросил самого Яцека.

BEM community development

Here are some latest links that we have found on the topic:

Add yours in comments!

Blocks dependency (modifier)

Hi,
I'm creating simple input with icon.
I have common block for all inputs, named 'input' that is setting padding alongside of another styles, like color, border, etc.
For input with icon, I’ve created another block named ‘input-icon’. In order to create space for the icon, I must override left padding in the input when used in ‘input-icon’ block.
To do this, I’ve created input modifier ‘input—with-icon’.
But now I have tied blocks where if someone uses ‘input-icon’, he must remember to also put ‘input—with-icon’ modifier on the input.
Is there any better way?
Thanks.

<div class="input-icon">
    <span class="input-icon__icon">X</span>
    <input class="input-icon__input input input--with-icon">
</div>
.input {
    padding: 7px 7px;
    /*..*/
}
.input--with-icon {
    padding-left: 30px;
}
.input-icon {
    position: relative;
}
.input-icon__icon {
    position: absolute;
    z-index: 1;
    left: 7px;
    /* .. */
}

emmet for BEMJSON

There was a thread recently in Russian on using BEM in medium-sized projects written by Nikolay Gromov who complained that writing BEMJSON requires more time than writing HTML with a help of emmet.

I don't feel the same way about time spent on writing code not in percentage relating to time spent on debugging and thinking over not in absolute terms but I thought that spending time for writing analogue for emmet for BEMJSON is good enough task to spend an evening.

It is how this package bemmet emerged that can expand abbreviations like b1>__e1*2>b3_theme_islands+_state_active{hello} into BEMJSON:

{
    block: 'b1',
    content: [
        {
            block: 'b1',
            elem: 'e1',
            content: [
                {
                    block: 'b3',
                    mods: { theme: 'islands' },
                    content: {}
                },
                {
                    block: 'b1',
                    mods: { state: 'active' },
                    content: 'hello'
                }
            ]
        },
        {
            block: 'b1',
            elem: 'e1',
            content: [
                {
                    block: 'b3',
                    mods: { theme: 'islands' },
                    content: {}
                },
                {
                    block: 'b1',
                    mods: { state: 'active' },
                    content: 'hello'
                }
            ]
        }
    ]
}

Using options you can configure custom naming — powered by bem-naming.
stringify() method supports indentation options and quotes — powered by stringify-object.

You can try bemmet in action using online demo. You can also install it right away into your editor using plugins for Sublime Text and Atom.

Would be nice if you can commit with plugins for some other editors.

Good luck!

Shortly about BEM

1. Naming convention

In terms of convention we used to use dashes as word separators, two underscores to separate elements and one underscore for modifier and it's value:

  • block-name
  • block-name__some-elem
  • block-name_mod-name_mod-value
  • block-name__some-elem_elemmod-name_elemmod-value

But it worth nothing to use any other style. We even have special library to abstract from naming.

More about naming convention: https://github.com/bem/bem-naming#custom-naming-convention

2. Going beyond naming convention

Naming convention is important but UI component is more than just a piece of CSS.

All methodologies for CSS could be considered as a subset of BEM. But they tell nothing about how to implement other pieces: JS, templates, images, specs, documentation (and its translation to different languages), etc.

BEM as methodology does.

3. Component approach

Actualy it's not something absolutely unique nowadays.
We already have Web components as a standard speaking almost about the same:

  • Split interface into independent blocks
  • Each block knows everything about itself and hides it's inner implementation
  • Declarative way to describe components

All these questions are solved in BEM without any polyfills. But what's much more important all these things are easy to use and tested in production on a lot of services with a really huge scale (in all sences of this word).

4. What's inside

4.1. DOM abstraction

DOM is too low level thing. It's like an assembler for browsers. We need to provide developers with high level abstraction. In BEM it's called BEM tree.

CSS and JS implementation of the block and it's templates work with it's elements. And for other blocks we provide API to work with.

So instead of waiting for shadow DOM roots to grow we just use current DOM tree for inner implementation of components.

4.2. Mixes

Mixes is a concept of having few different entities on the same DOM node. That gives a possibility to separate semantically different code:

<div class="header__user user link"> — it's simultaneously user element of a header block, user block itself and also a link to use profile.

4.3. File system

Each block get's it's own folder. And all techs of the block — their own files. Modifiers and elements may also be separated into different folders to provide possibility to build just the parts files we need.

Example:

blocks/
    b1/
        b1.css
        b1.js
    b2/
        __elem1/
            b2__elem1.css
        b2.css
        b2.js
        b2.en.md
        b2.ru.md
        b2.spec.js
        b2.png

4.4. Build

BEM tree works as a declaration to build final runtime upon.

Example:

Consider following BEM tree:

<page>
    <b1>
        <b1__e1>
   </b1>
</page>

or the same in JS:

{
    block: 'page', content: {
        block: b1, content: {
            elem: 'e1'
        }
    }
}

Now we can collect all the entities mentioned in this declaration to get all the files from block folder and concat them together.

4.5. Levels of redefinition

With such approach we can build entire library of components for all the purposes (and we actualy did ;)

But it's impossible to meet all the needs. So end users will face situation when they need to change something. Of course they always may edit the source of the library, add modifiers and mix new blocks to old ones to make them look and work as they need. But first option result in a pain when you are to update library version and others require quite a lot of efforts.

But because of declarative nature of blocks implementation we can just put our code in our own block folder and ask build system to concat files from there after library files:

library/
    blocks/
        b1/
            b1.css
                .b1 { width: 100px; color: red; }
project/
    blocks/
        b1/
            b1.css
                .b1 { color: green; }
    pages/
        page/
            page.css
                @import url(../../../library/blocks/b1/b1.css);
                @import url(../../blocks/blocks/b1/b1.css);

So we end up with b1 which is still 100px wide as in library but is green according to our company guidelines.

Absolutely the same approach is used for JS and templates. So developer may get some levels (layers) from a list of block libraries, decide which levels are needed for particular project, then add some specific code on project's level and update source libraries as easy as run bower update.

5. Implementation

At Yandex we implemented and open sourced a full stack of tools written in node.js to work with BEM methodoly as well as JS framework (it uses jQuery under the hood) and template engines operating in BEM terms and some block libraries on top of it.

Quite a lot of companies in CIS in addition to Yandex are already using it and we can confidently say there's no interface tasks which can not be splited into blocks-elements-modifiers.

Repetition in BEM

Hello,

I've adopted the directory organization where each block and element have their own directories.
The problem with this apprach is that when I have a style like this:

.tile__icon-wrapper,
.tile__textual-part {
    display: table-cell;
    vertical-align: middle;
}

I do not have a choice but to repeat the same style definition in both tile__icon-wrapper.sass and tile__textual-part.sass.

Is there a sensible way to get rid of this redundant repetition and still adhere to BEM's principles?

Доопределение библиотечного ym-модуля

Как правильно переопределить модуль, если он не только без DOM-представления, но и вовсе сделан на "чистом" ym?

Предположим, хочу доопределить метод querystring.parse из bem-components. Пока решил так:

modules.define('querystring2', ['querystring', 'objects'], function(provide, querystring, objects) {

var querystring2 = objects.extend(null, querystring, /** @exports */ {

    /**
     * Дополняем станадртную ф-цию parse
     * @param {string} str
     * @returns {object}
     */
    parse : function (str) {
        // Удаляем символ '?' в начале строки
        if ( typeof str === 'string' && str.indexOf('?') === 0 ) {
            str = str.substr(1);
        }
        return querystring.parse(str);
    },

});

provide(querystring2);

});

Есть ли более грамотный способ? Есть ли способ доопределить исходный модуль (декларировать под тем же именем)?

Смотрел:

(Не вижу тега ymodules. Вроде был раньше?..)

Correct use of Mix?

Hello everyone,
Just started with BEM and was a bit stuck on how to use it the right way, I have the following code:

<header class="header">
  <div class="header__logo">logo</div>
  <div  class="header__navigation">
    <nav class="header__navigation main-menu">
      <ul class="main-menu">
        <li class="main-menu__list">
          <a href="" class="main-menu__link">link</a>
        </li>
        <li class="main-menu__list">
          <a href="" class="main-menu__link--active">link</a>
        </li>
        <li class="main-menu__list">
          <a href="" class="main-menu__link">link</a>
        </li>
      </ul>
    </nav>
  </div>
</header>

Is this the correct use of BEM? As I understand not to nest too deep, so if I wanted to have a new block within an element you can use the mix feature?

Also I wanted to keep .main-menu reusable so I can move the main menu from the header to the sidebar if needed one day.

I hope I got it right :)

How to approach BEM in a modular way?

The thinner the footprint the better.
Without all the heavy lifters like enb, only bem-tools maybe.

This is what I try:

npm install -g bem
mkdir bem-playground
cd bem-playground
bem create level my-blocks
bem create -b foo-block -l my-blocks -t <WHAT TYPE TO START WITH?>

html type is deprecated, list of types, I guess, is here: https://github.com/bem/bem-tools/tree/master/lib/techs/v2
Default types are empty so no block is created without -t.

Ok, I can create block manually. But what's next?
To assemble blocks into a page, I guess, I need some bemdecl and some assembler (enb again).
So I can't escape complexity footprint of enb onto my stack, right?

How to format...

the posts in this forum? i want to post a question but can't find any description on how about to format my html code for better readability.

Configuration to have html not minified in tools

Hello I am going through the quickstart tutorial. One of the first things I noticed on getting it running is that the HTML generated is all on one line. I am looking for a way to have it display in a readable way. I have looked at enb-borschik>techs>borschik.js and have tried commenting out:
line 69:
.defineOption('minify', true)
line 85:
minimize: this._minify,
and restarted the server, but still seeing it compressed to one line. please let me know what to change to fix this. Thank You

In or out

The first example is strict bem, the second one less. Which of the following examples is more bullet-proofed (browser compatible, code readability, reusable etc.) :

<div class="block">
    <h1 class="block__headline">Headline</h1>
</div>

or

<div class="block">
    <div class="block__headline">
        <h1>Headline</h1>
    </div>
</div>

BEM examples and performance

  1. Any well-known websites use BEM, other than Yandex?
  2. In BEM, each block on a page has their own css file, would this increase the page loading time?

Many thanks!

Add CSS and JS that is not block-related using BEMHTML

Hello!

I've been using the BEM approach for front-end web development a couple of years now (and it's just great!) but only yesterday I started to try out the BEMHTML template language. So far I like it a lot!

There's a couple of things though that I can't yet wrap my head around and can't find anything about in the docs either. So I hope to have some more luck here and hopefully also help others that might be facing the same problems.

Basically I would like to know how to be able to add custom CSS for a webpage that isn't directly block related. For example declarations for webfonts, normalize/reset css code, etc. I would still like to be able to use Stylus as preprocessor and have bem-tools generate and minify this CSS together with my blocks' CSS.

The same question goes for JS. What is the correct way to add JS libraries and custom JS code, preferably maintaining the possibility to have this combined/concatenated with the block level JS?

Thanks! :)

name of 'BEM 101'

Sometimes people write "BEM", sometimes "BEM 101". It's obvious what "BEM" comes from. But what is the source of "101" in the name..? I am so curious :)

BEM Forum goes live!

Hi everyone,

We are ready to launch our BEM forum — a place where developers working with BEM can get together, share their experiences and ask questions directly to the BEM team.

Little bit of history

We wanted to have our own communication platform for a long time.

Before we launched BEM forum on bem.info for Russian language community in August 2014 we had to monitor a lot of social media platforms such as twitter, Yandex blog platform, facebook, in order not to miss your questions.

At the same time Yandex was shutting down it's blog platform, and that decision forced us to launch the forum.

We carefully planned it, have chosen github to host everything as well as to login through and we went live as well as moved in to github 5 years of blogging history that we wanted to keep.

We were worried from the beginning that useful channels of communication will still prevail, and developers continue to ask questions everywhere and not here that is time consuming in terms of search and not usefull at all for archiving the history for the sake of future users.

But forum proved us wrong: the number of posts grew up every month, and it is about 40 posts (issues) per month now.

Inside the forum

As we do almost everything in open source, forum is an open sourced platform too. This means we encourage you to use it in your home projects and report bugs.

The repository could be found here. Local copy installation instruction is in it's readme file.

Forum's architecture allows using it well as a separate service and as a route for express. We use it in a second capacity — it is a part of bem.info site.

We use github API as a source of data, node.js for backend and full stack of BEM (BEMTREE, BEMHTML, i-bem.js) for frontend.

Right now it is possible on BEM forum to open a topic, comment it and filter posts using labels. We already made few necessary for you there. And if you lack one or have a question regarding the work of the forum, just open a topic and mark it with "bem-forum" label.

Every post is an issue on github that we browse on the site. This scheme allows communicating via forum having what developers already have — github login.

Attention: we ask you to use our forum via bem.info interface, because here you can have it labeled and found by others.

All you need to start using BEM forum is to authorize via oAuth using your github login.

Start writing your first post right now! We as a BEM team and guys from the community monitor user questions all the time and answer them right away.

We also hope you open our eyes on the problems English language developers have with BEM (anything from documentation to demos, from installation to use cases). Just mark such posts with "bug" label. It will be a lot of a help!

Let's get started with BEM forum!

Struggling with correct BEM naming on third level

Hi there.. i'm just beginning with BEM and love the concept but struggling a bit around with nested blocks. I want to build some kind of responsive teaser with a few elements inside.

This is what my html looks like:

<div class="teaser">
  
  <div class="teaser__background">
    <picture></picture>
  </div>

  <div class="teaser__featured-product"></div>

  <div class="teaser-content"> <!-- what about this correct naming and its children-elements? -->

    <div class="teaser-titles"> <!--same question here -->
      <p class="teaser-title__overline"></p>
      <h1 class="teaser-title__headline"></h1>
      <h2 class="teaser-title__subline"></h2>
    </div>

    <div class="teaser-content__text">
      <p>Lorem ipsum..</p>
    </div>

    <div class="teaser-content__legal">
      <p>1) Some terms...</p>
    </div>

    <div class="teaser-content__manufacturer-logo"></div>

  </div>

  <div class="teaser__ribbon"></div>

</div>

Inside of teaser I want to keep my content together in one block teaser-content for better positioning. So what would be the correct naming for the teaser-content-wrapper and then the following child-element teaser-titles?

I thought about a bit different version for example:

<div class="teaser-content">

    <!-- <div class="teaser-titles"> --> <!-- maybe we don't need it? -->
      <p class="teaser__title teaser__title--overline"></p>
      <h1 class="teaser__title teaser__title--headline"></h1>
      <h2 class="teaser__title teaser__title--subline"></h2>
    <!-- </div> -->

But questions are still the same. Hope really you can help me because this drives me crazy.

Greetings from the rainy Hamburg (Germany)

Answers for daily use of BEM for CSS/JS

Hi, some time ago jQuery team asked us about BEM, and we cleared a lot of points for them. Answers are quite useful, so we decided to publish them free.

1. How easily is BEM kept maintainable long term?

Easy maintenance is what BEM was invented for.

Actually all the issues with CSS maintenance are because of cascade and strong coupling of components. And BEM is all about independence of blocks and reducing cascade to minimum level.

We have a lot of real experience with BEM on our portal and it proved to be a great solution.

Example 1.

ul a {
    position: absolute;
}

won't work as soon as you'll get second level of nesting for lists.

Example 2.

Considering menu can't have any other list items:

ul.menu li {
    ...
}

and then some components with own dropdown with own menu appear in list item.

2. The long class names can come off a bit intimidating and unfriendly for beginners using BEM. What is the justification behind the longer names? As it is now, we already have many people complaining when we use ui-button for a class name instead of btn, because the former is too long.

Well, BEM does not restrict usage of btn instead of button ;)
You can consider any naming strategy you want.
E.g.: context or ctx or c, attributes or attrs or as.

The choose is yours — BEM doesn't srink you.

There is still some "problem" with elements and modifiers, i.e. btn__txt and btn_hvrd, but we strongly believe that there's no real problem in typing. And of course there's no problem with kilobytes due to gzip. But what is really important for huge rapid projects which live for a long time is code readability and self-descriptive names of components is just a must.

Not so cool for common block library with a huge amount of users.

3. The namespacing decisions in general - members of our community would like a greater explanation of this.

That was something odd when we invented BEM. But right now that's a common idea:
OOCSS, Atomic CSS, etc. and web components standard try to hide internal world of a block from other ones. Web components use shadow DOM, BEM uses namespacing to achieve the same result but without necessity to wait for support from browsers or any additional JS.

Historical reason of having namespaces for modifiers is that joined selectors like .a.b were not supported in old browsers. Not it's not a restriction but in BEM there's also a concept of mixes — possibility to have a few different entities on the same DOM node. And namespaces help to distinguish modifier of which block is it.

Without mixes it's possible to have .btn._hvrd but we are sure that mixes are useful thing.

But what is often left in shadow is possibility to mix different entities on the same DOM node. E.g. it's possible to have <input class="input form__login"> which means we've got an input block (can be reused somewhere else) and login element of form block at the same time. So everything about abstract input will be provided by .input selector and things like margins, etc — with .form__login.

4. Neutering the Cascading potential of CSS code by making everything overly specific.

Yes, that looks strange at the first sight but soon you'll find it very convenient.
Cascade is cool for fast write-and-throw-away approach. But when we need bullet proof reusable components it just doesn't work.

Cascade creates strong coupling and results in impossibility to reuse such code.

5. The arbitrary distinction between blocks and elements.

Let's look at JS (actually OOP) analogy. JS class point [x, y] is just a field of Figure class or one more class Point.
If it has a lot of methods it's most likely a class by its own. Otherwise field is enough.
The same is for blocks and elements. It's always for your consideration.

With practice that's easier than it looks. When an entity is impossible without its parent — that's an element. When you find yourself trying to reuse an element somewhere in a project without its parent and inner complexity of element became bigger — that's a standalone block.

But what is often left in shadow is possibility to mix different entities on the same DOM node. E.g. it's possible to have <input class="input form__login"> which means we've got an input block (can be reused somewhere else) and login element of form block at the same time. So everything about abstract input will be provided by .input selector and things like margins, etc — with .form__login.

Nested elements or new block?

Hello, I'm new to BEM and I want to get opinion on something, so lets say I have blog post, in blog post we have title, badge, summary, figure ... below is the example of my html

    <div class="post">
        <h1 class="post__title">This is title</h1> 
        <summary class="post__summary">
            Some text here
        </summary>
        <figure class="post__figure figure">
            <img class="figure__image" src="">  
            <figcaption class="figure__caption">Some text</div> 
        </figure>
    </div>

So should I do .post_figure and then inside .post__figure__image and .post__figure__caption or should i create new block like in example?

Updated BEM form mark-up,

Before (attempting) to use BEM, I'd mark my forms up something like this:

<form> 

    <h3 class="title">Form Heading <small>(if small tag is added)</small></h3>
    <p>Short paragraph of text...</p>

    <div class="form-group">
        <label class="label">Username <em>*</em></label>
        <div class="form-controls">
            <input type="text" />
        </div>
    </div>
    <div class="form-group error">
        <label class="label">Email address <em>*</em></label>
        <div class="form-controls">
            <input type="text" />
        </div>
    </div>
    <div class="form-group">
        <label class="label">Label</label>
        <div class="form-controls">
            <input type="text"  placeholder="" />
        </div>
    </div>
    <div class="form-group">
        <label class="label">Label</label>
        <div class="form-controls">
            <label class="radio"><input type="radio" name="radio" checked="checked" /> Option One</label>
            <label class="radio"><input type="radio" name="radio" /> Option Two</label>
        </div>
    </div>

</form>

It seems, obvious to use form__group instead of form-group and form__controls instead of form-controls. Using elements like this, the form would NEED a class of form on it - otherwise it makes no sense? Seems a bit strange on a default element though, I've not used <ul class="list"> for example, just <ul class="list--bordered"> for example.

I've created some quick, updated mark-up below, would this be acceptable?

<form class="form"> 

    <h3 class="form__title">Form Heading <small>(if small tag is added)</small></h3>
    <p>Short paragraph of text...</p>

    <div class="form__group">
        <label class="form__group-title">Username <em>*</em></label>
        <div class="form__controls">
            <input type="text" />
        </div>
    </div>
    <div class="form__group error">
        <label class="form__group-title">Email address <em>*</em></label>
        <div class="form__controls">
            <input type="text" />
        </div>
    </div>
    <div class="form__group">
        <label class="form__group-title">Label</label>
        <div class="form__controls">
            <input type="text"  placeholder="" />
        </div>
    </div>
    <div class="form__group">
        <label class="form__group-title">Label</label>
        <div class="form__controls">
            <label class="form__radio"><input type="radio" name="radio" checked="checked" /> Option One</label>
            <label class="form__radio"><input type="radio" name="radio" /> Option Two</label>
        </div>
    </div>

</form>

Thanks again!

Multiple Classes vs Mixins

I was wondering why you chose to define an element entirely using classes in the HTML instead of breaking shared functionality into placeholders / mixins (to use Sass as an example). Is it because you don't use a preprocessor?

If we take the example of a list, it might look like:

<ul class="ui-list horizontal-list resource-list gallery-list"></ul>

In this situation, why is this better than a single class:

<ul class="gallery-list"></ul>

With that class composed from placeholders:

.gallery-list {
  @extend %ui-list;
  @extend %horizontal-list;
  @extend %resource-list;

  // Gallery List specific styles
}

Do you see this as potentially beneficial?

BEM: digest

Hi everybody,

Briefly about the main events in the BEM world over the last 4 months with the beginning of the year.

Libraries news

  • RC of the next major release of bem-core — 4.0.0-rc.1. The main changes concerned the improvement of i-bem.js. If you are ready — you can check this release on your projects. The stable version will be released soon. Don't forget to tell us about all the detected bugs.
  • major version of bem-components 3.0.0 that works with bem-core 3.0.1. Despite the fact that the release is major, update should be painless.
  • bem-history 3.2.0. The main change is a support for bem-core 3.x in bower.json. And, of course, a few bug fixes included.
  • renamed the organization bem-incubtaror in bem-contrib. New name much better reflects the organization's mission. If you use (or develop) any packages, you should update the paths to the repository (some time github supports redirects automatically). You can use the user manual.

Technology news

  • released two major and dozens of minor releases bem-xjst. The latest version is 6.5.1 Key changes:
    • BEMTREE
    • implemented support for ES6 arrow functions
    • made optional content escaping
    • supported JS-binding for elements
    • made mode to render the HTML without the /:
      instead of
    • removed some deprecated methods and functions.

Read more about all the changes in the release notes, which are written in detail to each release: https://github.com/bem/bem-xjst/releases.

Tools

Released ENB 1.3

Worked on the plugins for the ENB:

Site news

  • recently, we have partially updated our website bem.info — it became more modern, fast and beautiful
  • rolled out the Ukrainian version https://uk.bem.info, the translations into other languages will appear soon.

Events (only in Russian)

  • tadatuta@ held a webinar on three-tier architecture services on bem-xjst
  • Did two reports on Yandex.Subbotnik (frontend conference): https://events.yandex.ru/events/yasubbotnik/27-feb-2016/
  • Held another hackathon at the BEM, advanced modular Assembly and came up with a way to make friends BEMHTML-templates with React.

Interesting on the forum (in Russian)

Thank's and stay BEM'ed!

bem-element outside the bem-block and block-elements intersection in DOM tree

AFAIK, somewhere I have seen proof of the following things. Please confirm or disprove.

  1. As DOM-tree and BEM-tree aren't required be the same, it's possible that the BEM-element is physically located outside its BEM-block in DOM and it is valid.
<div class="block">
…
</div>
<div class="block__element"> … </div>
  1. For the same reason the elements of one block can be nested in another block, making intersection in the DOM-tree like:
.block1
     .block2
         .block1__el
         .block2__el

or even like this:

.block1
     .block2
         .block1__el
             .block2__el

Different blocks or modified blocks?

Hi,

I have a big disscusson with my colleague and would love to get your feedback.

I am building a website and have seen some areas, wich are reusable. They share the same HTML construct and looks similar. Example:

<header>
    <nav class="navigation navigation_main">
        <ul class="navigation__list">
            <li class="navigation__item"><a class="navigation__link">Item 1</a></li>
            <li class="navigation__item"><a class="navigation__link">Item 2</a></li>
            <li class="navigation__item"><a class="navigation__link">Item 3</a></li>
        </ul>
        </nav>
        <nav class="navigation navigation_meta">
            <ul class="navigation__list">
                <li class="navigation__item"><a class="navigation__link"><span class="svg-icon svg-icon_search"></span></a></li>
                <li class="navigation__item navigation__item_active"><a class="navigation__link">DE</a></li>
                <li class="navigation__item"><a class="navigation__link">EN</a></li>
            </ul>
    </nav>
</header>

My colleague says, that the navigations have to be named different:

<header>
    <nav class="main-navigation">
        <ul class="main-navigation__list">
            <li class="main-navigation__item"><a class="main-navigation__link">Item 1</a></li>
            <li class="main-navigation__item"><a class="main-navigation__link">Item 2</a></li>
            <li class="main-navigation__item"><a class="main-navigation__link">Item 3</a></li>
        </ul>
    </nav>
    <nav class="meta-navigation">
        <ul class="meta-navigation__list">
            <li class="meta-navigation__item"><a class="meta-navigation__link"><span class="svg-icon svg-icon_search"></span></a></li>
            <li class="meta-navigation__item meta-navigation__item_active"><a class="meta-navigation__link">DE</a></li>
            <li class="meta-navigation__item"><a class="meta-navigation__link">EN</a></li>
        </ul>
    </nav>
</header>

The navigations (there are some additional navigation in the footer and for social media icons, too) looks very similar. They differ in font size and paddings/margins. I see great advance in the first solution, because it is very modular and reusable. The end code is smaller. My colleague says, nesting (i.e. .navigation_meta .navigation__item{}) is evil and should be avoided, whenever possible (i.e .meta-navigation__item{}).

Who is right?

How to avoid specificity with modifiers

Hi all!

I've an issue with triple modifiers and I can't resolve without combine classes selectors :S.
I have this button block:

<!--Button Block-->
<button type="button" class="button button--main button--outlined button--disabled">Ok</button>

and css (I remove some properties to save space in the post)

.button--filled,
.button {
  color: white;
  background-color: blue;
  box-shadow:none;
}

.button--main {
  font-size: 26px;
}

.button--outlined {
  background-color: transparent;
  box-shadow:inset 0px 0px 0px 4px blue;
}

Now I need a button--disabled modifier to shade to gray the button appeareance, but really I need two button--disabled because I need to shade to gray the border if button--outlined is used or the background if button--filled is used.

Do I need outlined and filled buttons in two separate blocks?

Thanks you! :)

What a bunch of BS

srsly another BS drone rule made up by bloggers like the PSR crap and the retarded one with the commas at the beggining of the line in javascript.
LET THE CODERS CODE LIKE THEY WANT and stfu

BEM and blocks size

Hello!

I'm newbie in BEM and trying to use it in my workflow but I'm not sure how solve that problem.

I would like to create simple layout and position all elements i.e. something like this:

<div class="main-window">
    <div class="gallery">
        <!-- Here is gallery content -->
    </div>
    <div class="story">
        <!-- Here is story content -->
    </div>
</div>

Should I style .gallery and .story with position and dimension properties or maybe should I nest them in .main-window elements. Something like that:

<div class="main-window">
    <div class="main-window__gallery-wrapper>
        <div class="gallery">
            <!-- Here is gallery content -->
        </div>
    </div>
    <div class="main-window__story-wrapper>
        <div class="gallery">
            <!-- Here is story content -->
        </div>
    </div></div>

Now I can separate .gallery and .story styling from their position because I can define size and position with .main-window elements

.main-window__gallery-wrapper {
    width: 500px;
    margin: 0 auto;
}
.gallery {
    /* formatting without size and position */
}
.main-window__story-wrapper {
    width: 500px;
    margin: 30px auto;
}
.story {
    /* formatting without size and position */
}

Sorry for (probably) such a simple question but I didn't find answer for that.

Thanks.

BEM + Polymer = ?

Can I mix Polymer and BEM (techs, tools, everything behind the methodology)? Does it worth it?

Ok, I've made a feature comparison table.
I need it to figure out if one technology can supplement another, not to downplay one of them.

Feature BEM Polymer
Syntax conventions (for B, E, M) yes no, use BEM
Decomposition into components ENB assembler (*) HTML Imports / webcomponents.js
# of requests reduction ENB assembler (*) vulcanize
CSS encapsulation upper boundary (*) upper boundary, lower for Native Shadow DOM (unstable)
Component redefinition yes, orginized in levels, ENB? (*) limited: extend native tags, inherit javascript definitions (behaviors), more is planned
File structure organization yes, B,E,M, techs no, use BEM
Techs support (templates, transpilers) yes server-side preprocessing (e.g. w/ gulp), client-side may be hindered

(*) = I guess so

gemini навигация

Добрый день,

Подскажите пожалуйста как производить навигацию между страницами. Так сложилось что мне сначала нужно зайти на url для авторизации и потом зайти на другой где собственно уже и производить тест.
Пытался найти есть ли возможность работать в gemini с навигацией в браузере из коробки. Как я понял нету, т.к. в кол бэк возможно передать только actions и find/
Вторым вызовом suite.setUrl() поменять урл на другой не вышло.
С нестед сьютами так же не выходит. Возможно я не так их применял ниже код:

parent.setUrl('first url')
.setCaptureElements('element');
gemini.suite('first child', function (child) {
//this suite captures same elements on different pages
child.setUrl('secondUrl')
.capture('plain');
Заранее спасибо за любую помощь.

Как правильно размечать/именовать?

Приветствую!

Как избежать большого кол-ва элементов от 1 блока? Проблема возникает, когда много элементов в блоке, но нужно сохранить зависимость от родительского блока.

Sample

  <section class="meet-us">
    <div class="container">
      <h3 class="meet-us__title heading-3">Meet Us</h3>
      <div class="meet-us__items">
        <div class="meet-us__item">
          <img class="meet-us__img" src="img/team-1.jpg" width="269" height="355" alt="Team member">
          <div class="meet-us__info">
            <h5 class="meet-us__name">Kirkorov</h5>
            <p class="meet-us__metier">Babo-pinatel</p>
            <div class="meet-us__social"> <!--  overlay/display:none -->
              <a href="#" class="meet-us__link">
                <svg class="meet-us__icon">
                  <use xlink:href="img/icons.svg#behance"></use>
                </svg>
              </a>
              <a href="#" class="meet-us__link">
                <svg class="meet-us__icon">
                  <use xlink:href="img/icons.svg#facebook"></use>
                </svg>
              </a>
              <a href="#" class="meet-us__link">
                <svg class="meet-us__icon">
                  <use xlink:href="img/icons.svg#twitter"></use>
                </svg>
              </a>
            </div>
          </div>
        </div>
        <div class="meet-us__item">
          <img class="meet-us__img" src="img/team-2.jpg" width="269" height="355" alt="Team member">
          <div class="meet-us__info">
            <h5 class="meet-us__name">Putin</h5>
            <p class="meet-us__metier">reshala</p>
            <div class="meet-us__social">
              <a href="#" class="meet-us__link">
                <svg class="meet-us__icon">
                  <use xlink:href="img/icons.svg#behance"></use>
                </svg>
              </a>
              <a href="#" class="meet-us__link">
                <svg class="meet-us__icon">
                  <use xlink:href="img/icons.svg#facebook"></use>
                </svg>
              </a>
              <a href="#" class="meet-us__link">
                <svg class="meet-us__icon">
                  <use xlink:href="img/icons.svg#twitter"></use>
                </svg>
              </a>
            </div>
          </div>
        </div>
      </div>
    </div>
  </section>

Вместо:

<div class="meet-us__item">
и далее...

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

        <div class="card">
          <img class="card__img" src="" alt="">
          <div class="card__info">
            <h5 class="card__name">Nam</h5>
            <p class="card__metier">Profession</p>
            <div class="social card__social">  <!-- Тут ещё один блок social  -->
              <a href="#" class="social__link">
                <svg class="social__icon">
                  <use xlink:href="img/icons.svg#behance"></use>
                </svg>
              </a>
              <a href="#" class="social__link">
                <svg class="social__icon">
                  <use xlink:href="img/icons.svg#facebook"></use>
                </svg>
              </a>
              <a href="#" class="social__link">
                <svg class="social__icon">
                  <use xlink:href="img/icons.svg#twitter"></use>
                </svg>
              </a>
            </div>
          </div>
        </div>
  1. Правильно ли я разметил по БЭМ-у в 1 примере?
  2. Как мне сохранить зависимость/наследование/связь от родительского блока, то есть meet-us, или если я блок card вставлю внутри meet-us__item, то от него.
    Добавлять к блоку card второй класс meet-us__card? И как вообще правильно делать?)

Ещё где-то я видел в исходниках какого-то сайта примерно такое:

<div class="block">
  <div class="block__items">
    <div class="block__item">
      <h3 class="block__item-title">BEM</h3>
      <p class="block__item-text">BEM is wow</p>
      <div class="block__item-media">
        <img src="" alt="" class="block__item-img">
      </div>
      <div class="block__item-social">ya.ru</div>
      <div class="block__item-action">More</div>
    </div>
  </div>
</div>

Как вариант?

И видели ли документацию mdl (Material design light)?
Пример:

<ul class="demo-list-two mdl-list">
  <li class="mdl-list__item mdl-list__item--two-line">
    <span class="mdl-list__item-primary-content">
      <i class="material-icons mdl-list__item-avatar">person</i>
      <span>Bryan Cranston</span>
      <span class="mdl-list__item-sub-title">62 Episodes</span>
    </span>
    <span class="mdl-list__item-secondary-content">
      <span class="mdl-list__item-secondary-info">Actor</span>
      <a class="mdl-list__item-secondary-action" href="#"><i class="material-icons">star</i></a>
    </span>
  </li>
</ul>

Я просто в документации такого рода примера не заметил или пропустил, верно ли так? Вместо mdl-list__avatar, они пишут: mdl-list__item-avatar, и вообще от элемента mdl-list__item, они создают несколько блоков ниже, они так сохраняют связь, логику от имени item, но правильно ли это, или они так интерпретируют BEM под себя? Это хороший пример, когда много блоков/а точнее элементов внутри.
Например, в моём первом примере уже есть meet-us__title, я всё от блока meet-us и размечал, элементами, а вдруг внутри meet-us__item у меня завтра появится ещё заголовок, я уже не смогу написать meet-us__title, так как занято, могу конечно написать meet-us__heading, а гугл в (MDL) написал бы meet-us__item-title, они так избегают элемент в элементе - meet-us__item__title, правильно ли будет делать так как они?

Спасибо.

Русская версия форума у меня не работает, ошибка 500, а до этого пост не мог написать, как и на английской версии, поэтому пишу тут.

BEM news digest

Brief news about the BEM world since the beginning of this year:

Documentation news

Site news

Rolled out the BEM libraries section in a new design on bem.info:

Libraries news

bem-core

  • Released bem-core 4.1.0 and 4.1.1. All changes of the both releases are described in a CHANGELOG.

bem-components

  • Released bem-components v4.0.0 with update of controls design and with the transition from the Stylus to postCSS.
  • Released bem-components 5.0.0 that used bem-core 4.1.1. There are two style sets in v5.0.0: source files with postCSS and compiled CSS in case you prefer to use some preprocessor.

bem-history

  • Not yet released but is already used in a separate branch v4. This version is compatible with bem-core v4. Feel free to try, revise and send us a feedback before we release a new version.
    The major change is rename of uri block to uri__querystring element, which extends the basic implementation of the same name module in bem-core with Uri class. Class methods remained unchanged.

bem-react-core

Technologies news

bem-express

Released the following major updates:

  • Updated bem-core to 4.1.1 and bem-components to 5.0.0.
  • Began to use PostCSS instead of Stylus. We provide the same set of plugins that bem-components has.
  • Implemented an optional livereload. For details read the documentation and [README](https://github.com/bem /bem-express/blob/master/README.md) of the project.
  • Achieved the speed acceleration of the build procedure by updating npm-modules required for assembly.
  • Abandoned bower to supply libraries. Now all dependencies are set through npm in node_modules directory.

bem-xjst

  • v8.3.1 (v7.4.1)

    • extend() mode fixed. Now it works as expected.
    • Documentation updated: this.extend(o1, o2) description added.
  • v8.4.0 (v7.6.0)

    • New unquotedAttrs option allows us to ommit unnececary quotes of HTML attributes in some cases.
  • v8.4.1 (v7.6.1)

    • extend(function(ctx, json) { … }) mode callback now have two arguments, the same as have the callbacks of other modes. The first argument is a link to context of (this) template execution. The second — link to a BEMJSON node.
  • v8.4.2

    • Escaping functions fixed: now argumengs undefined or null and NaN will give you empty string as a result. In previous versions you get stringified results ('undefined', 'null', 'NaN').
  • v8.5.0

    • BEMTREE: added modes related to data: js(), addJs(), mix(), addMix(), mods(), addElemMods(), elemMods(). The rest of the modes that are relevant only to-HTML are available in BEMHTML.
  • v8.5.1

    • Fixed bug: calculate position if block/elem was replaced via replace().
  • v8.5.2 (v7.6.4)

    • Fixed bug in BEMTREE related to the rendering of special value field content { html: '<unescaped value>' }.
    • bem-xjst onlinе demo updated:
      • Added a switch of BEMHTML/BEMTREE engines.
      • Added a plug for BEM.I18N (), which returns its second argument. This is useful to copy the code from production to a sandbox.
    • README updated.
    • A sandbox updated. You could help our projest to fix issues with help wanted lable.

enb-bemxjst

  • Released a new version of enb-bemxjst v8.5.2 with "dependencies": { "bem-xjst": "8.5.2" }. However, we continue to actively support the both branches: 7.x and 8.x.

All changes are described in releas notes v8.5.2 and v7.6.4 and in a CHANGELOG.

BEM toolbox news

bem-tools

Released bem-tools 2.0.0 with updated bem-tools-create. Detailed description is in README.

bem-walk

Wrote a full and clear README.

project-stub

Ok to use descendant selector for common elements?

Hi there,

I know one of the benefits of BEM is not having to nest styles but I was wondering when is it ok to do so? Sometimes it's unavoidable and sometimes maybe more practical to do so?

In the example I'm working on I have bands/stripes than contain blocks of content, these bands can be different colours (black, white, blue). I achieve this by having a base class of <div class="band">, which the band is black the following class is added: <div class="band band--black">. For obvious readability issues the content of a darker block will need to be coloured differently, the headings white, paragraphs/lists a lighter grey and maybe even a subtle lightening of the anchor colour. It'd be a pain to apply classes to everything, especially if different content mark-up appears on different pages. So is it acceptable to write the CSS like this (using SCSS):

.band--black {
    h1,
    h2,
    h3,
    h4 {
        color: rgb(255,255,255);
    }

    p,
    ul,
    ol {
        color: color: rgb(200,200,200);
    }
}

or even this, which might be able to keep track of, keeping the colour changes grouped together:

h1,
h2,
h3,
h4 {
    .band--dark & {
        color: rgb(255,255,255);
    }
}

p,
ul,
ol {
    .band--dark & {
        color: rgb(200,200,200);
    }
}

This is some (basic) sample HTML:

<div class="band band--dark masthead">
        <div class="wrap">

        <h1 class="masthead__title">Page heading</h1>
        <ul class="breadcrumbs">
            <li class="breadcrumbs__item"><a href="#" class="breadcrumbs__link" title="TITLE">Home</a></li>
            <li class="breadcrumbs__item"><a href="#" class="breadcrumbs__link" title="TITLE">Section Name</a></li>
        </ul>

        <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut volutpat accumsan purus, in posuere nibh aliquam faucibus. Nam varius lectus id nunc ullamcorper, at euismod enim placerat.</p>

        <h3>Related Categories</h3>
        <ul>
            <li><a href="#" title="TITLE TEXT">Category 1</a></li>
            <li><a href="#" title="TITLE TEXT">Category 2</a></li>
            <li><a href="#" title="TITLE TEXT">Category 3</a></li>
            <li><a href="#" title="TITLE TEXT">Category 4</a></li>
        </ul>

    </div>
</div>

Another question I have is the class of masthead, part of me thinks this should really be band--masthead following the BEM spec?

Thanks in advance, just starting off with BEM so I keep find myself questioning most of my implementations of it!

Compound block question

I am large

Left Middle Right

.button {border-radius:5px;}

As you see in the example above i have a block named "button".
I want to reuse the block "button" inside another block "button-group".

However when a button is used within a "button-group" block i would like to apply some slight modifications.

  • The left button should have radius only on the left.
  • The middle button should have no radius.
  • The right button should have radius on the right only.

How should I do this? The straight forward way for me would be:

.button-group .button {border-radius:0;}
.button-group .button:first-child {border-left-radius:5px;}
.button-group .button:last-child {border-right-radius:5px;}

Thanks

unique classes on list-items - element or modifier?

Hi there,

I have a navigation list, each items will need unique styling such as an icon/image applied to it. I've seen this handled a couple of different ways so I thought I'd put it to the forum and gets peoples thoughts on it. The standard mark-up would be something like this:

<nav class="site-nav">
    <ul class="site-nav__list">
        <li class="site-nav__item"><a href="#" class="site-nav__link">Schools</a></li>
        <li class="site-nav__item"><a href="#" class="site-nav__link">Users</a></li>
    </ul>
</nav>

Originally I thought I'd use a modifier and add classes like site-nav__item--users for example. But quite a few sites I've looked at use an element instead, so site-nav__users. So in full...

<nav class="site-nav">
    <ul class="site-nav__list">
        <li class="site-nav__item site-nav__schools"><a href="#" class="site-nav__link">Schools</a></li>
        <li class="site-nav__item site-nav__users"><a href="#" class="site-nav__link">Users</a></li>
    </ul>
</nav>

What's the thinking behind this and is there a right/wrong answer? Thanks in advance!

Mixes

In the simplest form a block is represented by a single DOM node but generally blocks and DOM nodes are not the same thing.

Mixes are just the way to use several blocks and/or elements on the same DOM node.

That makes possible

  • combining behaviour and/or styling of different BEM entities without copy/paste
  • building new semantic components based on existed blocks.

For instance, we have a universal block logo (a block with a logotype) that could be used anywhere on a page: in header, inside copy, in the footer, etc. We can specify its width, height and a background image but what we do with its margins that differ from case to case?

Of course, we could use modifiers like logo_type_header or logo_type_content to do so. However it is wrong semantically, because such things should lay down within a scope of parent block’s responsibility. And giving the right to define such things to an inner block contradicts the whole idea of blocks independency.

That's where mixes shine:

<div class="header">
    <div class="header__logo logo"></div>
</div>
.logo
{
    width: 120px;
    height: 60px;
    background-image: url(logo.svg);
}

.header__logo
{
    margin: 12px 26px;
}

As you know there's no global modifiers in BEM methodology but again — mixes gives us possibility to achieve the same result with several different blocks on same DOM node.

Also you may want to use mixes to provide some arbitrary block with JS logic.

A single DOM node can represent:

  • several blocks <div class="menu head-menu"></div>
  • a block and an element of the same block <div class="menu menu__layout"></div>
  • a block and an element of another block <div class="link menu__link"></div>
  • elements of different blocks <div class="menu__item head-menu__item"></div>
  • a block with a modifier and another block <div class="menu menu_layout_horiz head-menu">
  • several different blocks with modifiers <div class="menu menu_layout_horiz head-toolbar head-toolbar_theme_black"><div>

So try to develop your blocks as small and reusable as possible and then combine them in any way you want to build huge applications!

Slides and tasks of BEM CSS workshop (free for any usage :-)

Hello.

Today there has been a BEM workshop in our company (SC5 Online, Helsinki, http://sc5.io/) We studied basics like CSS approach and modular file structure. People did their tasks one by one "at the stage" :-) These are the slides, and the task is inside http://varya.me/bem-css-workshop/

Finishing the tasks we could compare the changes we provided without BEM in mind https://github.com/varya/bem-css-workshop-source/pull/1/files and with BEM https://github.com/varya/bem-css-workshop-source/pull/2/files
In my mind, it shows the different very clearly and it is easier to understand the idea of BEM. Even better than presentations and the articles.

BTW, I was surprised to learn that many don't know about BEM selectors supporting in SASS and LESS although this is at least 1-year-old feature.

How is it in your mind? Feel free to use slides.

How to change website design into BEM?

Hi,
This is probably very basic question but I'm not sure I saw something about that.

How is best way to move from website design into BEM structure?

I mean, how to fast identify all blocks, find what names should be and build structure efficiently?

Thanks.

Using just some parts of a block

Hi all again! :)

I don't know if this is strcit a BEM question. Can I reuse just some parts of blocks?. Is a copy+paste thing and I think it's not a good idea.. :S

With this block

<div class="newsletter">
    <div class="newsletter__title">Newsletter</div>
    <div class="newsletter__subtitle">This is the newsletter subtitle</div>
</div>

Can I use just this in other parts of the interface:

<div class="newsletter">
    <div class="newsletter__title">Newsletter</div>
</div>

Or I need to create for example a modifier like newsletter--no-subtitle and hide it

<div class="newsletter newsletter--no-subtitle">
    <div class="newsletter__title">Newsletter</div>
    <div class="newsletter__subtitle">This is the newsletter subtitle</div>
</div>

Thanks you!!

BEM projects incubator

There is an organisation on github called bem-incubator.

And this organisation is joined by more and more BEM community developers who uses BEM technology inside their projects and wants to develop technology together with us and maintain it together.

There are some recent projects:

If you have useful tools and libraries based on BEM technologies, join our BEM incubator!

Naming of List Items

What is the correct way of naming items in a list when the item itself has subcomponents. Is it the case that the item should be classed both as a child block of the list and as its own component? Is the following example correct?

<div class="news-feed">
  <h3 class="news-feed__title">…</h3>
  <ul class="news-feed__list">
     <li class="news-feed__list-item news-feed-list-item">
        <h4 class="news-feed-list-item__title">…</h4>
        <img class="news-feed-list-item__thumbnail">
     </li>
  <ul>
</div>

Hackathon in Yandex. How it was

A week ago I took part in the hackathon in Yandex. It was a small and local(for Yandex) one, only for yandexoids
and friends. It was a very technical hackathon about tools for developers like loaders, builders, template engines.
So developers were doing something for themselves.

So how did I get there if I'm not a yandexoid - my college Anton invited me because
we were doing stuff related to Yandex on my current job. It's an interesting project - I'll say a few words about it
later - but I couldn't find time for it because of other duties. So this hackathon became a great opportunity to find
time and complete the project.

A few words about our project. BEMXJST is a declarative template engine, very
flexible and powerful. So you can describe some structures using logic and domain-specific functions. Also, there is
another engine BEMHTML that takes
BEMXJST-templates and BEMJSON(simply a subset of JSON) and after
some magic we get HTML. So on my current job we have a library of UI components that uses BEMXJST and BEMHTML.
We also have a library based on React renderer. The libraries have to be equal in functionality and appearance - so
there has to be no difference for users. The main idea is somehow to tell React-lib to use BEMXJST-templates in its
render function. This will give us the ability to develop markup in one place and not to copy-paste it. It's possible
to implement another engine that works like BEMHTML but outputs data structures fittable for creating virtual-DOM.
That's how the React render function works - it doesn't produce a real DOM but a structure that describes DOM so it
can compare it with the real one and then decide is it required to update the real DOM. That's why we called our engine
VIDOM.

Before the hackathon, we checked the idea and created some POC and I can say that it was almost ready and almost all
the tests were green. But the code base was awful and there were bugs and we didn't check all the edge cases. So the
goal for the hackathon was to complete the project and make it possible to merge into upstream.

I love hackathons because of their magic. Just imagine the Saturday morning, you want to relax and your body is tired
and then you came to the place with a lot of people who are also tired but they want to work and they have the ideas
and passion for doing it and it's really the thing that motivates me. So I was full of energy for the whole weekend.
Also, it's a great pleasure to hang out and just work together, it's great fun definitely.

This particular hackathon was great for me because it was about tools and I'm interested in it. I like that there
were no prizes or ratings or stuff like that. I believe that money or other prizes break the idea because what really
matters is the pleasure of doing some stuff with friends and what you get at the end. And this is the real prize.
I also felt the engineering culture that exists in Yandex and it's great.

Finally, we've done our tasks and created a pull request into the main project.

More details in russian here.

Source

How to avoid nesting elements

Hi all! here I go again :)
In the code below, how I should name the #### div?

I don't want to name it header__title because it doesn't reflect very well the DOM relation, and since BEM doesn't recommend nesting elements (And I don't really like too) it can't be header__rrss__title

So sorry for this silly question, I read all documentation FAQ's and I can't find any solutions :S

Thanks in advance,

F.

<div class="header">
  <div class="header__logo logo">
    <div class="logo__foo"></div>
  </div>
  <div class="header__rrss">    
    <p class="####"></p>  
    <div class="rrss-icons">
      <div class="rrss-icons__title"></div>
    </div>
  </div>
</div>

Size modifiers

So in my scss framework I define sizes gradually with a sass map with keys from xs to xxxl. So I can do things like creating button modifier classes from xs padding to xxxl padding in an each loop. In the case of a button it is pretty straight forward I have a button block class with a background color some padding and so forth. In the loop I create modifier classes looking like .button--xxl { padding: 2em; }. That makes sense - I have a base block class with all its stylings and I have a modifier class modifying a very specific aspect of the block class.

But now comes my "problem" - I have an .island block class which looks like this: .island { padding: 1.5em; } the modifier classes look like .island--xxl { padding: 2em; }. So the modifier class completely overrides the block class. In the case of the island class it may be a possibility to use a utility class instead - something like .u-padding-xxl { padding: 2em; }? But I have a second example:

.grid--spaced-horizontal {
  margin-left: -1.5em;
  > .grid__item {
    padding-left: 1.5em;
  }
}

.grid--spaced-horizontal--xl {
  margin-left: -2em;
  > .grid__item {
    padding-left: 2em;
  }
}

Again, it bothers me that the modifier class completely overrides the block class. I don't want to have <div class="grid grid--spaced-horizontal grid--spaced-horizontal--xl"></div> in my code when grid--spaced-horizontal is completely pointless.

What do you guys think about my problem? Am I completely on the wrong track?

New releases of BEM libraries: bem-core & bem-components!

Hi all,

We have a good news — new versions of bem-core and bem-components are available!

bem-core 4.2.0

The version is completely backward compatible, so the update should be fast and "free".

The main change is compatibility with bem-xjst 8.x.
And more good news — all documentation is in English now.
Details find in changelog.

bem-components 5.1.0

The version is also completely backward compatible, so the update should be "free" too.

Release includes

  • an update of dependencies on bem-core to 4.2.0
  • visual design for link_disabled
  • fixes of some bugs

Details find in changelog.

bem-components 6.0.0

This version requires a mandatory update to bem-xjst 8

This version necessarily requires an update to bem-xjst 8, where new useful modes have appeared and the work of the extend mode has been fixed. Required packages for build with ENB (enb-bemxjst 8.6.7) or Gulp ( gulp-bem-xjst 3.0.0) are already available for installation.

To swithch to a new version of bem-components you may need automatic migrator of templates: https://github.com/bem/bem-xjst/tree/master/migration#migration-tool-for-templates

The difference between 5.1.0 and 6.0.0 is new templates.

Try new versions

New releases of bem-core 4.2.0 and bem-components 6.0.0 are already integrated in [project-stub] (https://github.com/bem/project-stub/).

If you have any problems with the update — write, we will try to help.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.