There is JSLint for JavaScript, PHP_CodeSniffer for PHP…why not have some sort of code checking tool for CSS? Based on the outcome of several code reviews we had at Yahoo! Europe, I thought that it would come in handy having a tool that would catch findings automatically. So over the last couple of months I was working on such a tool and called it CSS Reviewr.
It is quite similar to a couple of tools that are already out there. JSLint looks for issues in JavaScript code and checks for adherence to a certain set of code standards. PHP_CodeSniffer, a PEAR package, provides similar functionality for PHP files (but is also able to check JavaScript and CSS). Then there is CSSTidy, a parser and optimiser for CSS, which e.g. compresses hex values for color declarations and provides different levels of minification (removing comments, whitespace etc.).
Essentially, what I wanted to achieve with CSS Reviewr is to not only point out issues in the code based on the experiences and the reviews we conducted at work, but also to provide explanatory text for each finding (much like how the W3C Validator does it for HTML). In one or two sentences, I wanted to explain why this is an issue and how it can be resolved. From my perspective, this is ideal for a developer who might not be familiar with a certain best practice or convention. By reading the explanation and maybe following a link to a page that provides more details, it has a certain learning effect to it.
CSS Reviewr, as it is stated on the page, is not a validator. It is encouraged to run your code through the W3C CSS Validator first, before checking it using CSS Reviewr.
Last, but not least, I would like to thank the real brain behind this: Sam Riley. I had the pleasure of working with him on Yahoo! Answers and I was and am still really impressed by his sheer endless knowledge of the ins and outs of CSS. Knowing that I would not be able to just turn to the side and ask him whenever I have a question related to CSS (because I relocated from London to California), I wrote this tool also to store his CSS knowledge somewhere for myself, so I could still use it here in the US 
So a big thanks to Sam!. Also thanks to Eva-Lotta, who kindly offered to do some visual design work for this in her spare time.
The tool is in beta right now and I have already identified some bugs myself that I need to fix at some point, providing I find time for this. Getting some early feedback from colleagues, I have also received the following feature requests:
- Indentation check (selectable option)
- Check (background) images used in the code are akamized/on a content delivery network (CDN)
- Fonts should not use uppercase characters (e.g “Arial” should be “arial”)
- Limit the amount of errors shown to 50 to prevent browser (FF2) from crashing. Add something like: “More than 50 issues found. Fix the issues above first before checking your code again.”
- Having a ‘Do it!’ button by each issue to make the suggested modification to the code, and then have a textarea at the bottom where you could copy out the fixed version
Suggestions, bug reports and all kinds of feedback welcome. Just leave a comment below. Thanks and happy holidays!
Wowee, this is excellent Klaus! Really, really powerful stuff.
Feature request time:
• Against each of the rules you’re enforcing, it would be great to see citations for the reason behind it. Either a link to an article that justifies it, or a short chunk of expanded text explaining why you should do something a certain way. For example, in the post above you make the point about using ‘arial’ over ‘Arial’. I didn’t know about that one, and I presume there’s a robustness based reason behind it. Having a quick click to find out about why one syntax is better than another would definitely help the education benefit of this tool.
Great work!
B
It’s really good to see this finally out in the wild, Klaus.
That said, I’ve got a few questions, feature requests and the like. So, here goes:
* First off, is there a list somewhere of all the recommendations the tool makes? Having this list available and browsable would be incredibly valuable in my opinion.
* Currently the tool doesn’t pick up on repeated semi-colons at the end of CSS rules. Whilst they aren’t bad per se, they’re a stylistic thing that might be worth picking up on.
* Slightly more important is the fact that the tool doesn’t pick up on “missing” semi-colons from the end of final CSS rules. Again, whilst not invalid, these semicolons being missing did cause issues with earlier versions of Safari.
* When CSSReviewr finds issues with a CSS file, the title of the page changes to “[Invalid]“, which seems a little harsh, since CSSReviewr is checking the style, not the validity of the CSS document.
* As a feature request, it would be lovely to be able to turn rulesets on and off, in the same way as JSLint allows. Having this feature would also make the rulesets used by the tool public, which I feel would be an educationally good thing.
Oh, and one more thing – you’ve got a GitHub repo for this – why isn’t the code for the site in it?
Oooh, here’s another one I noticed the reviewr isn’t noticing. If you have a shorthand rule and a longhand rule that overwrites it, the reviewr isn’t picking up on that and suggesting that you merge them. The example I saw in some CSS I was looking over was:
p {
margin: 0;
margin-top: 5px;
}
The reviewr probably should have suggested merging that into `p { 5px 0 0 0; }`.
What a great tool to add to a web developer’s arsenal! I remember you talking about this app back at Yahoo so it’s great to see it come to light after all this time.
I’ll certainly be putting it through the mill and suggesting any feature requests when they arise.
Good work Klaus.