Developers should use a concept called shame.css to silo any quick-fix 'hack' CSS in projects, according to Harry Roberts, senior UI developer at BSkyB.
Roberts explained in a blog post that this would potentially stop developers seeing hacks peppered throughout CSS and thereby think such things are acceptable by default.
Additionally, the article noted that such an approach, if properly documented and accompanied by the means to iterate, could enable faster progression towards cleaner CSS in projects where hacks were used (for whatever reason).
.net spoke to Roberts (HB) about hacking CSS and the potential advantages shame.css could bring if correctly used.
.net: Do you think there’s a tendency from some people in the industry to be unrealistic about the need for (hopefully) short-term hacks to get a site working?
HR: Big time. If you work on a site or product that earns millions of pounds per year, any bugs, breakages or quirks need fixing as soon as possible. Your product owner doesn’t care if your CSS is perfect — they care that the site is up and functional and ticking over that revenue. Good code is important, and hacks are far from ideal, but to think you can always prevent hacks and short-term/quick fixes is nave.
.net: So you’d say they’re just a necessary evil within business?
HR: When a client is breathing down your neck — or a feature is broken on a live site — you need to make sure you’re keeping the right stakeholders happy. If you spend an hour writing the perfect fix for something you could have superficially fixed in two minutes, I’d say you’re keeping the wrong person happy — ie yourself!
In my own work, I’ve found the ‘need’ for hacks increases fairly proportionately with the size of the project, but the good thing about that is that you also will likely later have more project time dedicated to fixing those hacks.
.net: Which is where shame.css comes in. With that concept, what specifically do you consider a CSS hack?
HR: Something that could've been done better given more time. It’s hard to think of examples out of context, but I think you’ll often know when something is a hack. Written something that you’d be ashamed to explain to a colleague? That’s probably a hack!
Therefore, shame.css is about making a file of things you could have done better, and that you can do better when you’ve time to revisit them. It’s a self-writing to-do list, really — a file of hacks that you put to one side to think about when you have more time.
.net: In your article, you mention documenting hacks, but isn’t there an argument developers should generally be documenting CSS more anyway, rather than just for hacks?
HR: Yes! If there’s one thing all developers should do more, it’s writing comments. You should comment anything that isn’t immediately obvious from the code alone. Document your code so that, if you get hit by a bus on your way home, your colleague can take over the next day.
.net: In terms of integrating shame.css, what do you suggest?
HR: If using a preprocessor, @import the shame.[scss|less|etc] file right at the end, ideally. (This could always lead to specificity and source-order problems, so your mileage may vary.)
If you’re not using a preprocessor, but have a decent build process, all your CSS should be concatenated and minified before deployment, so, again, shame.css can bolt on to the end of that.
If you aren’t using a preprocessor and you don’t have a build process, then one, you should probably fix that, and two, a hacks section at the end of your stylesheet is probably your best bet. Shame.css isn’t intended for public viewing, so never have a separate stylesheet called by a link element in your mark-up. You should serve one concatenated and minified stylesheet only.
.net: If shame.css as a concept really takes off, how do you think it could change design process and websites in general?
HR: Shame.css is only as useful as the developers who implement it. It’s all well and good isolating and documenting hacks, but if you never fix or revisit them, you’re just in the same boat as before.
For me, shame.css signals a broader shift in development; it doesn’t need to be limited to CSS. The concept is merely ‘realising, documenting and making a point of your hacks’. You can apply that thinking to everything.
The real work involved with shame.css is getting your immediate team (developers) on board, and then making the business/PMs/scrum masters/BAs/product owners (and so on) aware of the fact that a product will sometimes include less-than-ideal code, but that this code exists to meet business requirements.
Tell them you are isolating and documenting hacks and get some development time allocated to tidy things up. It’s easier to make a business case for tidying up a code-base if you can quantify it. Simply telling your project manager, "I have some things to tidy up before I can move on to Feature X" won’t always cut it! Take a list of things to your PM and try and get half a day of sprint time to spend cleaning up.
The idea behind shame.css is simply to make your hacks more transparent, quantifiable and isolated. It’s up to you what you do with that information!
