What is the problem of "BEM problems"?
It seems the week has ended 30 lines of code, and instead of it, the week of " BEM " apparently came. And quite funny sequence of topics can be traced:
And the most interesting, as always, in the comments is pure holivar. But why? Why do some people firmly believe in the BEM methodology, others despise it as a usurper of semanticism? I will try to state my point of view on the essence of the whole holivar and clarify first of all for myself the position of BEM in my own universe.
In fact, I became interested in BEM a long time ago, I liked the idea, tried to understand it, tried to put it into practice, but somehow it didn’t work, I don’t know why. I made several approaches, but in the end my project turned into a terrible jumble of attempts to introduce BEM, and “ideas of crystal semantic HTML + CSS” (to which I turned, disappointed in BEM). In fact, thismakes me sad so far and brings daily joy to the pain in the work on the project. The emerging articles from Kata and comments to them caused a storm of emotions in me about the semantic type of layout, the device browsers, BEM, preprocessors and all, one way or another related to the topic of ideologies, methodologies, techniques and other things. Since my personal approach to the application of BEM failed, but quite logical rationales for applying the methodology were still in my head, in every article and every comment I tried to find the truth that would somehow answer my questions and finally form Personally, my attitude to BEM. Oddly enough at one point this happened. How it happened and why I will try to convey to you.
Semantist - denying BEM.
Bemer is an adherent of BEM.
')
Let's write the menu structure.
We wrote the menu, we will fasten classes to it.
You rely on the structure and cascades - everything will fall apart at the first edit. It will be more correct so:
HTML:
CSS:
With this approach, you do not need to change the structure of the HTML, without breaking up the styles.
What is the point to produce a bunch of classes? Is it not easier and not shorter then to register inline styles? Why inflate a CSS file? Nothing is clear!
Classes are as specific as possible when processed by the browser, and studies conducted show that this plays a role in the modern world will be worked out faster. Inline styles will be spread throughout the project and their support will be as complex as possible. It is better to inflate a CSS file than to fill up the layout when making edits.
For me, the semantics and visibility of both HTML and CSS is more important than the time spent on the development of CSS instructions by the browser, because I am writing the code, not the browser. Moreover, such a large number of styles is easy to forget when writing HTML and linking them to the project structure. So that the layout does not fall, you need to think better about semantics.
Are you still writing HTML with your hands? After all, we have such beautiful elements as bemhtml and bemjson - you describe classes (which by the way can be used many times), their position in the structure of the document and content, and the tools for you generate HTML markup, and lay everything on the shelves. Therefore, you do not need to touch HTML directly.
And why should I use some kind of tool? I'd rather use HTML and CSS preprocessors - the effect will be the same, but the code is smaller and everything is much clearer and clearer.
Another one “did not drive into BEM” and for some reason drafted preprocessors, and generally compares warm with soft, we after all offer a methodology that is successfully used on large projects and all for nothing.
All the same, I don’t see any advantages of your approach, everything is only becoming more complicated and overgrown with some additional tools! My approach is better, since I have been working for several years now and nothing falls for me.
* Much of the description of holivar is purposely exaggerated, paraphrased, taken out of context and so on in order to emphasize the divergence of views from different sides.
The essence of the holivar described above essentially consists in arguing the comparison “warm with soft”, just by “warm” and “soft” each developer also means different abstractions. And this is the main problem of BEM and those who did not “enter” - the authors of the methodology put too much sense into these 3 letters, because of which those who did not work with the methodology see only its part through the “keyhole” of their experience and the universe. And in order to understand why it was invented at all, and what is the point of using it, you need to reread a lot of information, identify cause-and-effect relationships in it, get into it, and all this only to understand “why?”. The authors themselves pull out pieces of their methodology for argumentation and all these separate pieces are called BEM.
On the one hand, BEM is simply the principles of class naming. The idea of ​​“Block Element Modifier” looks quite logical - we describe all entities with.b-example blocks and nested elements of .b-example__element , for certain blocks and elements we use modifiers .b-example__mod_val / .b-example__element__mod_val . And this approach makes it possible to increase the visibility of classes and determine their belonging to a block only by name.
On the other hand, BEM is the implementation principles of independent units. The refusal to cascade classes, the refusal to bind to the structure of the document, the maximum specificity of class names is all with the aim of introducing painlessness and lightness with constantly arising edits, redesigns and other things.
And the most interesting thing is that the further the methodology is developed, the more sense is put into these 3 letters:
BEM - the rejection of the manual approach in creating the structure of HTML. We describe all the classes used, on JSON (in this case on the specific BEMJSON) we create the structure of the document and the relationship of the classes - a special tool (bemhtml) generates the corresponding HTML - everything is great and everyone is happy.
BEM - the ability to generate JS to work with previously generated HTML. * I can’t say anything meaningful on this point, because I didn’t work with it, I hope knowledgeable people will prompt.
In my very personal view, such a rethinking of 3 letters is the “root of evil” that does not contribute to the involvement of the masses in the ideology. Each time, bumping into misunderstandings, authors and ideologists have to explain what exactly they mean in a specific context under the abbreviation BEM, and very often it is not possible to explain this properly.
All these thoughts, in fact, pushed me to one of the comments with reference to the NSA . And it is completely incomprehensible to me why it was necessary to move away from such an extremely understandable term as “Absolutely independent block” or “Non-distorting block”, introducing the additional abstraction “Block Element Modifier”, which every time you have to explain and chew.
The logical solution to the problem, it seems to me, is the decomposition of such a global abstraction into smaller ones, with consistent introduction of terminology for each smaller abstraction (“BEM sphere”), which, by the way, will also reflect BEM’s ideology - independence use and refinement of each of the abstractions.
For myself, I decided on BEM:
- We impose a web page in 15 minutes.
- At BEM, it would be better!
- You yourself eat your boom, I have preprocessors!
And the most interesting, as always, in the comments is pure holivar. But why? Why do some people firmly believe in the BEM methodology, others despise it as a usurper of semanticism? I will try to state my point of view on the essence of the whole holivar and clarify first of all for myself the position of BEM in my own universe.
In fact, I became interested in BEM a long time ago, I liked the idea, tried to understand it, tried to put it into practice, but somehow it didn’t work, I don’t know why. I made several approaches, but in the end my project turned into a terrible jumble of attempts to introduce BEM, and “ideas of crystal semantic HTML + CSS” (to which I turned, disappointed in BEM). In fact, this
Consider a typical holivar
Characters
Semantist - denying BEM.
Bemer is an adherent of BEM.
')
Act I: Beginning
Semantist
Let's write the menu structure.
<nav> <ul class="top-menu"> <li><a href="/home/">HOME</a></li> <li class="active">ABOUT US</li> <li><a href="/services/">SERVICES</a></li> <li><a href="/partners/">PARTNERS</a></li> <li><a href="/customers/">CUSTOMERS</a></li> <li><a href="/projects/">PROJECTS</a></li> <li><a href="/careers/">CAREERS</a></li> <li><a href="/contact/">CONTACT</a></li> </ul> </nav> We wrote the menu, we will fasten classes to it.
nav a { text-decoration: none; } nav ul { margin: 0; padding: 0; } nav li { list-style-position: inside; font: 14px 'Oswald', sans-serif; padding: 10px; } .top-menu li { display: inline-block; padding: 10px 30px; margin: 0; } .top-menu li.active { background: #29c5e6; color: #fff; } .top-menu a { color: #b2b2b2; } Bamer
You rely on the structure and cascades - everything will fall apart at the first edit. It will be more correct so:
HTML:
<div class="b-menu"> <a href="#" class='b-link b-link_menu b-link_menu_active' >HOME</a> <a href="#" class='b-link b-link_menu' >ABOUT US</a> <a href="#" class='b-link b-link_menu'>SERVICES</a> <a href="#" class='b-link b-link_menu'>PARTNERS</a> <a href="#" class='b-link b-link_menu'>CUSTOMERS</a> <a href="#" class='b-link b-link_menu'>PROJECTS</a> <a href="#" class='b-link b-link_menu'>CAREERS</a> <a href="#" class='b-link b-link_menu'>CONTACT</a> </div> CSS:
.b-menu { margin:0; padding:0; list-style:none; width:100%; display:table; table-layout: fixed; } .b-link_menu { text-align:center; color:#bfbfbf; cursor:pointer; font-size:14px; height:38px; background-color:#f3f3f3; line-height:38px; border: 1px solid #e7e7e7; display:table-cell; text-decoration: none; } .b-link_menu_active { color:#fefefe; background-color:#29c5e6; border:1px solid #29c5e6; } With this approach, you do not need to change the structure of the HTML, without breaking up the styles.
Act II: Misunderstanding
Semantist
What is the point to produce a bunch of classes? Is it not easier and not shorter then to register inline styles? Why inflate a CSS file? Nothing is clear!
Bamer
Classes are as specific as possible when processed by the browser
Semantist
For me, the semantics and visibility of both HTML and CSS is more important than the time spent on the development of CSS instructions by the browser, because I am writing the code, not the browser. Moreover, such a large number of styles is easy to forget when writing HTML and linking them to the project structure. So that the layout does not fall, you need to think better about semantics.
Act III: Transition to another dimension
Bamer
Are you still writing HTML with your hands? After all, we have such beautiful elements as bemhtml and bemjson - you describe classes (which by the way can be used many times), their position in the structure of the document and content, and the tools for you generate HTML markup, and lay everything on the shelves. Therefore, you do not need to touch HTML directly.
Semantist
And why should I use some kind of tool? I'd rather use HTML and CSS preprocessors - the effect will be the same, but the code is smaller and everything is much clearer and clearer.
Act IV: Decoupling
Bamer
Another one “did not drive into BEM” and for some reason drafted preprocessors, and generally compares warm with soft, we after all offer a methodology that is successfully used on large projects and all for nothing.
Semantist
All the same, I don’t see any advantages of your approach, everything is only becoming more complicated and overgrown with some additional tools! My approach is better, since I have been working for several years now and nothing falls for me.
* Much of the description of holivar is purposely exaggerated, paraphrased, taken out of context and so on in order to emphasize the divergence of views from different sides.
"Problems BEM'a"
The essence of the holivar described above essentially consists in arguing the comparison “warm with soft”, just by “warm” and “soft” each developer also means different abstractions. And this is the main problem of BEM and those who did not “enter” - the authors of the methodology put too much sense into these 3 letters, because of which those who did not work with the methodology see only its part through the “keyhole” of their experience and the universe. And in order to understand why it was invented at all, and what is the point of using it, you need to reread a lot of information, identify cause-and-effect relationships in it, get into it, and all this only to understand “why?”. The authors themselves pull out pieces of their methodology for argumentation and all these separate pieces are called BEM.
On the one hand, BEM is simply the principles of class naming. The idea of ​​“Block Element Modifier” looks quite logical - we describe all entities with
On the other hand, BEM is the implementation principles of independent units. The refusal to cascade classes, the refusal to bind to the structure of the document, the maximum specificity of class names is all with the aim of introducing painlessness and lightness with constantly arising edits, redesigns and other things.
And the most interesting thing is that the further the methodology is developed, the more sense is put into these 3 letters:
BEM - the rejection of the manual approach in creating the structure of HTML. We describe all the classes used, on JSON (in this case on the specific BEMJSON) we create the structure of the document and the relationship of the classes - a special tool (bemhtml) generates the corresponding HTML - everything is great and everyone is happy.
BEM - the ability to generate JS to work with previously generated HTML. * I can’t say anything meaningful on this point, because I didn’t work with it, I hope knowledgeable people will prompt.
"The root of evil"
In my very personal view, such a rethinking of 3 letters is the “root of evil” that does not contribute to the involvement of the masses in the ideology. Each time, bumping into misunderstandings, authors and ideologists have to explain what exactly they mean in a specific context under the abbreviation BEM, and very often it is not possible to explain this properly.
All these thoughts, in fact, pushed me to one of the comments with reference to the NSA . And it is completely incomprehensible to me why it was necessary to move away from such an extremely understandable term as “Absolutely independent block” or “Non-distorting block”, introducing the additional abstraction “Block Element Modifier”, which every time you have to explain and chew.
The logical solution to the problem, it seems to me, is the decomposition of such a global abstraction into smaller ones, with consistent introduction of terminology for each smaller abstraction (“BEM sphere”), which, by the way, will also reflect BEM’s ideology - independence use and refinement of each of the abstractions.
Instead of a conclusion.
For myself, I decided on BEM:
- there is a sense of using independent blocks, and of course I will apply them;
- I didn’t particularly like the class naming rules - it’s often too redundant (I won’t argue that in large projects this could be a panacea), I’ll probably use a slightly modified approach;
- BEM's tools seem redundant to me, at least for my current tasks, maybe in the future I will consider them in more detail
Source: https://habr.com/ru/post/203994/
All Articles