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:
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability."
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.
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
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
should be written before rule
.funding-description > span > a
, but why? I went back to review my HTML code and realized that the last
.news-box > div > h4 > a
class was at line 378:
And when I looked for
class I found that one block of
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
Let’s see another example:
It looks like a case very similar to the first one. Rule
has to come before the
.latest-title > h3 > a
rule, why? Well, we reviewed HTML and found the last appearance comes at line 244.
So, that’s again the same validation. As
rule has a level of access major than
rule, so it has to come after it.
And now a pair of examples with
So what is the issue here? I see the last appearance of
is at line 676.
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
is only two levels and
.popular-topic > a
is a four-level selector, it has to come before the
left-menu > ul > li > a
left-menu > ul > li > a
Now, what happens with a
selector? Pseudo-classes as
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,
class appears the last time at line 676 and
classes are before that line, but their level of access is major than the level of
. That’s why it has to appear before the other selectors.
popular-topic > a
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!