What I learned about CSS
By: Adam Shaffer
Tags: Atomic Design, Coding, Heirarchy, CSS, Scss

“If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon and explode once a year, killing everyone inside.”

-Robert X. Cringely

I’ve always had a love hate relationship with programming. The fun side to programming is solving problems and building. The darker side to programming is the challenge and frustration of translating your ideas and thoughts into a language the computer can understand.

Unlike human communication computers do not allow any wiggle room. It forces you to refine your thinking. One line of code changes and everything breaks. Code that worked fine at one moment can spiral out of control the next leading to frustration and possibly panic.

Photo by Sebastian Herrmann on Unsplash

As a front-end web developer, I am always a little surprised at how much time and energy I end up spending on CSS (Cascading Style Sheets) for each project. I haven’t timed myself, but I honestly would not be at all surprised if I spend 90% of my time in front end development with CSS. Maybe that’s a bit of an exaggeration but I am confident it accounts for the majority.

As aspiring web developers, I am sure we all need more time to brush up on our skills in a multitude of areas. Often, it can seem that we are stuck on simpler CSS when we should be building our strengths in the latest frameworks.

So, to minimize the pain for my fellow web developers, I would like to present a list of basic rules of thumb I have developed from my experiences and failures with CSS.

Consistent Layout

Before you begin a project pick a layout style that is most appropriate to you and to the project. This has two major benefits:

Photo by William Iven on Unsplash

1. It keeps your thinking organized. You know what to expect at every level of the site’s structure. You don’t have to make any accommodations or exceptions in terms of outline. Most importantly you have a path laid out in advance.

2. It makes the CSS code more streamlined. A consistent layout will naturally lead to cleaner CSS code. Thinking in a consistent way about your layout will lead to thinking more consistently about sizing, font sizes, margins, padding, etc…

Personally, I prefer grid. Based on the work I’ve done it can accomplish most or all of what flex can while being superior in responsive design. I haven’t found anything that beats it so far.

Atomic/Hierarchical Design

Don’t jump into it blind. Have a plan. Start by thinking of your page hierarchically. More specifically as a nested hierarchy. Much like Russian nested dolls, the higher order elements should encompass the lower order elements below. As the old saying goes “a place for everything and everything in its place.”

Photo by Blake Weyland on Unsplash

I also highly recommend studying the theory of atomic design and applying it. It is an excellent analogy for understanding how to design your page. It uses the analogy of atoms -> molecules -> organisms -> templates -> Pages. Thinking of your project overall in a hierarchal and atomic way helps organize and streamline your thinking. It also makes debugging your code down the line much easier.

Understand Specificity

When it comes to using specificity there are some basic rules we need to get out of the way.

1.!Important is a big no-no. Use this only as a last resort. It makes it more difficult to debug code in the future. It also marks you as an amateur. Resist the temptation.

2.Do not use inline styles. Always use separate stylesheets. This one is pretty easy. I’ve never felt the need to use inline styles and it makes your code less maintainable.

With that out of the way let’s understand how specificity works. Each CSS selector is assigned a specificity number that ranks it relative to other selectors. The specificity number consists of four numbers as follows:

[style][id][attribute][element]

The numbers of selectors are compared and the selector with the higher specificity number applies to that element. Each number in a slot represents how many selectors of that type are in the selector. For example, take the following two css selectors:

.classone h1 p

#textid p

The specificity numbers for the two are as follows:

0012

and

0101

The first selector contains two tag names and one class name. The second selector contains one id and one tag name. The second number beats the first because it has selectors at a higher slot irregardless of the numbers in the lower slots.

Let’s look at a second example:

.classtwo .classone h1 p

.classtwo h1 p

The specificity numbers for the two are as follows:

0022

and

0012

The first selector contains two class names and two tag names. The second selector contains one class name and two tag names. In this case, the first number beat the second because it has a higher number in the highest slot. The first selector will apply to the element.

Beyond comparing the specificity numbers, you should keep in mind a simple set of rules:

1. If two or more selectors have equal specificity number rankings, then the last selector listed in the CSS file is the one that counts.

2. The last rule applied to an element overrides any previous conflicting rules.

3. Universal selectors and any inherited selectors have a specificity number of 0,0,0,0.

4. Embedded stylesheet rules override CSS in external files.

Simplicity

“Everything should be made as simple as possible, but no simpler.”

-Albert Einstein

Photo by David van Dijk on Unsplash

A good rule of thumb that has guided me in my journey is to be smart but not clever. This is good advice for all web developers and programmers. A simple solution implemented effectively is almost always more sustainable than a complex rule implemented poorly. My greatest failures have involved choosing the later over the former. To help you avoid this pitfall my advice is to focus on these areas.

1. Naming: An important first step for maintaining simplicity is picking consistent and understandable naming conventions. Pick class names that point to the div or elements place and purpose in the project as opposed to specific properties. Also ensure that the names are easily distinguishable from each other and fit into the overall heirarchy of the page. This creates a logical link between the HTML and CSS.

2. Minimization: Less CSS will always be easier to manage than more CSS. Be careful to reduce unneeded redundancy in CSS rules. For that matter avoid applying CSS rules to elements that don’t need them. If a CSS rule has no appreciable effect on the layout and styling of an element consider removing it. You can always add the rule later if it proves necessary.

3. Modularity: Don’t be afraid to split your CSS into multiple files. A large file with many lines of code can quickly become unmanageable. Even if your project doesn’t use a preprocessor such as SASS or SCSS it is a good idea to split your CSS into discrete chunks with separate concerns. The human brain can only keep track of so much information. Don’t overload it.

4. Minification: Eventually your CSS file will be complete and streamlined. At this point consider minifying the CSS file to reduce load times. A great online resource for this is cssminfier.

Resources

If you would like more information, I have found the following resources to be invaluable in learning and improving my skills in CSS.

1.CSS Tricks — This is a well-structured site maintained by dedicated people with straightforward articles written in clear language.

2.CSS Garden — This is a an excellent that site that uses a garden game to teach grid layout.

3.FlexBox Froggy — This is another great resource that uses a game about hopping frogs to teach flexbox.

4.Free Code Camp — Free Code camp is an excellent resources for web development topics in general with tutorials and projects for web developers of all levels.