By Harry Roberts CHAPTER 1Think back to our Subway ingredients: carrot is excellent at being
carrot, because that is all it is intended to do. Carrot absolutely sucks at
being chicken, but that’s fine because it’s not meant to have anything to do
with chicken. The idea is that we have lots of tiny pieces of code that have
one single responsibility each. These responsibilities should never merge
or leak into each other, but they should play very well alongside each other
when combined.
oRganizing iT all
Now we have these lovely, Subwayesque, Lego-like, SRP chunks of code,
we have to start thinking about how to get them all playing well together.
Luckily, the way we outlined our house build is pretty much the ideal order
in which to form our style sheets.
A few years ago, before I started thinking about the SRP and granular
CSS, I often laid out my style sheets to roughly mirror the structure of a
typical page. It may have looked something like this:
- Reset
- High-level styles (body backgrounds, etc.)
- Header styles
- Page styles (content, subcontent, etc.)
- Content (forms, typography, images, tables)
- Footer styles
This is obviously a vast simplification, but I really did order style sheets
with no appreciation of how the CSS was structured, and with no real
regard for the cascade or inheritance. Since starting to work on larger sites,
I found that the most effective way to order rule sets was in inheritance or-
der. That is to say, every rule set should inherit from and add to the previous ones.
You start with your very basic stuff, your foundations, and you add struc-
ture, then components, then visual design. Your rule sets should be ordered