<aside> 👉 See the new style guidelines for CSS/LessCSS.

The original proposal is below.

</aside>

Between Djblets, Review Board, Power Pack, and various extensions, we have a lot of CSS to maintain, and this CSS has a lot of complexity to it. LessCSS and plugins help, and we've achieved some decent organization of the files, but there's more we can do with the naming.

Our CSS naming patterns generally look something (hand-wavy) like this:

.my-component { ... }
.my-component-active { ... }
.my-component-horiz { ... }
.my-component-vert { ... }
.my-component-child-element { ... }
.my-component-child-element-mystate { ... }
.my-component-child-element-grand-child-element { ... }
.my-component-child-element-grand-child-element-mystate { ... }

But at other times we don't prefix some parts of it:

.my-component { ... }
.my-component.active { ... }
.my-component.horiz { ... }
.my-component.vert { ... }
.my-component .child-element { ... }
.my-component .child-element.mystate { ... }
.my-component .child-element .grand-child-element { ... }
.my-component .child-element .grand-child-element.mystate { ... }

NOTE: The example here is intentionally a bit exaggerated — we could certainly trim the child-element part from the grand-child-element rules, but it demonstrates how long CSS names can get. As we'll see, this is addressed explicitly in BEM and its variants.

Picking one form and sticking to it is fine, but the former is verbose, and the latter leads to collisions.

This isn't the only issue. We have many problems to consider:

  1. We have a lot of CSS, and we want to organize it and, hopefully, help it be self-documenting.
  2. It's far too easy for us to have conflicts, particularly as we introduce new CSS down the road. Review Board is extensible, and Djblets is pulled in by projects. Extensions are going to define their own CSS, and pull in other modules with their own CSS. Companies integrate their stylesheets and bits of UI into our product. So many places for style names to conflict.