... opening ...
Rule 0: Styles work opt-in, not opt-out
The problems of CSS can fall into many categories, but the most notorious one in my book is styles affecting things they weren't meant to affect. Examples:
- I defined a default
buttonstyle, now I want to use bootstrap but cannot
Organise your styles into small modules
.....Make your modules....
I like to compare CSS modules to import statements in Python. If I do
import myapp.blogposts, I can now use the functionality from "blogposts" module, but the import itself doesn't cause any visible effects. Similarly, including
myapp/blogposts.css on my page should load the corresponding styles and make them available to me, but shouldn't itself affect how the page looks.
The library actually starts doing its things if I fire a
myapp.blogposts.get_last(). Similarly, the CSS module should only do something when I use a class name that is defined in it.
Whenever you define a CSS module that doesn't obey these rules, you put a pair of handcuffs on yourself. Imagine situations like "augh, I just want to put on my page but once I include the styles for it, everything else will suddenly break because one of its dependencies also redefines paragraph spacing".
There should be very few exceptions from this, here are my picks:
- global reset -
normalize.cssis the go-to choice nowadays, a safe approach of evening out browser differences while keeping basic HTML conventions in place
box-sizing: border-boxglobally is also handy (and just plain logical), many third-party components like Semantic UI go as far as to actually depend on this being a global
Page defaults can go to modules too
I'm sure you want