Writing CSS Rules for a Better Relationship with Stickler CI

When you start this way of learning the fundamentals of HTML and CSS you can find a lot of web sites that can help you to know HTML semantic tags, how to name classes, how to write rules for tags, events, animations... and even how to use more advanced models as FlexBox and CSS grid.

Suddenly after intensive practice, you finally achieve this position of knowing how to use every tool you have available and “start thinking in CSS”, and it feels great! But there is something else. For creating excellent CSS rules there are a lot of standards that have to be followed in order to it looks more organized and easy to read for other developers. Until now, when writing HTML and CSS we are not programming yet, but we are writing code for making the pages good looking, and remember: 

Maybe you are not a master in designing webpages yet, but for making sure you are, at least, writing your CSS in a good manner there is an automated tool called Stickler CI. 

I have used this tool for a while and it has helped me a lot to fix the styles of my CSS files. The most important thing: it is not just for CSS but for most of the languages you probably know as Javascript, Ruby, Python, GO, Java, PHP, Typescript, etc. 

Something that happened to me is that most of the time I used Stickler it was a painful process to fix all the 573 style errors the console throws me. It means, at least, one hour of correcting just typos, enters or empty lines, and even the order of the written rules and that’s why I decided to write this article.

For now, I’m just going to talk about how to write CSS rules to make this process of reviewing your code more friendly, and start coding with these rules of style in mind so you can minimize your stickler errors at the end.

The main rules of style in CSS you must have in mind I’m going to list them now:

1. Begin bracket at the end of the rule name

2. End bracket one line after the last rule of the block

3. Indentation of two spaces

4. Make sure you are not leaving blanks spaces after any line

5. At the end of a block of rules, there should be an empty line

6. When having a block of rules for more than one class (class, id, or element tag) put each one in a different line

7. 0 Values: Don’t add px (or any unit measure)

8. If you are going to add comments, they should be one line comment

9. Selectors as

before

and

after

should be preceded by a double colon:

I have classified the next rules as advanced because they need more code analysis when it comes to fixing them. It is not just typos but ordering on how the rules have been called.

Here instead of listing rules, I’m going to explain with real examples.

Imagine you already fixed all typos, indentations, and removed blank spaces and run stickler again to validate your file. Sometimes you can find some errors like the one below:

¿What’s happening here? It says rule called

.funding-description > span > a

should be written before rule

.news-box > div > h4 > a

, but why? I went back to review my HTML code and realized that the last

funding-description

class was at line 378:

And when I looked for

.news-box

class I found that one block of

.news-box divs

are from line 136 to 226 but another block starts at line 723 and the last one appear at line 818.

Here Stickler is no t validating the order of appereance of the class in HTML but the level of access of the element

a

.

Let’s see another example:

It looks like a case very similar to the first one. Rule

.latest-title > h3 > a

has to come before the

.new-box

rule, why? Well, we reviewed HTML and found the last appearance comes at line 244.

So, that’s again the same validation. As

new-box

rule has a level of access major than

latest-title

rule, so it has to come after it.

And now a pair of examples with

hover

selector: 

So what is the issue here? I see the last appearance of

popular-topic

is at line 676.

But,

left-menu

has only one appearance and it is at line 30:

As in the cases above, what happens here is that stickler is reviewing the level of access of the selector

a

:

As

.popular-topic > a

is only two levels and

left-menu > ul > li > a

is a four-level selector, it has to come before the

left-menu > ul > li > a

selector. 

Now, what happens with a

hover

selector? Pseudo-classes as

:hover

are always tied to an element, a class or an id and always has to be not only after the same rule without the pseudo-class but also after all the rules at the same level without pseudo-class.

Now, let’s analyze this stickler validation:

So, as we said before,

popular-topic

class appears the last time at line 676 and

left-menu

,

right-menu

and

latest-menu

classes are before that line, but their level of access is major than the level of

popular-topic > a

. That’s why it has to appear before the other selectors. 

Finally to have a general view of how a CSS file should look after fixing all stickler errors, let’s see the next illustrations:

At the beginning all the one level selectors in order of appearance.

All the rules from two-level to N-level of the same element and selectors with pseudo-classes at the end of that block. Example:

Rules for the element a:

Rules for the element a, with hover, ordered by level of access:

And basically, those are the frequent stickler errors you are going to find when validating your CSS. Better you’ll be prepared and recognize them before Stickler sends you a list of one thousand errors to fix! @.@

What I would recommend you for facing basic errors is to install the plugin called Stylelint, which helps you to fix the typos while you are writing. Only you have to add the file .stylelintrc.json to your folder project and start writing CSS!

And for advanced errors, I’ll try to add more details when I find more examples, but I hope that, until now, this article helps you to understand what is validating stickler and face better and faster the resolution of those errors it shows you.

Thanks for reading! And happy coding!