Before you start this article is 90% disgruntled front end developer, with maybe 10% tips for good practice at the end. You have been warned.
Raise your hand if you’re a front end developer and at some point in your career been made to feel like what you do is easy, that the value you add to the team is minimal, that what you do can be done by anyone? If this is the case then you are part of the majority.
And too be fair CSS is easy right I mean any schmuck can do this:
So what gives me the right to complain? CSS takes literally no skill to code. And that is absolutely true, styling one element at a global level with no other CSS to worry about is easy.
So when does it get difficult?
Back end developer: I have implemented a new feature but I broke the front end, I fixed most of it there are just some simple tweaks for you to make, should be no more than 30 minutes work….
Me *Opens HTML file* tables every where, deprecated HTML tags, zero evidence of responsive design being taken into account. *Takes deep breath* Surely the CSS they wrote will be better. *Opens CSS file* fixed positions, clears left and right, and !important everywhere. *Slowly wraps mouse around neck*
Okay so maybe it’s not that bad all the time but I have meet very few back end developers who write usable front end code. And that’s fine it is not their responsibility to, but please don’t make a half arsed attempt and then expect the front end developer to clean up your mess.
So what makes for good CSS?
Structure, project structure is really important especially when working with large projects a good example of this Directory Structures That Help You Maintain Your Code by Steven Bradley, this article is aimed at SCSS but can be applied to normal CSS projects and it puts a large focus and modulating your CSS into more maintainable files.
Specificity, this is probably the biggest issue I face daily. Unfortunately most developers have a loose understanding of CSS specificity and this is what leads to the worst kind of CSS… !importants everywhere. So how do we remedy this? There are lots of naming conventions (see below) that focus on minimising the need for highly specific CSS selectors, however if this is not your thing I would recommend on avoiding selectors more than 3 elements/classes deep unless absolutely necessary.
Naming conventions, for any large scale CSS project naming conventions are a must IMHO. Without them CSS becomes un-maintainable and un-trustworthy, naming conventions allow us to easily re-use CSS through a project and remove un-used CSS if necessary. Some popular naming conventions are: BEM, OOCSS, SMACSS, and my own hiccup to name but a few.
Testing, this is the one most other developers seem to overlook do you know what is great about being a back end developer? You get to develop for one environment (the server your site will be installed on). Do you know what sucks about being a front end developer? 5+ Browsers and 1000’s of mobile devices… Good front end testing is a task and a half and takes a lot of time I see a lot of projects go overtime because testing is not taken into account and typically takes longer than most people expect.
So how do we fix this unrealistic view of CSS?
Stop letting them get away with it, as a front end developer we don’t get to write half arsed non responsive CSS for back end developers so why should they provide crappy useless markup and try and patch our CSS to a point where it does not work? I’m not saying get them to write it, tell them not to if it is easier. Just please stop letting other developers get away with thinking what you do is easy, it’s not, you work as hard as everybody else and don’t let anyone tell you different.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!