# BEM : presentation
## Block / Element / Modifier
### What is BEM ?
BEM was created by ***Yandex***, the "Russian Google" in 2009.
It is a component based architecture and naming convention.\
It stand for ***Block / Element / Modifier***. You may be familiar with this very well known namming convention. But it is also one of the most **misunderstood** yet the **most safe and advanced** methodology I had the pleasure to work with.
{% hint style="info" %}
**I strongly encourage you to** [**read the docs**](https://en.bem.info/)
{% endhint %}
### Why BEM ? It's so ugly !
One of the most common critic for BEM is that it is ugly, and that **those long classes names are making the markup hard to read**. I completely understand and it is often the main reason why developer do not want to switch to **BEM**. It's very sad because **the true beauty of BEM is hidden**. And I make you a promise : used right, you will love it so much, that you will see it as the only option out there to writing good CSS.
#### What are we talking about ?
When I talk about BEM, i'm refering to the class naming scheme. If you carefully [read the documentation](https://en.bem.info), BEM comes with practices [about file structure organization](https://en.bem.info/methodology/filestructure/). As we will use ITCSS, we should not feel concerned with the BEM file structure principles.
### The good stuffs about BEM
#### Just by looking at a piece of markup :
* you can know witch classes are related to others
* you can also know in witch file they are declared, reducing headache
* you can understand the role of the class (And therefore better follow the SRP)
**Following theses practices will help you:**
* make decision about emplacement easily
* get self documented code, and logically reduce the need for CSS documentation
* keep specificity low (because most of your selectors will only be composed of one classe)
* make class colision almost impossible (all classes will be uniques)
* thus, making it safer to have multiple sources of code (any CSS frameworks mixed with your own)
## How does it works ?
Please note that the following part was completely copy-pasted from the [documentation site](https://en.bem.info/methodology/key-concepts/)
### *Block features*
***Nested structure***
{% hint style="success" %}
***Blocks can be nested inside any other blocks.***
{% endhint %}
*For example, a `head` block can include a logo (`logo`), a search form (`search`), and an authorization block (`auth`).*
***Arbitrary placement***
{% hint style="success" %}
***Blocks can be moved around on a page, moved between pages or projects.***
{% endhint %}
*The implementation of blocks as independent entities makes it possible to change their position on the page and ensures their proper functioning and appearance.*
*Thus, the logo and the authorization form can be swapped around without modifying the CSS or JavaScript code of the blocks.*
***Re-use***
{% hint style="success" %}
***An interface can contain multiple instances of the same block.***
{% endhint %}
### *Element*
A constituant of a block
{% hint style="danger" %}
***An element can't be used outside of his block.***
{% endhint %}
*For example, a menu item is not used outside of the context of a menu block, therefore it is an element.*
### *Modifier*
*A BEM entity that defines the appearance and behavior of a block or an element.*
*The use of modifiers is optional.*
*Modifiers are similar in essence to HTML attributes. The same block looks different due to the use of a modifier.*
*For instance, the appearance of the menu block (`menu`) may change depending on a modifier that is used on it.*
*Modifiers can be changed in runtime (for example, as a reaction to a DOM event of the block), or via other blocks.*
*For example, if the wrong credentials are entered when a user clicks the Sign In button (the 'click' DOM event), the 'visible' modifier is set on a hidden block with error messages.*
{% hint style="warning" %}
We will see later that our version of BEM provide a better way to handle those types of changes
{% endhint %}
here the end of the copy-pasted content, and i'm not even a little ashamed…
### If you don't believe BEM is awesome
then you may want to believe them (they are all gurus in the CSS world) :
**Harry Roberts** Consultant Front-end Architect\
"*I use BEM notation on everything I build now as its usefulness has proved itself over and over."*
**Mark McDonnell** Technical Lead, BBC News\
"*Itʼs less confusing than the other methods (i.e. SMACSS) but still provides us the good architecture we want (i.e. OOCSS) and with a recognisable terminology."*
**Connie Chan** Design Director, Thoughtbot\
"*Combined with a preprocessor, BEM makes keeping your CSS modular and object-oriented a breeze."*
**Jonathan Snook** Author of SMACSS, Xero\
"*Most common misspelling is “SMACCS”. I should just rename it to BEM."*
**Paul Irish** Front-end Developer, Google Inc.\
"*This BEM stuff is next-level shit. Itʼs incredible how methodical it is."*
**Necolas Gallagher** Software Engineer, Twitter\
"*BEM is far more than a HTML/CSS system. Iʼve got no plans to use it all; just adapted some of its ideas."*
{% hint style="info" %}
**I strongly encourage you to** [**read the docs**](https://en.bem.info/) **(again...)**
{% endhint %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://gael-boyenval.gitbook.io/atomic-design-css-architecture-with-itcss-bem-sass/bem-conventions/bem-presentation.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.