CSS Guidelines

About CSS codeguides

The CSS guidelines of the project are fairly simple, and are based in common sense, semantic nomenclature and the BEM structure (Block, element, modifier).

For starters we have to state that we are targeting the latest and greatest browsers, so the use of CSS3 is allowed and suggested..

Main Rules

  • Don't camelCase on class names. camelCasing is used widely on element IDs, React properties and things javaScript, so leave it alone, let's not confuse everybody with more camelCasing in rule-names.

  • Specify font-sizes, line-heights, paddings and margins as rems. (1rem equals the font size declared for the body tag, 16px by default, if you need 8px of padding, then it would be 8px/16px which equals to 0.5rem).

  • Don't use visual descriptions on class names. For example .button–red is wrong. Use semantical meaning of the style instead, for example, ir the red color is used for dangerous actions, then use .button–danger. Why do we do this? because in the future we might style a dangerous action with purple instead of red. Same goes with adjectives like round, square, light, dark, etc. For those you could use (soft, sharp, regular, inverted, etc.)

  • Don't write a rule for an HTML element, instead give the element a class attribute and write a rule for that class name. Why not using element tags? because one day you might have to correct your tags to give more semantical meaning, and you would have to change the stylesheet as well (there . is an exception for this, please read next item).

  • If you are creating a web component, eg, Angular component, React Component, Polymer component it is permitted to write a rule for the default state of this component targeting the html tag you chose for such component. This would mimic the default styles that regular web elements come bundled with such as the paddings and margins of p, h1, ht etc.

  • Don't write a rule for an id (#elementId), instead give the element a class attribute and write a rule for that class name. Why not using id's? Because you might change the id in the future for some reason, and then you would have to correct the stylesheet.

/* The footer (B)lock */ .footer {

padding: 1rem;


/* The common button (E)lement rule */ .footer__button {

border-radius: 3px;

border: none;

/* a default background color */

background-color: #ccc;

color: #fff;


/* The button (M)odifiers */

.footer__button--danger {

background-color: red;


.footer__button--success {

background-color: green;


BEM Nomenclature

Simple Straightforward, take the name of your Block (header, jumbotron, main menu), add double underscore (__) and the Element name for styling the block descendants, and add double dash (–) to add the Modifiers for those elements.


So, if we have a red and a green button on a footer the css nomenclature for all three would be:

What about grandchilds?

First thing that comes to your mind is actually using double underscore to mimic the DOM, but no need of that, within BEM, there is only one level when referring to all of the descendants of the Block, so, for example when you have a list, you could name elements like this:


/* a wrapping nav element */

.main-menu {

   padding: 0;


.main-menu__list {

   list-style-type: none;


.main-menu__list_item {

   margin-bottom: 0.5rem;


.main-menu__link {

   text-decoration: none;



<nav class="main-menu">

    <ul class="main-menu__list">

        <li class="main-menu__list_item"><a class="main-menu__link" href="#!/one">One</a></li>

        <li class="main-menu__list_item"><a class="main-menu__link" href="#!/two">Two</a></li>



Any Questions?

For more information or comments please write to us at cemexgo.developerscenter@cemex.com  and we will gladly assist you as soon as possible.

Support Links

For more reference please visit the following links:


Battling BEM – 5 common problems and how to avoid them