Comparing different CSS patterns in Drupal 8

Recently we have been working a lot with Hayato Goto to adapt our current coding standards to the Drupal 8 standards. It is quite difficult to define new standards since everybody is different and has her/his preferences in matter of writing code, and to be honest we are still working on some points. Anyway, we found out many different code writing styles and methodologies so I thought it may be good to share some of them here.

What is a "CSS methodology" ?

It is a way to write code. As I said before every developer has her/his own preferences so when working in a company it may be good to define standards so that the code is unified and euphonious. But it may also be a way to divide the code in different parts and structure the folders/files of the code following a specific method.

Why using a specific methodology

There are many reasons why someone would adopt a methodology. First it helps developers to code quickly while keeping a good and understandable structure in their different files. I am going to introduce several methods later in this post and you will see how some developers thought about various files organisation. It is also helpful to apply a consolidated code style within a company or a group. An other advantage can be for interns or new employees to catch up easily with the way an enterprise write code and maybe learn more effectively. Last but not least, your code would definitely be more readable for other developers (even outside of your corporation) if you follow specific standards.

CSS Methodologies

While searching for new standards we got some inspiration here and there on the Internet and we were checking out how other front end developers were writing their own code, the kind of standards they are following, and their inspirations. One thing leading to another we ended up with a lot of ideas and at some point I must admit that I was a little lost between all the different methodologies and standards. As you will see in this post there are some methodologies that are very structured and some quite abstract. I think it depends on people but having a mix of some of them can be really beneficial to your productivity and your code readability.

Object Oriented CSS

The concept of OOCSS has been introduced by Nicole Sullivan. The main idea is to produce a code that is reusable and easy to maintain. To do so, Nicole Sullivan suggested to separate the structure (such as the position, the width and height of an element) and the skin (theme : the colors), it allows you to reuse the structure or the skin by just adding a class to an element. An other important principle in OOCSS is to avoid the location dependent style. Some developers use the parent element to style an specific html tag. For example :

.Block {
  a {
    color: red;

In such a situation all the links in the block would be red, which I guess is ok if they all should be red but what if you have links that are different ? You would have to override the default style you wrote for those links. According to the OOCSS method you should add a class and style with it if your elements are not supposed to be the same. This way your style is reusable somewhere else and you do not need to override some style.

What is OOCSS

Scalable and Modular Architecture for CSS

SMACSS has been created by Jonathan Snook in order to organise CSS to make it easier to maintain and easier to build. For him it is a necessity to divide CSS files in different folders and files. There is no concrete standards given in his book, it is only a way to structure your code. SMACSS has been adopted by a lot of front end developers and has been implemented to the Drupal 8 coding standards too.

Drupal 8 CSS Coding standards


The base folder files should include only HTML tags, no class, no ID. It is used to define the default style of the website. At Studio Umi we usually include our normalize.scss file in this folder.


As the name suggest it, the Layout folder should contain elements for the layout such as the header, footer or sidebar.


We usually use only classes in the files in this folder. In the different files, we try to style the elements so that they can be reusable in any part of the code if possible. We also try not to make some elements dependent to others.


Here we should write the Javascript related code and also the pseudo-classes and media queries. Whenever an element changes style after some "event" it must be handled by state.


It can be useful for a website with several themes however if your website has only one colour theme it is not an obligation to use this folder. We include the colours, borders of the element and the typography.


Blocks, Elements and Modifiers

BEM has been created to produce code that is reusable and modular. The BEM methodology is said to be easy to learn and to put in place.


Entities that are the "parent" of one or multiple elements. For example : header, block, menu, etc..


Elements that are considered as blocks' chidlren. Example : block title, menu item, etc...


Entities that change the appearance of a block or an element. Example : highlighted, hidden, primary, etc...

Naming Convention

Each category should have a special syntax so that it can be identified in the code easily.

There are different naming conventions, some people adapted them to their needs and preferences :

Traditional naming convention :
  • Block : .block
  • Element : .block__element
  • Modifier : .block--modifier .block__element--modifier
CamelCase style

Instead of using hyphen to separate the different words, we use CamelCase.

Sans underscore

No underscore is used for the class names. CamelCase is used to separate the words in the name and elements are separated with an hyphen while modifiers are separated with double hyphens.


MindBEMding - Getting your head around BEM syntax


Naming Convention

The naming convention is a mix of hyphens and CamelCase.

  • .ComponentName {}
  • .ComponentName--modifier {}
  • .ComponentName-part {}

The methodology is made to help the code being modular and reusable. The semantics and the single responsibility principle are taken into consideration in SuitCSS too.


Trello CSS Guide

The purpose of those guidelines is to keep the CSS easy to understand, as a result they use only import, variables and mixins, and they try not to nest their code a lot to avoid complex functions.


You can use descendant classes or name spaces : .global-menu .link or .global-menu-link.

They avoid using id, html selectors, underscore and camelCase for the components.


In order to make a difference between a descendant and a sibling, they use a special syntax : .mod-modifier.

Example :

.global-menu-link .mod-contact


Whenever there is a change in the state of the element (visible, hidden, open, close, etc..), state should be used. The syntax for the state pattern is the following : .is-state.

Javascript classes

In order to separate style from behavior, they use a different type of name for JS classes and style classes : .js-behavior


These classes can be used for any component. See CSS Wizardry - Utility Namespaces for more information.

Trello CSS Guide

Atomic Design

This methodology is quite similar to SMACSS on some points, the goal is almost the same : a code easy to maintain and reuse. The different categories in Atomic Design are the following :


It can be considered close to a "normalize" file, it contains HTML elements and no class nor id.


Similar to chemistry, molecules are composed of atoms. So basically a group of HTML elements is a molecule.


Organisms are a construction made of molecules (so of atoms too). Organisms make the different sections of the website.


Templates are the complete pages without any real content, the different organisms are grouped together to construct a template.


Simply the templates with "real" content.

Atomic Design

Drupal 8 Themes

Goto-san compared the different Drupal (8) themes and what methodology they are using :


  • Pattern : MindBEMing
  • Comment : Seems to have some exception but the base is MindBEMing


  • Pattern : Bootstrap : block-element block--element block--modifier


  • Pattern : MindBEMing block-modifier block--modifier
  • Comment : Node and comments are using MindBEMing, block and other are using a different pattern, views is a mix


  • Pattern : MindBEMing and GridLayout


  • Pattern : MindBEMing and GridLayout


  • Pattern : MindBEMing and GridLayout


  • Pattern : MindBEMing and GridLayout and block-element pattern ?


  • Pattern : None ?
  • Comment : A few Sass files so uncertain


  • Pattern : None
  • Comment : Follow the core


  • Pattern : MindBEMing and GridLayout


  • Pattern : None ?
  • Comment : There is almost no hard-coded classes so neutral ?


  • Pattern : MindBEMing and block-element pattern ?

We can see that the most used is MindBEMing, however famous themes such as zen and omega are not using any CSS pattern. Anyway I think it can be useful to have some knowledge about the different writing styles in CSS since it really depends on the developer and the project. Moreover, knowing different style can definitely help you to write code more efficiently and increase your productivity.


I think each methodology has its perks. It depends on the projects and developers working on it. There is no correct standard and no best way of writing code. However there is (are ?!) bad way(s) of writing code, it is important to keep in mind that we may not be maintaining a project our whole life so we need to produce some code that can be easily understood by other developers. Following a famous methodology can be a good thing since other developers are probably aware of it too, but sometimes it may not fit the project. I think the best way to choose how to write code is too try several ways and find the one that match better our way of thinking when developing a website and our projects.


Drupal 8 Themes

Webプログラマー募集 私たちスタジオ・ウミは、共に技術を高め合い、共に価値ある仕事を追求できる仲間を探しています。