Principles of Modular CSS

Modular CSS is a way of organising your CSS, and other assets, into discrete and re‑usable chunks.

CSS is easy to write but a bugger to maintain.

Some key principles

Build what you need. Start simple. Stay simple.

  1. ID-based CSS selectors must not be used. IDs have a much higher specificity, which can then lead to all sorts of specifity wars when trying to apply a style.
  2. HTML elements must not be used in CSS selectors. This means classes can be applied to any element eg <input class="button" type="submit"> and <button class="button">pushme</button>.
  3. Only use the module for one bit of functionality. This is the Single Responsibility Principle.
  4. Class names should be functional & independent of content. Again, this makes a module re-usable in different contexts.
  5. Modules must have unique names.

Visibility

A guiding principle in Kanban development is to make work visible (Kanban 看板 literally means billboard in Japanese).

To this end, use a styleguide, from the beginning. Groundwork comes bundled with Fractal, a magnificent, automated, styleguide builder. So long as your module folder has an HTML template file (we use Handlebars), then the module will appear in the Fractal styleguide.

To start Fractal locally:

$ fractal start --sync

Big kudos to Pattern Lab by Brad Frost – very inspirational work with a lovely interface. Personally, I like the idea but find the layered granularity difficult.

Also worth a look is http://styleguides.io/ a website of styleguides curated by Brad Frost and Anna Debenham, and the book Front-end Style Guides by Anna Debenham.

Testing

Test Everything!

There are simple CSS lint tests in assets/css/test/test.css, from Harry Roberts](https://twitter.com/csswizardry)’ Healthchecks.

TODO: implement more testing…

Further reading

This just scratches the surface, there is a wealth of information out there: