CSS Bliss: Main Peculiarities of Methodology

Among numerous methodologies of styles organization (BEM, SMACSS, OOCSS, SUITECSS) one really stands out - CSS Bliss. It is the quintessence of usability and readability.

First of all, let's define the main concepts: module, element and modifier. These concepts are closest to BEM, except for the fact that Block is called Module in CSS Bliss. Later it will become clear why Module is a more suitable term. All in all, the methodology itself is very similar to BEM but has its own peculiarities. These peculiarities deserve to be discussed separately since they are exactly what allow CSS Bliss to take one step up over the other css methodologies.

CSS Bliss

The main differences of CSS Bliss

1. Naming of module, elements and modifiers

In BEM, the main separators are "-" and "_":


but CSS Bliss improves readability by using capital letters:


As for me, it is very difficult to distinguish between a dash and an underscore, even more so if they look almost identical with the only difference in a shift for a couple of pixels down. Whereas capital letters highlight and divide into words the parts which represent a single name.

Perhaps, it's not clear through an abstract example. Let's take an example closer to a real project. Compare:

<li class="custom-user-menu__list-item_size-normal"></li>
<li class="CustomUserMenu-listItem--sizeNormal"></li>

The first BEM's version is longer and more complicated to read. Especially its modifier, which merges with the name of the element. The second (CSS Bliss) is more compact and is visually split up into understandable components: module, element and modifier. Moreover, the difference in the first letter instantly allows us to understand what we're looking at: a module or an element (a module begins with a capital letter, while an element starts with a lowercase one).

If I still haven't convinced you, here's another example from BEM documentation for "key-value" modifiers:


It is difficult to imagine where such unreadable constructions could be of any use. To my mind, it would be more appropriate to use either another name or find another way of splitting into elements and modifiers.

2. Components positioning

A module is independent and self-contained on its own. It should look similar in any place and any resolution. That is why a module has one important restriction: it mustn't contain properties which would strictly define its positioning, namely - its size (width), outer padding (margin) and positioning with respect to other elements (position). These properties should be either specified in the module modifier or this module should also be an element of an external block, given that this element defines its position.

This important difference makes modules really independent from neither their location on a page nor screen size. It is easy to reuse them.

3. Structure organization

Although BEM has a conveniently organized file structure, it suggests excessive subdivision: each modifier and element is stored in a separate file. Here's an example:

├─── popup
|    ├──── _target
|    |    ├──── popup_target.css
|    |    ├──── popup_target_anchor.css
|  &nbspnbsp; |    └──── popup_target_position.css
|    └──── _visible
|         ├──── popup_visible.css
|         ├──── popup.css
|         └──── popup.js

Meanwhile, CSS Bliss implies creating files only for modules. Its internal elements and modifiers are specified inside this very file, because they don't make any sense outside of it.

├─── modules
|    ├──── _PopupDialog.scss
|    ├──── _Btn.scss
|    └──── _ElmInfo.scss
├─── _base.scss
├─── _colors.scss
├─── _mixins.scss
├─── _zindex.scss
└─── application.scss

In addition, you can create common files for the whole project, which is also very handy.

4. The state of an element

Very often we have to define the state of an element or a module: active, hidden, available, used and so on. Using a modifier for this purpose not only obstructs the readability of html, but also pollutes javascript.

An example in BEM CSS style:

<div class="my-module__my-mlement my-module__my-mlement_my-modifier-with-state"></div>

An example in Bliss CSS:

<div class="MyModule-myElement isState"></div>

In the latter example, in order to change the state in js, we use customary and universal "isState" instead of a long modifier name "my-module__my-element_my-modifier-with-state". As the state is defined only for a certain module or element, it has only local impact on them. And if need be, a universal name of the state allows to reuse the js-code for different elements of the page.

5. The use of @extend

Personally, I'm against using such ability of sass as extending classes with the help of @extend. The main requirements to CSS should be:

  • simplicity,
  • readability,
  • easy changeability.

With the help of @extend you extend original classes with an additional code, what is more, from any other place. In spite of the apparent simplicity of the concept, @extend fundamentally contradicts the basic principle of cascading styles; makes it difficult to manage and read the code. No wonder that CSS Bliss doesn't allow using @extend for classes and elements.

6. Documentation

Apart from the usual documentation on the site that describes CSS Bliss, there exists an interactive walkthrough with examples for developers. Here you can not only check your knowledge in correct understanding of the methodology, but also work out through actual examples how it is better to solve particular tasks with the help of CSS Bliss.

It's the best applied documentation I have ever seen.


Despite the wide popularity of BEM in recent times, the overall blend of all pros and cons of Bliss CSS allows to conclude that it is much more practical. Like other methodologies, it develops the habit of thinking not in terms of a page, but in terms of its components: modules, elements, modifiers. This makes the process of writing CSS more self-conscious, because the correct splitting into components determines not only the beauty of the code but also the viability of styles in the future.