Yandex developers jointly produce solutions for the problems they run into. At
the same time, Yandexoids are truly nerds connected to the world outside Yandex
via conferences, hackatons and meetups. So, the solutions produced by Yandex
developers perfectly work outside and can be easily shared.
Look at the draft for an online shop. As you can see, it's nothing special.
Just an ordinary web site providing all the generally accepted possibilities,
such as navigation through the site pages, searching books, some advertising
parts and so on.
As web developers, you know that behind the page there are our dear HTML and CSS.
````js
...
...
body {
font: 0.8em Arial, sans-serif;
margin: 0;
color: black;
}
.sidebar ul li {
````
Also, besides the page is really combination of HTML and CSS, it's also a set of
interface pieces.
Each piece is to do something. It provides to a user a functional or design
point.
Each has its purpose, similar to pieces of furniture…|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Each block is represented by a piece of HTML markup. To style the block you can
write the CSS rules, as usual.
The same works for the `Search` block, that is represented by `div` tag with
some content.
````js
````js
A block must not be affected by its ancestors, and in its turn must not affect the descendants.When filling a page with blocks, we developers, shouldn't care where exactly each block is placed. You just define a set of blocks with the appropriate order. And that's enough for getting a complete functional page. ````js ..
Regardless of where this block is placed.
Since now the `Menu` block is not a unique within a page. Because of that you
cannot use `id` selectors to match the CSS rules to it, this would be invalid.
So,
To apply CSS to a block, you should use classname selectors.**wrong** ````js
Again, even if a block *now* is a single one within a whole site, that does not
mean it should depend on its surroundings.
We, developers, should think about keeping associated CSS in the actual state.
So that if a block was removed from a page, we should remove its CSS code. Also,
if a block was added to a page, we should ensure its CSS is linked there.
As you see in the picture, the `Header` block contains the `Search` block. This
design solution seems to be invariable within the whole site.
But not. The page providing advanced search form doesn't have this `Search` block
in the `Header`.
So, should we include the `Search` block code into `common.css` file? Seems like
shouldn't. Well, should we copy-paste it for all the other pages? Again, no.
Moreover, this is just a simple example. In the real life the variety of
interface object combinations indeed can be huge. Usually it is very hard to
define the common stuff.
What about turning these drawn sets of blocks into code?
You can store CSS code for every block separately, each in a file with a
corresponding name.
blocks/
header.css
menu.css
button.css
tabbed-pane.css
logo.css
footer.css
So that, CSS for the `Menu` block is in the `menu.css` file, CSS for `Tabbed
Pane` block is the `tabbed-pane.css` file and so on.
Then, you can pack the CSS files for the pages with these blocks using an
`import` keyword.
````js
@import url(blocks/header.css);
@import url(blocks/menu.css);
@import url(blocks/tabbed-pane.css);
@import url(blocks/text.css);
@import url(blocks/logo.css);
@importurl(blocks/footer.css);
````
That enables you to take only what's necessary for a page.
As a result there is a block stack of our project, stored in a special folder.
And some pages that use these blocks.
Looks cool, but
## Inside a block
So, let's have a look what is inside our blocks.
The `Menu` block is going to be the first example.
````js
````
It's represented by `ul` tag and has some `li` children for the items. Also, the
`ul` tag is marked with a CSS class, so that you can apply the rules to it.
Here you can see that a `Dropdown` block with its own list was placed into the
menu item and immediately got broken because of this CSS instruction affects it.
As you can see, except of avoiding cascade there appears even more specific
rule.
You should not use tag selectors.The additional explanation why it is a bad practice to use tag selectors can be easily found in the Internet.
The style system matches rules by starting with the key selector, then moving to the left (looking for any ancestors in the rule’s selector).Further information can be found in [Davis Hyatt's article](http://mzl.la/UuwZql), from Mozilla. However we still need a solution to style menu items inside the `Menu` block. ## Element First, let's clarify a definition and call the things inside a block — `elements`.
This is a clear picture of what elements are.
The `Tabbed Pane` block has 2 `tab` elements (and can have more if necessary)
and the `pane` element to keep its content.
Styling elements you should think about them as self-reliant entities.
To apply CSS rules to the elements you will need to mark them with classes.
The difference you can see in the slide is that it comprises different sets of
elements. So that, elements are optional. This means you should be able to take
CSS code for the elements we use.
Similar to blocks, elements can be stored separately.
````js
blocks/
search.css
search__checkbox.css
search__autocomplete.css
tabbed-pane.css
tabbed-pane__tab.css
tabbed-pane__pane.css
menu.css
menu__item.css
book.css
book__title.css
book__image.css
````
That enables you to take element code only if you want. If not, you just won't
write the import instruction linking it to your page.
## Modifier
Now to the last notion, a `modifier`.
|
|
|
|
The famous examples of modified elements are active tabs and menu items. They
look a bit different from their friends.
To deliver design changes to an active tab, you need to add a modifier to an
element. Similar to what we was doing for blocks.
````js
You can see a modified block here. It has a blue theme. Of course, when having a
blue theme the block should guarantee that its elements will work correctly. In
this situation you allow the block affect its elements.
````js
.tabbed-pane_theme_blue
.tabbed-pane__tab
{
background-color: #9CF;
}
````
Here cascade is possible because the tabs appearance DOES depend on block
modifier.
*************
And just to wrap up, to make your blocks independent, be sure that
* a block has its "name"
- no "id" but "classname" selectors
* avoid cascade
* no "tag" selectors
## Block file structure
All the previously shown examples used flat variant when CSS files for blocks,
elements and modifiers are placed into one folder `blocks`.
````js
blocks/
tabbed-pane.css
tabbed-pane__tab.css
tabbed-pane__pane.css
tabbed-pane_theme_blue.css
tabbed-pane_theme_black.css
tabbed-pane_size_l.css
tabbed-pane_size_s.css
menu.css
menu__item.css
menu_size_l.css
menu_size_s.css
logo.css
search.css
search__checkbox.css
search__autocomplete.css
````
That works for not very large projects and not very complicated blocks.
If you expect many blocks with elements and modifiers, it's good to contain all
the files related to a block in a block folder.
````js
blocks/
tabbed-pane/
tabbed-pane.css
tabbed-pane__tab.css
tabbed-pane__pane.css
tabbed-pane_theme_blue.css
tabbed-pane_theme_black.css
tabbed-pane_size_l.css
tabbed-pane_size_s.css
logo/
logo.css
menu/
menu.css
menu__item.css
menu_size_l.css
menu_size_s.css
search/
search.css
search__checkbox.css
search__autocomplete.css
````
Less mess, and also it's much easier to copy block files from project to project.
We, at Yandex, use the most detailed structure with internal folders for
elements and modifiers.
````js
blocks/
tabbed-pane/
__tab/
_state/
tabbed-pane__tab_state_current.css
tabbed-pane__tab.css
__pane/
tabbed-pane__pane.css
_theme/
tabbed-pane_theme_blue.css
tabbed-pane_theme_black.css
tabbed-pane.css
````
It is not obligatory, but just works for our case.
Now, before proceeding to the next section, let us sum up.
* First, any interface is a set of blocks, which can be combined in different
ways, can be placed one into another, can change their parent block. And nothing
bad should happen since the blocks are independent.
* Also, all the nested tags in a block are elements.
* And finally, both blocks and elements can be modified.
## BEM
Now, that the three terms are introduced, I am happy to present you BEM methodology.
You've just learnt its parts related to independent CSS blocks.
Furthermore, BEM brings some other interesting solutions.
* First, BEM is a methodology. It's a way of thinking when developing. It provides
us with data domain applicable for all the technologies.
* Besides, BEM is a toolkit automating your work.
* Finally, BEM is a range of reusable code libraries, making you to develop
* faster and better.
Now let's have a look at all these opportunities in a little more detail.
### CSS for IE
First, I'd like to show how we deal with our bosom friend, the IE browser.
It is possible to link an additional CSS file to a page, especially for IE.
Using conditional comments you make other browsers ignore this file. So that,
there we can write fixes for IE only.
````js
...
````
Inside the `ie.css` file you import the general CSS file for the page.
````js
@import url(index.css);
@import url(blocks/menu/menu.ie.css);
@import url(blocks/button/button.ie.css);
@import url(blocks/footer/footer.ie.css);
````
Then, you can redefine CSS that doesn't work correctly for every piece of
interface. It's logical to do it separately for each block.
Blocks that need special IE hacks are equipped with additional `ie.css` files.
If all the block files are under the block folder, we can just place one more
file in it.
````js
blocks/
tabbed-pane/
tabbed-pane.css
tabbed-pane.ie.css
...
menu/
menu.css
menu.ie.css
````
The same works for elements and modifiers.
````js
blocks/
tabbed-pane/
tabbed-pane.css
tabbed-pane.ie.css
tabbed-pane__item.css
tabbed-pane__item.ie.css
tabbed-pane_theme_blue.css
tabbed-pane_theme_blue.ie.css with
````
So, a block folder encapsulates all the CSS needed. Using the project block
stack we can assemble CSS files for pages, both the general one and for IE.
## JavaScript
HTML/CSS dummy is not a functional web application yet. But implementing some
JavaScript logic we can paint it with colours.
We should code that the `Tabbed Pane` block reacts on leftclick.
The `Dropdown` block functionality is that it is hidden when a page is just
loaded. But if a user makes clicks with the left mouse button on its switcher,
the block shows.
The `Dropdown` also can be smart enough to calculate its direction according to its
place on a page. In the picture the second `Dropdown` block opens up since it's
too close to the bottom.
We got this information with a visual language the picture provides. But the
same can be described in text. Any nesting format works for it.
````js
We, here at Yandex, have a bunch of our in-house BEM-based libraries helping us
to build a new Yandex-style web service much faster than from the scratch and
making maintaining process easier.
When we started to open source our magic stuff, a small part of the internal
library was turned into [bem-bl](https://bem.github.com/bem-bl/index.en.html).