Enforcing CSS Syntax Style (and more!)

I bet you have a style that you write CSS in, for the most part. You like 4-spaces, say. You always have a space after braces and colons. You always put a space after rulesets. You only ever put one declaration on a line, and the only declarations that can be multi-line are when they are big blocks like a gradient or a comma-separated box-shadow.

You might take this a little further and codify this. Perhaps you have a team meeting about it and decide on how you want to style code. You write up a guide and make it available for everybody on the team to see.

Clean code is important, you say. While style differences in code don’t actually matter in the final output (most of us have build processes in place that compress the code anyway), it matters for day to day work. A messy inconsistent codebase is hard to look at and hard to reason about. Jumping into clean code makes it quicker to stay in the right frame of mind and get to working on the problem at hand, not waste cycles being frustrated by the mess.

Harry Roberts recently even called it an litmus test for developers:

[Tidy code] seems like a very superficial thing to worry about, but to my mind, tidy code signals something more important: I would assume that a tidy developer has better attention to detail, is more likely to follow process, and is more likely to spot mistakes. Rightly or wrongly, I see it as a litmus test for more general approaches and attitudes.

Automated Style Checking/Warning

A step beyond just agreeing on standards is having your computer actually help you make sure you’re doing it right.

I’d wager this is a far more common thing for JavaScript or server-side language programmers. For example, ESLint is very popular. You configure it with loads of rules based on what your team decides is good syntax.

ESLint goes a litttttle further than just style checking, in that, for example, it knows if you use a function or not, or try to use a variable that is undefined. Tools like Rubocop for Ruby code are simliar. You can use them for style checking, but do more.

Style checking doesn’t have to happen in code editor itself. It’s pretty useful if it is, so you can fix problems immediately as you are authoring, but it doesn’t have to be. It might be more practical for a large and technologically-diverse team to make style checking part of the task running / build process setup.

For example, ESlint can be integrated into Grunt or Gulp, so when JavaScript files are processed, you see error output:

So there are multiple ways to incorporate style checking:

• Within a local IDE
• As part of a local task runner setup
• As part of automated testing
• Some combination of these

And you can take it even further. For example, treating linting errors like failing tests and preventing git workflow stuff. Like you can’t complete a merge request until everything passes.

Wait! We’re talking about CSS here!

Indeed. As far as I know, stylelint is the big player here. David Clark wrote all about it here on CSS-Tricks last year.

stylelint is very much like ESlint. You can incorporate it in the same ways: like as part of a task runner workflow, or right in your code editor.

At the moment I’m using Sublime Text, and here’s me using stylelint with SublimeLinter, the same exact linter UI thing I use for ESlint:

You’ll also probably do well by starting with a standard config.

What about opinionated CSS choices?

You could say that stylelint (and ESlint) are unopinionated. They are intentionally super flexible. You can incorporate whatever rules you want to (or leave out rules), and even when you add rules, they are designed to be flexible by either enforcing the rule one way or another and even allowing exceptions.

More importantly, I’d call them unopinionated because they aren’t exactly passing judgment on your code. But what if you want a tool to pass judgment on your code?

“Hey, you’re using too many floats!”

“Hey, that property isn’t particularly well supported!”

“Hey, @import is pretty bad for performance!”

That’s more like CSSLint territory, which has a variety of fairly opinionated rules.

There is some crossover for sure. CSSLint, for example, can check for duplicate properties just like stylelint can.

Can you use them together? Probably. Certainly, at the command line / task runner level you can. I’m not entirely sure how it would work to integrate them both into an IDE linter at the same time. Try it!

Maybe a comparison is helpful to wrap this part up:

• stylelint is a lot like ESlint (less opinionated)
• CSSLint is a lot like JSlint (more opinionated)

Can’t these things be actually automated? Like actually fix the problems for me?

This is what got me thinking about this stuff in the first place. I like IDE-level linting quite a bit, but I think I like the idea of the automated fixing of style even more.

We’re essentially talking about “prettifying” here (also known as “code tidying” or “beautifying”).

The new super popular kid on the block for JavaScript is Prettier, which I’d say is a good choice. But that doesn’t help us with CSS.

There is another one, JS Beautifier, that does work with CSS (and HTML!)

CSS Comb is another tool right up this alley. It is has far fewer options than stylelint (your call if that’s good or bad), and has a cool config builder for setting those rules. CSS Comb looks quite popular and well done, but I’m not going to recommend it any further, as it looks like they have stepped away from the project:

The tool is no longer being developed though we may still fix parsing errors and critical bugs. That means that you should not expect any new features or options.

CSS is changing plenty fast these days, so I’d be nervous incorporating a tool that won’t be changed. Kind of a bummer, because CSS Comb can do some things that others can’t, like re-ordering properties how you want them, which is pretty cool (although as always, there are options).

There might be a better option than these two…

stylefmt

Since the best bet for CSS style checking is stylelint, why not use the exact stylelint config for actually fixing the CSS! (Well, almost exact.)

That’s what stylefmt does. And, like most of these other tools that we’ve talked about, it can be integrated at the on-demand IDE level, or as part of task runners / build processes.

Here’s an example of me in Sublime Text with a SCSS file that has stylelint errors, and them being fixed with stylefmt:

Niiice.

stylefmt isn’t the only option, there is also perfectionist.

In Closing

Style checking is pretty cool. Not only can it be done, it can be highly customized to your liking. It can be incorporated anyplace into your process that works best for you and your team. For CSS, you’ll do well with stylelint. You can even automatically fix problems with tools like stylefmt. You can get pretty good coverage across your entire codebase as well, with things like ESlint for JavaScript and Rubocop for Ruby.