Learn how to avoid making these most common mistakes with your CSS and how to fix them when you find them.
Why do I need to learn this? I hate CSS.
Trust me, when you implement code from a language you dislike learning, the rest of us can tell.
We need to know these things because Web Development is all about building on top of others’ code.
Whether you’re working with the latest version of a language, a new framework, or trying to make your product work with someone’s code, to be able to scale, you need a solid foundation.
Poor CSS practices will always create a faulty foundation and trying to build from that will ultimately crumble your efforts. Learn to avoid these mistakes and how to fix them when you find them.
Let's walk through the major mistakes I see people make with CSS on a regular basis, how they actually work, and how to fix them.
Not using Semantic HTML5
If you aren't building with HTML5 you need to start yesterday.
HTML5 comes with a lot of incredibly sensible HTML tags that help you not only create an organized document, but it also helps you build for accessibility, SEO, and reduce your code length.
A common mistake I see is developers overwriting an HTML tag's default display properties for no reason. If you are overwriting the HTML tags' default CSS styles, you need to ask yourself why.
This is because most web technology relies on the default display styles of HTML elements.
For instance, the default display property of a List Item is "list-item".
If you change the display property to "block", be sure you know why.
It makes sense for a horizontal navigation list item to be set to "inline", like this:
But it doesn't make sense for a sidebar area to have list items set to display "block". It may not affect the way you are styling the sidebar area, but it can affect the way another product uses this area and create a conflict.
Using the HTML tags that already use the display block property makes more sense and will be more compatible with other products.
How to fix it:
In this below image a sidebar and main area are using unordered and ordered lists with their styles set to display block.
As you can see the sidebar area and main content area are not aligned and the code is a little harder to follow.
Instead of an unordered list, use the aside tag as the main sidebar container and either section, article, or div tags when they make sense for the elements within the sidebar.
In this below image I have switched out the original HTML with Semantic Mark-up and removed the list item styles.
As you can see, not only are we using less code here, but it's also easier to follow, and it's already fixed a styling issue (alignment).
Using absolute measurements when relative would work better
Here is a really good take away, for responsive layouts
- Padding should almost always use absolute measurements.
- Margins usually should use relative measurements.
- Content containers should almost always use relative measurements
How to fix it:
In this below image we have a sidebar and a main area whose paddings are each set to 5%, a relative measurement.
Relative is the operative word, as you can see the calc directive on the main content area is trying to make the content no larger than 100% minus the sidebar (300px) minus the 10% which is the left and right padding of the sidebar added together.
The problem is, the 10% we are trying to subtract is relative to the main container, not the sidebar container. Trying to calculate the padding is not so simple.
You can see the absolute measurement by checking the element's box properties in dev tools but it's going to change as the page grows or shrinks with the device.
The only way to use this method and figure out the percentage you need to subtract from the main area is high level "Maffs", and if you're anything like me, you're not going to do that.
Now, in this below image, you can see the calc directive is much simpler to understand and ensures that the width of the main area keeps the sidebar next to the content.
The padding is set to 10px, so there will be 10px on the right and left of both containers. If you're still with me on this, that's 40px total.
The calculation here is much easier and our content is where it needs to be.
Position & Z-Index
I often see people using really high numbered z indexes, which is only necessary when you are creating a dynamic element like a modal window, or a sticky video player.
The problem is, even if you are using a really high numbered z-index, if it's relative parent element has a lower z-index than the parent element of another item using the z-index property, things start to get really weird.
Here's how to fix it:
This below image shows that the main and sidebar areas have a relative position, while the pop up and centered paragraph in the pop up have absolute positioning. Any positioned element has a z-index property. Whether you add one or not, a positioned element's default z-index is 0.
Note from W3C: If two positioned elements overlap without a z-index specified, the element positioned last in the HTML code will be shown on top.
Note that the pop up element is placed as a direct child of the main element.
Note in the HTML below, how the sidebar is also the last element in the body tag of the HTML
The main and sidebar sections both have been set to a z-index of 2 and the pop up has a z-index of 9999.
I resolved this not by trying to make the pop up's z-index even higher, but by changing the sidebar's z-index to 1.
!important - But is it?
I thankfully see this less and less, but I still see the important directive being misused.
MOST IMPORTANTLY DON'T USE THIS UNLESS YOU HAVE TO! I'm begging you.
The important directive was not developed as a lazy hack, it was not developed to be used when you don't know what else to do.
The best use cases for the !important directive are:
- To overwrite an inline style that shouldn't be there
- To overwrite a dynamic style you don't want to effect your element.
- When you need to control the behavior of an element so that it is always looking the way it needs to.
Here is an image of a heading with a class of red and an id of blue. Normally, an id would be more specific, but because of this important directive the red style is taking priority.
Here's how to fix it:
If you can't delete the unneeded important directive straight out of the stylesheet, then the only way to overwrite it, is by using the important directive, specificity and the cascade.
Important Directive; Yup! You have to use the important directive to overwrite the important directive. It sounds as dumb as it is. That's why you should be very careful when implementing it.
Specificity; Make sure your selector is using an id if available and as many parent elements as it takes to get that important directive to stop.
In this below image the heading color is overwritten by the style that is more specific. The style using both the id and the class name
Cascade; Make sure your style is implemented and read by the browser after the important directive you are trying to overwrite.
In this image both styles have the same selectors but the winner comes last.
We all make these mistakes when we are starting out, or before we know any different. There's no reason to beat ourselves up for not knowing something yet.
Learning how to recognize and troubleshoot these issues is going to help you solve multiple issues on a web page, design for scalability, and create solid products.