CSS is not as simple as it looks and developers often make some mistakes that leave them struggling with what to do. CSS is perceived as an unintuitive and difficult language to work with because of these common mistakes that thwart most developers when they try to write CSS. As a result, most developers opt to use CSS frameworks such as Bootstrap and Tailwind CSS to avoid writing their own CSS.
In this blog, we will discuss five common mistakes that developers often make. Recognizing and avoiding these mistakes will help you write CSS that:
Let's dive in.
This is one of my surprising discoveries and I have only realized that I have been doing CSS wrong all this time. Browsers have default styles that serve as a fallback if the stylesheet does not exist. However, these default styles are different across browsers. In any case, two browsers rarely provide identical default styling, so the only real way to ensure your styles are effective is to use a CSS reset.
A CSS reset entails resetting (or, rather, setting) all the styles of all the HTML elements to a predictable baseline value. The beauty of this is that once you include a CSS reset effectively, you can style all the elements on your page as if they were all the same to start with.
CSS reset is a blank slate that helps you have consistent styling across different browsers. Most often, this entails setting a margin:0 and padding:0, although there is a need to reset other elements.
Here is a sample reset code:
* { margin: 0; padding: 0; border: 0; outline: 0; font-weight: inherit; font-style: inherit; font-size: 100%; font-family: inherit; vertical-align: baseline; } /* remember to define focus styles! */ :focus { outline: 0; } body { line-height: 1; color: black; background: white; } ol, ul { list-style: none; } /* tables still need 'cellspacing="0"' in the markup */ table { border-collapse: separate; border-spacing: 0; } caption, th, td { text-align: left; font-weight: normal; } blockquote::before, blockquote::after, q::before, q::after { content: ""; } blockquote, q { quotes: "" ""; }
I am also actually guilty of using px units for font-sizes, margins, padding and height or weight attributes. While using px units can be fine in some instances, overreliance on them leads to accessibility issues.
According to MDN, Defining font sizes in px is not accessible, because the user cannot change the font size in some browsers. For example, users with limited vision may wish to set the font size much larger than the size chosen by a web designer. Avoid using them for font sizes if you wish to create an inclusive design.
However, px units are also bad for setting height and width for content, since content might also overflow if the user increases the default font size in the browser. Using px units in-media queries also affects the layout when a user zooms in or changes the default font size.
? Mistake
p { font-size: 16px; /*this prevents users from resizing the font-size*/ line-height: 20px; margin-bottom: 8px; }
✅ Correct
body { font-size: 16px; } p { font-size: 1rem; line-height: 1.25; margin-bottom: 0.5em; }
One of the most overlooked problems in web development is the use of over-qualifying selectors that are too specific and difficult to override. IDs selectors have more specificity in CSS, meaning you cannot override them or reuse the style in another component.
Always write your CSS selectors with the very minimum level of specificity necessary for it to work. Including all that extra fluff may make it look safer and more precise, but when it comes to CSS selectors, there are only two levels of specificity: specific, and not specific enough.
? Mistake
#header { font-size: 1em; line-height: normal; }
✅ Correct
.header { font-size: 1em; line-height: normal; }
In general, you should avoid using overly specific selectors in CSS. The CSS Specificity Tournament illustrates why it's a bad idea to use selectors that are too powerful. When a selector is very powerful in the tournament, it wins quickly and early on, which means the only way to beat it is to write an even more powerful selector.
This tendency for specificity to always escalate is known as a specificity war. Similar to stockpiling nuclear weapons, no one wins in this war—things only become more difficult to de-escalate as specificity increases. The best way to avoid a full-blown specificity war is to not use highly specific selectors in the first place.
Another mistake that I discovered when doing my research is the problem with named colors. Developers often ignore that what you perceive to be a specific color looks very different across browsers.
By saying: color: red; You’re essentially saying that the browser should display what it thinks red is. If you’ve learned anything from making stuff function correctly in all browsers it’s that you should never let the browser decide how to display your web pages.
Instead, you should go to the effort to find the actual hex value for the color you’re trying to use. That way, you can make sure it’s the same color displayed across all browsers. You can use a color cheat sheet that provides a preview and the hex value of a color.
? Mistake
.header { font-size: 1em; line-height: normal; color: red; }
✅ Correct
.header { font-size: 1em; line-height: normal; color: rgb(255, 0, 0); }
As a developer, one rule is to never repeat yourself. Therefore, you should find ways to minimize the number of lines of code that you write.
One common problem with CSS is understanding shorthand properties for things like margin, padding and inset. As a confession, I also struggle with this problem and often have to look to the documentation on whether margin: 0 5px sets the margin in top-bottom or left-right.
? Mistake
.my-cool-div { margin-top: 50px; margin-right: 0; margin-bottom: 50px; margin-left: 0; background-image: url(background.png); background-repeat: repeat-y; background-position: center top; }
✅ Correct
.my-cool-div { margin: 50px 0; background: url(background.png) repeat-y center top; }
Using shorthand CSS improves efficiency and makes it easier to maintain our code. However, this could take time to master and I recommend checking the documentation.
Position absolute is that one band-aid solution that can cause more problems as it breaks the document flow. When using positions absolute, MDN recommends that you ensure that elements that are positioned with an absolute or fixed value do not obscure other content when the page is zoomed to increase text size.
Position absolute should be the last choice since it has some effects such as pulling the element out of the flow and making it stack over other things.
Furthermore, elements positioned absolutely don't naturally adapt to changes in screen size or parent element dimensions, which can break the layout on different devices.
? Mistake
.sidebar { position: absolute; top: 50px; right: 0; width: 30%; background-color: #e0e0e0; padding: 20px; }
✅ Correct
.sidebar { transform: translateY(50px) translateX(0); /* Moves the element down by 50px */ width: 30%; background-color: #e0e0e0; padding: 20px; }
In this example, we see that we can achieve the same functionality without breaking the document flow by using transform to move the sidebar down by 50px.
Collapsing margins can be really hard to understand and frustrating to decode since you might not understand why your applied margin or padding is not working as expected.
The top and bottom margins of blocks are sometimes combined (collapsed) into a single margin whose size is the largest of the individual margins (or just one of them if they are equal), a behavior known as margin collapsing. Note that the margins of floating and absolutely positioned elements never collapse.
Understanding margin collapse is essential for achieving consistent spacing in your layouts, particularly in scenarios where you want to ensure a specific amount of space between elements.
One solution to collapsing margins is using padding, especially for child elements rather than margins. It is generally advised not to add margin to the child element, especially in JavaScript frameworks such as react since this might affect their reusability.
You must always remember that adding a margin to a child element can affect the position of the parent element as the margins collapse.
? Mistake
/* html */ /*Element 1Element 2*/ .element1 { margin-bottom: 20px; } .element2 { margin-top: 30px; } /* the total margin will be 30px rather than 50px */
✅ Correct
.element1 { margin-bottom: 20px; padding-bottom: 1px; /* Prevents collapse */ } .element2 { margin-top: 30px; }
Conclusion
I hope you enjoyed this article, and that it gave you a sense of how to avoid the topmost common mistakes developers make when they write CSS. There are many mistakes not covered in this blog such as separating between layout and content elements, overusing flex box and much more. Comment below with some other mistakes.
The above is the detailed content of SS Mistakes that Beginners Often Make. For more information, please follow other related articles on the PHP Chinese website!