Why Most Developers Fear CSS

5 minCSS
Why Most Developers Fear CSS

When I started at my job, we were two front-end developers on my team. It was me and a senior front-end developer. Then the senior front-end developer quit his job, and I was the only front-end developer on my team. And it was fine. I did my job, and there was no harm. We had some job interviews, but we did not meet the right fit. The time went by, and then it hit me: I was the only one knowing anything about our front-end. The bus factor was at one, which is not a good number in this case. Why? If I get hit by a bus, the project will be in a bad situation.

I then talked to my boss, and we came to the agreement that we all should be responsible for the front-end. The work could be done in pair programming. At least until we would find the right match. I thought that was a great idea. I had a total burnout from working alone on the front-end.

We then presented the idea, and the first reaction was fear from the other developers. The fear was mostly concerned about CSS.

Why do developers fear CSS?

I talked to the other developers about why they fear CSS. The first thing brought up was cascading 😡 What if they make changes to one class, that will affect five hundred other elements?

The next thing brought up was support of browsers πŸ’» What if they implement something, that isn't supported in some browsers?

The final thing was building something from the ground up 🏑 What if they make something, that isn't solid and doesn't look good?

Cascading 😡

This is one of the biggest fears. When other developers are talking about this, I guess they are talking about many things. It is both importance, specificity, source order, and how properties inherit from different rules. The styling can be specified in many different places, and it can interact in complex ways. This is why CSS is so powerful, but it is also the reason why it can be confusing and difficult. The cascading can be a devilish thing if you don’t know the rules of how selectors can overrule other selectors 😈

Importance

This is a well-talked subject. We all know that it is (in most cases) bad to use this little helper. This is because !important will always win πŸ†

<h2 class="winning">This is a paragraph.</h2>
<h2 class="winning" id="not-winning">This is a paragraph.</h2>
html
#not-winning {
    background-color: gray;
}

.winning {
    background-color: black !important;

    background-color: gray;
    color: white;
    padding: 1em;
}
css

Specificity

Specificity is basically a measure of how specific a selector is. Like, inline styling is the most specific, then #id, then .class, and then the element. From there, the specificity can be measured in a million different ways. If you have doubts, you can use a specificity calculator.

<section id="wrap" class="wrap">
    <ul>
        <li><button class="button">One</button></li>
        <li><button class="button">Two</button></li>
        <li><button class="button" style="background: tomato">Three</button></li>
    </ul>
</section>
html
/* specificity: 0013 */
.wrap ul li button {
    background-color: red;
}

/* specificity: 0103 */
#wrap ul li button {
    background-color: black;
}

/* specificity: 0010 */
.button {
    background-color: yellow;
}

/* specificity: 0021 */
li:first-of-type .button {
    background-color: grey;
}

/* specificity: 1000 */
/* inline styling */
css

Source order

Source order is basically that later rules will win over earlier rules. If you write a selector with a property and a value, and then later on write the same selector with the same property - but with a different value. What will then happen? πŸ€“

<h2 class="blue red">This will be blue</h2>
<h2 class="red blue">This will be blue</h2>
html
.red {
    color: red;
}

.blue {
    color: blue;
}
css

Inheritance

Inheritance in CSS is both simple and tricky. It can be explained in this way: Some property values applied to an element will be inherited by the element's children, and some won't. Doesn't that sound great? 😡 CSS properties like font-size and color do inherit, and properties like margin and padding don’t inherit. I guess that you will have to use common sense in this one. If margin would be inherited, it would cause a huge mess! You could use MDN as reference.

Browser support πŸ’»

Unless your client is a company that only supports Internet Explorer 6, you shouldn’t worry that much. Most users are using modern browsers with great support of CSS. If you feel insecure whether you should use a specific property, then you can check it out at caniuse. If a browser doesn't support the property, but you really want to use it, then most browsers @supports the CSS at-rule of the same name. Then you can make a fallback solution.

@supports (display: grid) {
  div {
    display: grid;
  }
}
css

Building something from the ground up 🏑

This is mostly about the communication between designers and developers. The communication is not always that great. Sometimes the ambitions of the designers can be too high in relation to the company's wallet and the developers' skills - or what is actually possible.

The point is, that we as developers should be more integrated in the design process, so we all can feel comfortable with the outcome. With that being said, if the developer feels comfortable with the design, then it will be easier building it from the ground up.


I hope this wasn't a bunch of nonsense. I just really want to tell other developers, that don't work with CSS on a daily basis, that CSS isn't magic ✨

Thank you for your time!