This article is also published in french - Déployer Sass de manière efficace


As we saw earlier, writing in Sass does not mean writing traditional CSS, but it is incumbent on us to produce quality CSS, and, finally, to comply with a set of good practices.


I therefore invite you, before I begin, to bring you closer to Principles of writing consistent, idiomatic CSS.


Next, it is important that we are interested in some approaches, and methodologies, in designing CSS styles.


Each of them explores a way of using classes and sharing descriptions.


It is true that, at first glance, this may run counter to a certain idea of CSS, and in particular on the abuse of class, otherwise known as acute class.


If you take the time to analyze them one by one, you will quickly realize that whatever the nature of your project that the single use of selector can very quickly become blocking at the level of the specificities, and is relatively heavy to manage as to its scalability.


OOCSS (Object Oriented CSS)


The object-oriented approach OOCSS is a revolution in the basic approach of CSS.


The idea is simple. Just think about distinguishing the structure and the appearance, and therefore to separate the contents of the container. Not to use strong specificities, and thus avoid the ID, to continually think flexibility first, flexibility and responsive.


In addition, not to hesitate to minimize the impact of a single module on an element and thus, if necessary, to multiply the modules on the same object in order to apply several objectives.


It is necessary to favor the transversal re-use by avoiding falling into an excessive specificity, which would limit the cases of use. Think global and non-specific.


A small example ... let's say that the <h1> title of an article is styled in a certain way, and that the title of a <caption> table uses a large common base with the previous title, similarly for the title < h3> of a particular module ... The CSS approach could be


article h1,  caption, .module h3 {}


An OOCSS-style revision would be equivalent to implementing a specific rendering class of this title and adding it to each of the elements directly at the HTML DOM level


.title_emergeant {}


The obvious advantage is that it will not be necessary to isolate the caption selector, in case various modifications are necessary, and the evolution will be much more flexible, even if a particularity occurs on one of the elements, to add a class to this element


.title_emergeant_particularity {}


It is true that in Sass the use of inheritance, and / or placeholder, might suggest being a rather flexible alternative of use. Attention, as we shall see later, not to fall into this apparent easiest way.


%title_emergeant {}
article h1,  caption, .module h3 { @extend %title_emergeant; }


BEM notation, or SUIT CSS, methods


BEM (Block, Element, Modifier), is a methodology, or convention, for naming, and dividing by blocks, elements of the page. This does not provide anything at a purely structural level, although this specifies it. It however, allows to quickly defining a block, each of its elements and their possible states.


Contrary to OOCSS, BEM will rather integrate in a verticality specific to each module and less impose itself as element of transversality between the modules.


If we take the example of a module, BEM allows us to define various classes, having a first class to define the module itself, and, various classes which will qualify each of the elements the component, modify specifying the states, both of the module, and of its elements.


The classes corresponding to the various elements use a single hyphen separator, whereas the classes 'modify' use a double dash separator.


.module-title, .module-icon, .module-bar, .module-button
.module--inactive, .module-button--inactive, module-button--on


Basic Approach


We will see that this can be improved by also using a dedicated @mixin. But, this kind of naming can be implemented quickly and easily within Sass, notably through the use of the parent's referential character, &.


.module {
     &-title {}
     &-button {
          &--on {}


Using a name convention, BEM or SUIT CSS oriented, will give an architectural tree. Therefore, the main idea will remain to define a real BEM tree, in place of the classic tree of the DOM.




More Complex Approach


Since Sass 3.4, the enhancement of the parent selector (&) allows by coupling with the @at-root directive to use a real encapsulation. To highlight this point, let us support the excellent article by Marc Mintel - Pushing BEM to the next level with Sass 3.4


BEM and dedicated libraries


BEM does not stop to be just a naming convention, it can also be complemented by JavaScript libraries including i-bem.js, or component packages ready to be used, and some other works around jQuery.BEM or package like bem-js, as well as jQuery BEMHelpers.


If you wish, we could explore these uses in a forthcoming series of articles.


Suit CSS, another alternative


In parallel with BEM, we could also evoke SUIT CSS (Style tools for UI components), which is a method based on the same principle but which calls for a different division. We are talking this time about Component, Descendent, Modify, State and Utility.




Unlike the first two approaches, which propose a CSS implementation methodology, SMACSS (Scalable and Modular Architecture for CSS) redefine rather a methodology of work, (much of the work is free access).


Jonathan Snook delivers a large number of important keys that allow us to gather together to properly organize the deployment of CSS, but especially to guarantee its scalability and maintainability in a very simple way.


What we will retain, for our concern, is the declension of CSS into categories:

  • Base
  • Layout
  • Module
  • State
  • Theme


Sass, allows us to decline, and to increase, as much as possible, this granularity of cutting, because at the end everything can be very simply regrouped within a single file.


@import 'base';
@import 'layout';
@import 'module';
@import 'state';
@import 'theme';


Let us not forget that SMACSS, proposes an architecture that wants to be scalable and modular for our CSS.




ITCSS, (for Inverted Triangle CSS), proposes a distribution by degree of specificities and cascades, thus avoiding significant overloads, and often blocking.



  • Settings, allows grouping all the settings both at the level of the preprocessor (parameters, variables and map at the global level, environment ...), as well as the definition of typos and other colors used by the theme.
  • Tools
  • Generic, proposes the very first level of CSS with both the resetting of the default values of the browsers, the properties of boxes and the first definition of the different layouts specific to each device.
  • Elements
  • Objects, will group all the identifications by class, representing objects (in OOCSS philosophy), or molecules (Atomic Design).
  • Components, is a higher level of objects, also based on classes, with a BEM-oriented naming approach, and consisting mainly of organism (Atomic Design), complex objects (OOCSS) and interface components (UI)
  • Trumps, last level that can surpass previous and now mainly all utilities, helpers, states and other forces of the theme. Do not fear the use of the !important property for certain declarations.


Regardless of the layer, none of them must contain a selector based on the use of an id, #identifier.


Naming _partials.scss files can therefore use the root of these layers, for example:




Do not hesitate to get closer to this github which offers a good starting tree


Moreover, if we want to go further by coupling for example BEM and ITCSS this gives BEMIT and there is an excellent article on the subject, BEMIT: Taking the BEM Naming Convention a Step Further.


Atomic Design


From 2013, Brad Frost, began to publish a work on a particular methodology, and close to the atomic constitution of the elements. He also gave this name to his study Atomic Web Design, quickly completed and expanded by his book Atomic Design.


Like BEM and SUIT CSS, Atomic Web Design offers a cutting starting from the atom, molecule, organism, model and page.


The metaphor is quite appropriate, and if we replace it with elements of content, we end up with:


  • A label, a button or a title (in the role of atoms),
  • A search tool component (on the molecule side)
  • A fairly comprehensive menu bar (at the organism level),
  • A filling template (to embody the model, and, bring together all the organisms)
  • Finally, a site page (being an instance from the previous template).


To support this principle of establishment and construction, Create atomic design systems with Pattern Lab proposes a set of tools (Node and PHP).


This approach allows us to encompass all the previous methods, namely OOCSS, SMACSS, ITCSS and BEM.


One can therefore resort to partials,


@import 'atomic';
@import 'molecule';
@import 'organism';
@import 'template';
@import 'page';




Through these various methodologies, we have seen that using a class notation work is therefore a solution, certainly a matter of debate among the most purist of us, but oh so adapted to the maintenance of a great flexibility in the daily management of our projects.


The modular approach and the cutting into several files _partials.scss quickly brings a great flexibility to the maintenance of the sites.


In conclusion, we can retain three key words,


  • Modules
  • Naming
  • Divided


In addition, it is well on these three points that we will have to focus our use of preprocessors.