CHAPTER 1 Modern CSS Architecture and Front-End Development
This is a sensible order in which to build a house; we can’t hang photos
before we have walls, and we can’t erect walls without foundations, so we
have to assemble things in a certain order. That is not to say we have to
make the individual parts in a certain order, certainly not. Our ornaments
might be antiques made hundreds of years ago, but they can’t become part
of the house until we have our shelves in place.
Let’s carry this analogy over to our websites, then. Our foundations are
our CSS reset; our grid systems are structure; components and widgets
are our fixtures and fittings; our design is the decoration; and, finally, any
skinning or theming (for example, a special offer badge on a product, or a
Christmas-themed logo) are our ornaments.
Again, we could design our components and widgets long before they
are dropped into a page, but when it comes to assembly order there needs
to be a page there to drop that component into. We need to build things in
a certain order, so why not start breaking our code up there?
So now we should be in a position to start breaking our build up into
logical chunks, for example:- I want to use normalize.css, so that needs to go in first.
- This is what grid system I will be using.
- This is what I want an unclassed h2 to look like.
- This is what the store locator widget will look like.
- This is what the store locator widget will look like if there are no stores
in your area.
We can keep all of these things nice and separate, so we should. We have
convenient, natural points at which to start breaking our code up into pieces.
These little pieces leave us with code which adheres to what, in the
computer science field, is known as the single responsibility principle. My
diluted and very high-level definition of the single responsibility principle
is basically: code that does one job, one job only, and one job very well.