The following is a guest post by David Racodon. David contributes to this open source code quality tool he’ll tell you all about. I hadn’t heard of it until now, but I know there are lots of folks out there interested in tooling to help keep their CSS in check. This is a bit like CSS lint but formalized into an interface that handles code quality for a whole project.
The quality of CSS tends to degrade over time. You start a new project and it’s squeaky clean. But, slowly, over changes and maintenance, technical debt adds up. It gets even worse with projects with many different maintainers or employee turnover.
The vast majority of CSS developers I’ve met do care about their code cleanliness, and also feel like they could be doing a better job.
I work on and with a tool called SonarQube, which is specifically for developer to improve code quality.
What is SonarQube?
SonarQube provides feedback on code quality for a wide range of languages including CSS. A web interface provides an overview of your project code quality.

From there, you can drill down and SonarQube can show you problem inline directly in the code, such as potential bugs like duplicated properties:

Or duplicated selectors across files:

Or any other of the developers’ seven deadly sins.
There’s a demo of these features that you can check out, too.
Where to start? New code.
What if you analyzed your code right now? If you’re lucky, you’ll only have a few dozen issues. But what if you have a few hundred? What should you start working on then? Let’s frame it another way. If your bathtub has a leak, would you first start mopping the floor or would you try and fix the leak first? I believe (or at least I hope) that most of you would try to fix the leak first.
SonarQube provides what you need to focus on new code: the differential views. They allow you to compare the current state of your code to a previous state.(A previous state might be the last analysis, the beginning of the sprint, a version in production, etc.) and highlight new issues.

In the example above, you would just click on +9 to display the 9 new issues introduced since the last analysis and start fixing them.
What sort of CSS checks does it perform?
Over 50 are available at the moment. Here’s just a few examples:
Potential bugs:
- Duplicated properties: Bad copy paste? Intended for cross-browser support? A comment would be nice in this case though
- Property value should be valid otherwise they will just be ignored by browsers. Not just a basic CSS2 validator, it also takes into account CSS3 and values commonly accepted by browsers. See the full list of validators.
Coding guidelines
- Selectors should follow a naming convention
- Units for zero values should be removed
- Stylesheets should not contain too many rules
Cross-browser compatibility
- Standard properties should be specified along with vendor-prefixed properties
- Deprecated system colors should not be used
Trying it
SonarQube is open source and free. To get your code analyzed in less than two minutes, a SonarQube package bundled with the CSS plugin and the analyzer can be downloaded here (see the Download ZIP on the right hand side).
Or, see the in depth documentation.
Learning more
Convinced? Go further by automating the analysis of your code with your favorite continuous integration service. There are also plugins for JavaScript, HTML, and other languages. You can use it to review issues, evaluate your technical debt, and many more.
Feedback on the CSS plugin
Along with Tamas Kende, I contribute to the SonarQube CSS plugin. We’re not exactly CSS gurus and we’re sure that the existing rules could be improved and new rules could be added. Your feedback is more than welcome! Post to the SonarQube user group or ping us on twitter at @kalidasya and @DavidRacodon.
The first error example is kind of scary. If I wrote a second margin-bottom in the style, it’s probably because I wanted to change it, and in any case, the second one will overwrite the first one.
So the suggestion to delete the second property definition is THE WRONG SOLUTION. It will change the appearance of my site, probably in a way I don’t want. Instead, it should flag the first one as unnecessary because it’s been superseded.
It is in the same selector, so it would not override anything, it is just a duplicate. Overriding would happen if you had another selector with higher specificity with the same rule.
Also, just because a rule is superseded by another one doesn’t make it superfluous. It may very well be used in another, less specific context.
Wahoofive is completely correct. In a CSS rule with duplicate properties, the second property always takes precedence over the first, thus rendering the first rule void.
Given that fact, more often than not, you’ll want to delete the first duplicate, not the second, since your site has been living with the value provided by the second rule.
Yep. Agreed. Flag first as unnecessary.
@wahoofive:
What is really ‘scary’ in the first example is that the
margin-bottom
property is duplicated.That is for sure a mistake in this case. That’s why SonarQube points out the issue. Then, you, as a developer, should take the proper remediation action: remove the first definition of
margin-bottom
if you think that is the proper fix.SonarQube has no way to guess, but for sure, most of the time, the first definition would be removed. So, I’m going to log the issue on the first occurrence (instead of the last occurrence) of the duplicated property: https://github.com/SonarCommunity/sonar-css/issues/133
Thanks for your feedback
I would simply flag the duplicate property, not suggest a solution. The dev will have to examine it to determine which is the correct one to keep. And he is correct, the second one will override the first one. This has nothing to do with selector specificity; sorry to say it, but you are incorrect Max.
Awesome. very Nice Described. Thanks
regards
https://www.bunnytechs.com
I tried this out from reading this article but was disapointed to find a lot of shortcomings with the css plugin. It won’t do SCSS, nor does it work if you’re outputting minified CSS. Where this fits in to my workflow is unclear.
@MrChristopher
Nor Less. But, we hope to tackle those languages in the near future.
SonarQube is a tool to check code quality. So, it doesn’t really make sense to run it against your minified CSS. You should run it against your actual CSS code before minifying it. Thus, you should add this code quality check before your minifying step. Also, you can break the build after the code quality check if it does not meet some requirements (such as ‘new blocker issues have been introduced’), see http://www.sonarqube.org/quality-gates-shall-your-projects-pass/
As you’re outputting minified CSS right from your SCSS code. The added value would be indeed to analyze your SCSS code, not the output minified CSS code.
Why not just use the W3C CSS validator?
@raj
As described in this post, SonarQube does much more than CSS validation. See available checks at http://nemo.sonarqube.org/coding_rules#languages=css
im getting
this error Luiss-MacBook-Pro:package-test-sonarqube-css luisbetancourt$ sonarqube-5.1.1/bin/linux-x86-32/sonar.sh start
Starting SonarQube…
sonarqube-5.1.1/bin/linux-x86-32/sonar.sh: line 417: /Users/luisbetancourt/desktop/package-test-sonarqube-css/sonarqube-5.1.1/bin/linux-x86-32/./wrapper: cannot execute binary file
Failed to start SonarQube.
Luiss-MacBook-Pro… It looks like you’re on a Mac machine.
linux-x86-32… It looks like you’re trying to run a command written for a 32-bit Linux machine.
Can you try to run the right command?