Introducing Bandit.

A methodology to write highly modular and scalable CSS in a modular and scalable application

Bandit It’s not something completely new

It steals ideas from the other great methodologies.

Problems Bandit wants to address

Have a low-maintenance environment

Solve issues with multi developer environments

Dead easy dead code elimination

Have a Smooth DX, visual order, simplicity.

Does Bandit fit in our project?

I’m assuming you are working with a modular application, using tools like Backbone/Marionette/Angular/React/Ember.

Better if you manage to require your css files together with your views at render time, there are ways to achieve that.

Files Organization in Bandit

All the files that create a module are contained within a folder.

Styles go away when module goes away (dead code elimination).

Also this structure is great if you want to load CSS asynchronously

Can work in React, Backbone/Marionette, Ember, Angular

App/

— — modules/

— — — — -MyModule/

— — — — — — — — js/

— — — — — — — — — -MyModule.js

— — — — — — — — styles/

— — — — — — — — — -MyModule-layout.scss

— — — — — — — — — -MyModule-theme.scss

— — — — — — — — templates/

— — — — — — — — — -MyModule.hbs

— — styles/

— — — — -partials/

— — — — — — — -_base.scss

— — — — — — — -_buttons.scss

— — — — — — — -_grid.scss

— — — — -global-styles.scss

— — — — -_variables.scss

Naming Conventions

Encapsulate module styles using a unique selector prefix

Like BEM, Bandit has a naming convention.

Only one strict rule: each selector in a module must have the same unique prefix. It could be the filename (if unique), it can be a composition. As long as it is unique. The rest is up to you.

Why the unique prefix? Encapsulated styles.

Unlike OOCSS and SMACSS, let’s not abstract as much as possible, let’s isolate as much as possible.

The styles for your module are confined, they won’t affect other parts of the application, they are kind of specificity risk free, so hopefully you will deploy with a free spirit ;)

You are also quite free to invent the naming convention of each module, everything after the first hyphen is scoped to that module.

Or better, you can choose all together a set of conventions that naturally fits in your project.

Principles of Bandit

Principle — Flat hierarchy of class based selectors

From BEM.

The module’s unique identifier isolates the rules so there is no need to use regularly descendant selectors to control your styles.

The benefits are quite nice. The descendant selector is the most expensive selector in CSS so the goal is to avoid it when possible.

We will use descendant selectors for example when we need to override a rule of a module because of a state change:

Principle — Abstract and organize some basic styles

This comes from SMACSS. I think there should be a common set of classes for basic elements or components, like Resets/Normalize styles, buttons, typography rules, or very basic components like avatars or dropdowns.

You could use a framework like Bootstrap or your own set of common styles.

Because of the first principle, we isolate the code, that means more code duplication*, so we want to have some basic styles abstracted:

view.html

view.scss

button.css

Principle — Separate skin and structure

From OOCSS. Each module has two optional css files, one for the structural styles and one for skin, like the visual features.

I call them -layout and -theme files:

DealsDocumentDetails.html

DealDocumentDetails-layout.scss

DealDocumentDetails-theme.scss

CSS output:

DealDocumentDetails.css

*This means duplicated code!

The output of the previous two files, compressed, is 891 bytes. That is the size of the styles you needed for that module. If your project is composed of 100 modules we can still produce less than 100kb of CSS.

If your code allows the injection of the module’s styles it’s even better. The code is loaded asynchronously together with the HTML it belongs to.