Avoiding Rookie CSS Mistakes: The Basics
Ever look back at your work and think, “What was I thinking?” In reworking this site, I had that record playing on repeat. I built my original portfolio site back while I was still learning code, and so I’ve had to face all those rookie CSS mistakes.
Naturally, being a good friend, I want to help you avoid making the same beginner CSS mistakes. In the next few posts, we will unpack some of the basics of writing better, cleaner CSS by deconstructing the code in my original site. Then we will put everything back together for a leaner, cleaner style sheet.
What Is Good Code?
I won’t lie. I thought my original site was
If you had looked, you would have noticed some things. First, my CSS stretched for miles, and it was hard to read. Then if you looked at my HTML, many of the pretty effects required markup that had nothing to do with the rest of the page. Take a look for yourself.
All that said, we ought to start this series by talking about the hallmarks of a
- Semantic
- Organized
- Concise
- Accessible
- Valid
You could argue that there are other marks of good code, but this list makes a good starting point for rookies. Plus, I don’t know if my pride could take going through 6 or 7 principles. That’d just be cruel.
Semantic Code
Quality CSS begins with quality HTML, and that HTML should be semantic. Semantic code has to do with how you mark up your content with HTML. You can almost think of HTML as being a language we use to tell a computer what’s what in your content. For instance, look at this HTML snippet.
<h2>Awesome Cat Names</h2>
<ul>
<li>Sprinkles</li>
<li>Garfield</li>
<li>Thunder</li>
</ul>
The opening h2 tells where the headline starts and what level of importance it has in the overall page. Then the closing h2 shows where the headline stops. The opening and closing ul show that Sprinkles, Garfield, and Thunder belong to a unordered list where the order does not matter. And each li shows what is an item on that list.
Writing semantic code means that you have thoughtfully labeled your content with HTML markup that make sense to the context. A paragraph is a paragraph. A header is a header. An article is a piece of content that could be shared or reused. You get the idea.
Extraneous HTML Elements
So why bring this up when we are talking about CSS? Glad you asked. It’s all about the purposeful use of the code. HTML should be used for content, and CSS should be used for appearance. (And JavaScript for behavior.) As a novice, I found myself adding stylistic components to my HTML, but now I know better.
Consider how hard it is to speak with someone who constantly goes off on tangents to make themselves look good. They may bounce around subjects so much that you lose track of what you were talking about in the first place. The conversation devolves into a terrible experience.
Building a website is like facilitating a conversation between site owners and site users. Adding unnecessary structures to the HTML interferes with its core function.
Was That Element Necessary?
Let’s use the animation I showed you above as an example. That animation sequence eventually appeared on my About page. I built the About page to introduce myself to potential employers, but do you think an animation of the aurora help or hinder that message? Just because I could add it didn’t mean I should add it.
Then consider the how it would be to read the HTML out loud to yourself. The headline says this page is about me. Then suddenly I jump to three images to create the aurora. Then I jump back into a paragraph talking about myself. The northern lights has nothing to do with anything else on the page.
Maybe this sounds nit-picky to you, but shouldn’t a pro sweat these types of details? After all, the person whose screen reader depends on semantic HTML to navigate would surely appreciate this detail. I’m sure that any site owner would appreciate if automated crawlers could do a better job indexing their site, too.
If you must have that extra visual flourish, don’t forget that CSS allows you to add visual content with pseudo-elements. A pseudo-element allows you to display content before or after an element on the screen, but it does not affect the HTML. That means you achieve the look you want while keeping your HTML semantic. Win-win.
Abusing HTML Elements
Along those same lines, many beginners feel tempted to misuse HTML elements to make text take on a particular appearance. For example, they may use an h3 when the situation really calls for an h1 or h2 because they like the default text size assigned by the browser. This problem becomes especially prevalent when users rely on a rich text editor or WYSIWYG editor for formatting.
Fortunately, I knew better than to abuse HTML elements like that when I first built my portfolio site. I may or may not have been guilty of this crime back in the days of Geocities though (dating myself there), so let’s look at the right way to handle this problem.
First, educate yourself on the correct way to use HTML elements. The W3C specifications explain the correct way to use each element. You may find the explanations on W3 Schools or MDN easier to understand though. We will explore this in greater detail when we look at writing valid code.
Then use CSS declarations to achieve the look you want. A browser like Safari or Chrome comes with a default set of styles for each HTML element called the user agent stylesheet. The appearance of any “unstyled” element relies on basic CSS that has been set for you.
Use Your Browser To Write CSS Correctly
You can see the user agent styles easily by inspecting the code. In most browsers, just right click over the element you want to know about. Then choose “Inspect.” This will open the developer tools where you can see all the styles applied to the element including user agent styles.
So let’s say you like the font size of the default h3 but the headline you want to style should really be an H2. You can recreate that look by declaring a new font-size without butchering your HTML. Even better you can use the developer tools in most popular browsers to preview changes you before adding them to your code.
Developer Tool Panels
First, open your developer tools and inspect the h2. You should see one panel containing the HTML, one panel containing CSS, and maybe another panel for the console.
In the panel with the CSS, you will see all the CSS declarations that apply to that element. These are listed in order of where they fall in the cascade. Items near the top have higher precedence (which is the exact opposite of how it works in the actual CSS). If a style is canceled out by another in the cascade it will have a line through it.
Changing the CSS Rules
All of the text in the CSS can be edited by clicking it once. Any changes you type will be automatically previewed in the browser. You can also use the up and down arrows to change number values. If you type something that won’t work, the developer tools will cross it out and show an alert to let you know it’s invalid.
You can also test out selectors. To try a new selector, click the plus sign at the top and type in the selector and the styles you want to apply. When you’re done you will be able to see how your new declaration will work.
If nothing seems to happen, then you know either you typed something invalid or another declaration is overriding your styles. You can simply scroll down and see which declaration has taken precedence over yours. Then change your selector to be more specific. Once you get the element looking how you want it, you can copy and paste your new declaration into your CSS.
To Be Continued…
As a beginner in CSS, you may be tempted to take the easy way out and abuse HTML to achieve a certain look. Don’t do it! Remember good is semantic, so your HTML based on how the information is structured not its appearance.
In the next post of this series, we’ll dive into the other hallmarks of good code including accessibility and organization. In the meantime, I suggest that you experiment in the developer tools because the only way to stop making rookie CSS mistakes is to practice.