Don't like this style? Click here to change it! blue.css
Class 10: Principles of Great Code and CSS Preprocessors (by way of Stylus)
One of the main goals of this course is to look at the principles of good software engineering and teach them in
the context of visual web design. That is a new (in 2016) idea which is powerful and needs students like you to
spread. Here is a list, "Principles of Good Programming", which I am stealing from Christopher Diggins but they are all
well-known amongst good developers:
- DRY - Don't Repeat Yourself
- Abstraction Principle Every piece of significant functionality should be implemented in just
one place in the source code. When similar functions are carried out be distinct pieces of code, it is
generally worth combining them using abstraction.
- KISS - Keep It Simple, Stupid
- YAGNI (You Aren't Going to Need It)
- Do the simplest thing that could possibly work
- Don't make me think Code should be easy to read and understand (and debug/maintain)
- Open/Closed Principle Extending is better than modifying
- Write Code for the Maintainer Code spends more time in use than in development, make it easy
- Principle of Least Astonishment Someone reading your code should be surprised as little as
- Single Responsibility Principle A component of code should define a single well-defined task.
- Minimize Coupling Avoid as many dependencies as you can.
- Maximize Cohesion Similar code should be in similar components.
- Hide Implementation Details
- Law of Demeter Components should only communicated with their direct relations.
- Avoid premature optimization! "Premature optimization is the root of all evil" - Knuth
- Code reuse is good
- Separation of concerns Different functionality should overlap as little as possible.
- Embrace Change Code as if you will have to change the projects specs many times before
launch. (Hard to practice in a single semester course but very important to maintainable projects.)
The heart of this course
ignore almost all of these principles. What does it mean to to "minimize coupling" for a CSS design? If you were
able to just get your JS code working did you bother to go back and start applying the single responsibility
Reflection Task 1: Which of these did you violate in the projects you turned in
yesterday? If I were to ask you to make major changes to the heart of your game how little could you get away
with. Make a text file with your answers, including most honored principles and least honored principles for
Reflection Task 2: How did your CSS project violate these principles? Which of
these did you try to consider in your CSS? Which did you least consider? Add this to your text file and email me
the reflections for both projects in a single email to
The SMACSS system (the first book in our list of books)
is a loose set of guidelines which encourage you to rethink your CSS rules in a more modular
and well-engineered way. Specifically he encourages classifying/categorizing your rules into five categories.
Then use a naming convention to make it clear what category your rule is:
- Base The default rules for everything in your project. These are the rules that target tags
(also tags with pseudo-classes and siblings and such).
- Layout These rules structure the location of your elements that hold your "modules" together.
Use a class prefix like
- Module These are the main, reusable, parts of your design. The sidebars, callouts, captions,
etc. These can just be the class names without prefix like
- State These rules describe how your modules and layouts look in a particular state. Hidden,
on a small-screen, selected, etc. Use a convention like
.is-selected and mix the state rules with
module rules like this:
- Theme These are the very rare rules that override others when you want to re-theme/re-style a
page. The SMACSS convention is that they are named the same as other rules but kept in their own
I'm not looking to dogmatically assert these rules on you, but I do want you to have some structure to your
rules. Also you should think about them a little differently from the perpective of the above principles.
Refactor Task 3: Head to the CSS file for your first project. How are your CSS
rules grouped? (My guess is that many are based around the particular elements they are targeting.) Try to pick
a couple of rules and refactor them into base, layout, module, and state rules. How many classes did you have to
add to the HTML element to get it back to looking correct?
SMACSS from the source Task 4: Head to
a page of the SMACSS book
and inspect his source and classes. Find his modules, look at his CSS source, see how fine-grained his philosophy
SMACSS in the Wild Task 5: Head to http://chriswrightdesign.com/ and inspect his source and classes. This
guy has gone on record as a SMACSS promoter so let's see how his classes look and if the rulesets are reusable.
I now want to show you some of the amazing powers possible with a CSS Preprocessor and also warn you to only use
these when they are absolutely needed. There are two main reasons for this:
- CSS Preprocessors add complexity to your codebase. You might not agree with this since the code looks (and
truly is) cleaner. However, now
your code is tied to another technology that is not as well supported as CSS. When you move on from your
project you might have to hire a Stylus expert which is harder to find than a CSS expert. Making a change to
your codebase has to be done at the command-line rather than in the stylefile. You might need a
"build-process". The beauty has a non-negligible cost, so go vanilla until you can't.
- CSS Preprocessors should eventually be unnecessary and when they are you'll be dated. When
you start to work with a preprocessor you become a little weaker as a CSS thinker. The features that made
a preprocessor needed now should be part of the CSS specifications (check those editor's drafts). So if you've
grown to need a preprocessor then you will grow to be more and more obsolete. It is always better to push what
browsers offer than to try and go around the standards process.
So why learn these things?
The benefits are this (besides less verbose code):
- Variables and Functions (in CSS, how cool)
- Nested rules (some rules for paragraphs and also paragraphs with this class get this extra rule)
- Conditionals (use those variables to decide which rules to use)
- Extends and Mix-ins (my personal favorite: declare a selector to be an extension of other rule sets (and only
ship the used ones))
- Prefix-management (use nib to avoid the
-webkit, -moz, etc. mess)
Stylus as an example
I like Stylus because it ships with
npm and I like Node more than Rails (SASS ships with
gem). You can try other preprocessors on your own and play to your heart's content.
Hello Stylus Task 6: Head to Codepen. In the CSS gear icon select the "Stylus"
preprocessor. Now use the http://stylus-lang.com/ docs to make a
horizontal nav bar.
Stylus Level 2 Task 7: Now split into 5 groups. Each group select one of the
bullet points from my list of awesome things about Stylus. Master it, make a sample, share it in chat, present
to us what you did.