In the example given, the final result for the class names was simplified to

.correspondence-item
  .correspondence-item__title

Naming: the whole logic behind it is that some elements in the tree are redundant, like the list, so we decided to remove them (it’s a convention we made and it works well for us).

Structure: The reason why we don’t define elements inside elements in the form of .block__list__item__inner-element__inner-subelement is clarity and modularity.

Following the principles described in the post, each component is given a single responsibility. So an item that has a title, a subtitle and a link is a standalone block, responsible for styling itself and it’s children. It’s not linked to the parent in this case, which is reflected in the naming as well (e.g we would never add `width: 50%` to this block, because it would make it dependent of it’s parent context and we tend to avoid that).

A more controversial example would be if we need to add a wrapper inside the list element for styling purposes. We would only add a list-wrapper element to the correspondence block, inject it in the markup and that should be all. The concerns of the inner blocks won’t change.

So the focus is not on the markup structure, but on the scope of the block / element.

.correspondence__list
  .correspondence__list-wrapper
    .correspondence-item
      ...

and in the CSS I only need to add the extra properties for the list-wrapper element.

Handling things using this mindset makes structural changes a lot easier, especially when you’re dealing with a new product that constantly requires structural changes.

How would you approach adding this new wrapper in the mix, taking your original example?

.correspondence__list__item__title