Most front-end developers don't like CSS.
Why?
Because working with CSS is frustrating. It's hard to troubleshoot mistakes because the feedback usually isn't helpful. There are no error messages. Nothing to nudge you in the right direction.
Most CSS problems are solved by trial and error:
Make a change
Save your code
Ask yourself, "does this feel right?"
If not, then rinse and repeat.
To be fair, this isn't inherently bad. You can solve a lot of smaller issues this way. That said, once you start running into bigger problems this isn't the best approach you could take. The process and output of that process can be error-prone.
Usually, you end up treating the symptoms instead of the root cause. Bandage after bandage until you're left with a mess of CSS properties that no one wants to maintain.
Most CSS development is inefficient
When you don't understand CSS, you have to solve all of your problems through trial and error.
This happens all the time.
A good example of this is the classic z-index problem. You're guaranteed to run into this at some point. For those who don't know, the z-index problem happens when two HTML elements overlap in the wrong order.
In the example below, I want B to be above A.
The easiest thing to do would be to increase the z-index for B until it works. In this case, that'd be fine, but that won't always work. There are all sorts of things that could affect the behavior:
The element ordering in the DOM (this might be important if you need to worry about keyboard accessibility for the overlayed items)
If there's another element on the page that has to have a greater
z-index(this is common for modals, app bars, sidebars, etc.)
In other words, you might not be fixing the underlying problem.
So what do you do the next time you have a z-index problem? I guess you can try to increase the z-index again, but things start to fall into a never-ending cycle.
Weak CSS skills lead to bad HTML structures
A bigger problem is when developers rely on HTML structure to solve CSS problems.
This leads to complex HTML. For example, if you’re using a component library it might seem like a good idea to reach for a built-in layout system. Sounds good in theory, but the problem is that you're forced to wrap your own components with library components for basic layouts.
This leads to the following:
More HTML elements in the DOM
More noise in your own code
Unnecessary indirection
In most cases, a few lines of CSS can accomplish the same thing.
CSS should be viewed as a unified system
Most CSS is written as a mixed bag of one-off properties.
A little padding here.
A little margin there.
This approach is hard to maintain. When there's no relationship between your styles, making updates and solving problems is more difficult. Most elements on a page should be styled in relation to one another. Instead of treating CSS as a mixed bag, it's better to view it as a unified system.
The behavior of CSS properties can change based on which layout algorithm you're using. Understanding these differences leads to a more cohesive and maintainable solution.
Understanding CSS layouts pays dividends
Learning everything about CSS can be a huge undertaking. Honestly, you probably don't need to (and likely won't ever) learn every single part of the CSS ecosystem. Instead of worrying about learning everything, it's better to learn things incrementally.
A good place to start is with CSS layouts. In my experience, learning how layouts work is one of the quickest ways to highlight the power of CSS and immediately add value to your applications.
Knowing when to use a layout algorithm leads to better solutions that require less code. Building a foundation around layouts ensures that the HTML in your application is cleaner and that it's easier to understand and modify because elements aren't deeply nested.
Better CSS mental models can change CSS development from being frustrating to fun.