When I started at my job, we where two front-end developers at my team. It was me and a senior front-end developer. Then the senior front-end developer quit his job, I was the only front-end developer at 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 burnt out from working alone on the front-end.
We then presented the idea, and the first reacting was fear from the other developers. The fear was mostly concerned about CSS.
HTML and CSS is for losers 🙄 We should all use Microsoft Word.
— Steffen 🖤 (@mrsteffenp) June 8, 2019
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 effect 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 🏆
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.
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? 🤓
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 support 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;
}
}
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 fell 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 doesn't work with CSS on a daily basis, that CSS isn't magic ✨
Thank you for your time!
If you liked this, then please ❤️ and follow me on Twitter.
Oldest comments (54)
!importantHush. We do not speak of it.
Shh! The rule that must not be named. The unspeakable rule.
At some point someone's going to have the bright idea to add in an importance factor, like Z-ordering, and further insanity will ensue.
Oh, I need this.
Good article! I'm mostly a back-end developer, but I do guerilla front-end when I have to. Can confirm it scares me.
Thank you so much! Maybe it is a good thing being scared sometimes. Okay, Google can't help me on this one. How are guerilla and monkey work different? 🤔
Haha, by guerilla I just mean that I rush in and rush out and do a very shoddy job :)
Exactly the type I'm describing over there :) dev.to/katsanos_george/the-real-re...
I completely agree. There are just so many developers having a biased opinion on CSS. And there are so many with a bad attitude. I think I will use the saying that knowledge is the best cure against fear 😃
Regarding the title pic: as a front end dev, I'm pretty scared of floating :D
I was left as the only dedicated front end dev in a company once too. It didn't decrease the bus factor to 1, since we exclusively worked with a 3rd party product, but I felt that I was the only one thinking about innovation in our front end.
I talked to the boss and got the permission to have internal workshops. Turns out, if you take the time to explain flex or svg hands-on, most back end guys can comprehend it pretty quickly and take their knowledge to production.
I love hearing stories like this one 😃 You are right. I have also explained CSS to back-end developers. Most of them have learned the basics of CSS in school at some point.
I ended up falling into mostly frontend work because nobody else seemed interested, and the work needed to be done. I think CSS is why. Backend work seems more "pure".
Trying to make things work cross-browser isn't as bad in the old days, but it's still a hazard to watch out for. Safari is usually the biggest problem IME, despite all the jokes about supporting IE.
Safari is the new Internet Explorer 😉 I am not even joking that much.
I think we will see a huge change on browser support in the future. There is a new thing called CSS Houdini, which will try remove these issues.
Houdini is actually one of my greatest CSS fears.
I'm afraid that, even if this allows you to seamlessly roll out a new type of layout rule, all this will create, ultimately, is more fragmentation in the ecosystem.
The thinking and strategy appears to be along the lines of "Just throw more JavaScript at it", which, time and again, tends to go all kinds of wrong.
CSS, like JS, is already bloated and messy, struggling to be all things to all people. Now CSS won't even be declarative in nature anymore - it'll depend on JS, and the two will fuse into a giant, hairy ball of mud.
With Web Components fusing HTML with JS, what used to be declarative, semantic markup is now unreadable gibberish - this will do the same for CSS.
The web used to be a homogenous, human-readable medium. Now every webpage will use it's own version of HTML and CSS, and no two sites will look the same.
I used to be optimistic about the web - but now, there are definitely times when I think HTML, CSS and JS are all f_cked beyond repair, and maybe we just need to start over with something much simpler that actually does what we need.
You are correct 100%. All used to be simple and uniform and clean. Now all is a big mess and super fragmented.
A lot of back end devs I know have little love for CSS for the simple reason that you had to write so much garbage for so long. Things are pretty different now with browsers at least trying to agree on how they interpet things like CSS. The legacy of internet explorer, and its refusal to align with other browsers, meant that a lot of what you had to learn and implement were just fixes and patches that could well be irrelevant a year or two later. Compare that to learning coding theory that will still make sense years later or with a different language and I can appreciate that many back-enders are more "reluctant" (rather than scared) to tackle front end coding.
You are so right! There has been so much development on CSS for the past few years. I do understand why some developers are reluctant to work with CSS.
Nice overview, thigh there is one failing... Css IS magic 🤓😉💫
We're not developers. We're magicians 😉🎩✨
Most developers like CSS
It's a vocal minority that casts shade.
I think you're absolutely right.
Great article, right on target. We use SCSS 4.6 with Wellington preprocessor SMACSS compliant. GoHtml5 templates. No JS now with WebAssembly. CSS can now be well organised and reusable, it is a different world.
Thank you! A lot have happened in the past few years 😃
Great article. I wouldn't use the word "scares", but I have a hard time picking names for classes, especially when there are child elements or wrappers involved. Somehow I don't seem to get that problem in backend context very often.
I think naming in general can be tough 😲 In CSS there several different ways to help organising. There are ITCSS and BEM, which combined is called BEMIT. There is also Atomic CSS, which I haven't tried out yet 😃
I have only heard about BEM so far, I'll look into others. Thanks :)