What properties should be written for each BEM type?

Question

BEM

Hello! I have a few questions about BEM that are haunting... I have repeatedly met with the opinion that the block should not be given dimensions. That is, it turns out that I cannot move any of the blocks (slightly) using margin. Can't set padding and width? Hence the question: What properties should be assigned to each of the BEM types... Block, Element, Modifier?
Second question: I want to start with why I decided to move to BEM... Purpose: Independent blocks!!! Hence the question... The fact is that I want to use BEM to a minimum, only in terms of class naming. But will this be enough to create independent blocks? And ... as I understand it, one cannot do without dividing properties into types ... Is this true? ... Next... I don't want to go into mixes (I don't understand that yet). Somehow the example was considered when a div had a block class and an element class together... And when the element included a block (in my mind, only a block includes elements) . That is, it's all too windy in BEM. I can't use it all at once in new projects, I'll get confused! And especially in terms of LESS and JS ... I heard from one course that in general, for each block on the site, a LESS file is created. The fact, that I already have a ready gulp-file for projects. It turns out that because of BEM, I have to redo everything. In fact, to learn again) And I want to write in LESS normally, without looking at the blocks, but only on the name. Please help me figure it out!
PS Sorry for such a big question... There is confusion in my head... Thank you!

Answer 1

Well, first of all, some lyrics: there is no single right way to use BEM in this or that case. Since BEM is not a set of axioms and algorithms, but an idea (cheat. Ideology, philosophy, a look from a different angle, etc. ...). Also, BEM is not the only concept of its kind, the first thing that comes to mind is SMACSS, OOCSS, Atomic CSS . If you look at the generalized, the same thing in different words with minor differences ( brief review). It's not the name that matters, but the essence. Now you (and indeed everyone who takes the first steps on the path of a Jedi :)) probably think - "Damn, what the hell did they come up with this brainwashing?", Or - "Why are they doing this to me?". You can not answer, I still know what it is :). But the essence, just the same, lies in the opposite plane. In order to understand complex things, often written in incomprehensible words (exclusively for pathos), you need to:
1. From the entire flow of information, clearly, point by point to highlight what it was created for and what difficulties it should actually solve.
2. Using the method of scientific poke, in practice, find these problems, see with your own eyes and understand that this tool is not a punishment from heaven, but a hammer for nails that you used to hammer with a screwdriver handle.
Programmers don't like layout at all. Because they are used to working with advanced programming languages ​​where everything lends itself to logic, and all the bumps are already full of predecessors. And the html / css bundle is very difficult to fit into this picture. Hence the constant desire to invent a bicycle. Next, there are 1000 and one ways to lay out even the simplest element. What can we say about modern interactive web applications... As a result, you get thousands of lines of code that do not understand how they work, and also interact in an incomprehensible way with each other, so that their creator himself cannot figure it out in a day.
Actually, BEM is nothing more than an attempt by bearded coders from Yaedex to apply the OOP ( object-oriented programming ) paradigm) on the layout process. And if more precisely, then a subspecies of OOP is COP (not a cop, component-oriented programming ). And I must admit, completely even a successful attempt.
What we have:
a BEM entity, it is also a block, but it is also an object, which is also known as a component or module that meets the principle of OOP abstraction - And in simple words, this is a part of our web page on which we once threw an eye and without much hesitation we can single it out as something self-sufficient. Something that can be described in one word. And this word will be at the same time the name, and without looking at the picture it will make it clear how the block may look, and besides all this, it will describe its functions and the principle of its operation. However, it can be reused in different places on this page, or on other pages of the site.
- Hello, Alex, I registered on the toaster, how can I ask a question here?
- Yes, it's as easy as shelling pears, you press the 'Ask a question' button, you ask and you press the 'send' button.
Thus, you, without looking at the monitor, and I just saw this site for the first time, understood each other perfectly. Because the site has a pronounced, self-sufficient, user interface element - a button block.
- Hey Alex, do you remember that site we submitted last week?
- Well, yes, even the source code is lying around on the desktop.
- Great, the customer asked to change the buttons in the forms from branded green to a brighter green, otherwise something does not catch his eye. :) And the button in the "Learn more" header should be centered.
- Ok, three minutes, we have everything there for less-bem, chiki-piki.
In this case, neither you nor I remember either the exact implementation of the buttons or the implementation of the tables, we are not at all interested in what is inside, what tags were used, how many inputs there are, and so on. We abstract from the more primitive to the more meaningful. Accordingly, when you edit, you will do it not by the method - with your finger to the sky. And simply by reading the names of the classes. First you will find the header class, then the button class in it.
The button block is a button in general, it defines a general skeleton, a template that others look like. Ideally, styles for resetting browser styles get there, and something else, if it is present in all buttons on the layout.
(diagram example)

/* HTML types */

<a class='button' href='#'>Кнопа</a>
<button class='button' href='#'>Кнопа</button>
<input class='button' type="submit" value="Кнопа">

/* bem entity */

.button{
                                 // reset
  user-select: none;
  display: inline-block;
  text-decoration: none;
  touch-action: manipulation;
  
                                 // common
  padding: 0.5em 1em;
  border-radius: 2em;
  text-align: center;
}

/*        _MODS_       */
// SIZE (SCSS)
.button{
   &_size_s{
     font-size: 1rem;
     }
   &_size_l{
     font-size: 2rem;
     }
}

// COLOR
.button{
  &_primary{
    background: #607D8B;
    color: #ffffff;
    }
  &_secondary{
    background: #8BC34A;
    color: #ffffff;
    }
}

// PARENT__BLOCK
.header{
    &__button{
      display: block;
      width: 200px;
      margin: 0 auto;
     }
}

codepen.io/kovbassa/pen/ObrqZv?editors=1100 Next
we are asked to change something in the form of buttons.
Which ones are branded, which ones you need are bright green. Everything what, what, what, etc. .. is the .button__mod-name modifier, here are rectangular and color and rounded and large and small. Example, let's make the buttons in the forms more noticeable.

<button class="button button_accented button_xl">text</button>
             // common, color,            size

Now center the button in the header.
.button is the skeleton of all buttons, where its specific case would be in the header, it doesn't care.
button_mod - button skins, one is green, the other is red, and there is a big one, etc.
Let's remember how the task is: to center the button in the header.
That is, the .header header and it has a .button element, which should be in the middle.
From here:

<header>
<button class="button button_brand header__button" >text</button>
             //common, color,        local position
</header>

At the end - blocks can consist of both smaller blocks and elements. Elements cannot have their own blocks, or elements. One DOM node (html tag) can be both a block and an element of the parent block at the same time.
Regarding the sizes, it is better when the sizes are set by the skeleton of the page, tobish grid. Therefore, try to make the blocks as wide as possible rubber. Try to operate with relative values ​​(%, em, rem) and not absolute ones - px.
In general, it is not so important whether you use BEM correctly or not, more important is the stability of the style. If you start layout in a certain style, try to stick to it until the end. For example, it is good practice to vertically position elements on a page to use only margin-bottom, or only margin-top. And not everything in a heap and margin's collaps everywhere in the end.

Answer 2

Briefly and simply - the block does not know what is happening around, the parent block does it for it. It's just unidirectional data flow.
Long and with epithets - in the documentation .