The Art and Zen of CSS Writing

Original author: Jim Jeffers
  • Transfer
I have been creating templates in pure HTML / CSS for over eight years. During this time, I was convinced that various agreements and documentation help in the work. Of course, they do not save from periodic CSS nightmares. They only make them less painful. My decision is to follow certain principles in writing styles. These principles form the basis on which all further style writing will be built, making it easier to work on a growing project.

Lesson One: Be Concrete Only Where You Need It


People are shy about making full use of style inheritance. Many who have worked with CSS for a long time write very sophisticated pseudo-selectors to handle a particular element. This is all good and cool, but contributes to the development of an unhealthy habit - we stop writing simple rules.

This lesson has been taught to me many times. I preferred to be neat. He wrote styles that were truly clear and specific. But this is bad. Special rules are pushed into a framework from which it is then very difficult to get out. Instead, more generalized rules will do the same job, and you will only have to add custom code when the situation requires it. Take a look at the example below:


The second rule will be applied to each paragraph on the site. But, firstly, it's good. Imagine how easy it is to add a custom rule later. With the growth of the project styles more and more, they become more complicated, and situations where some special rules are needed, arise by themselves. If we took advantage of inheritance from the very beginning, you can simply redefine the code you need when needed.

To see how you don’t need to do this, look at the example below (the third set of rules describes how to add situation-specific styles):


This is kind of like a basic CSS lesson. We can write styles that are applicable to most objects, and for special ones we can do more specific ones. Most people who write CSS know this. What they usually do not know is much safer to avoid unnecessary complexity without creating too special rules. Here are some things to remember:
  • The complexity of your styles is directly proportional to the complexity of your selectors.
  • Refactoring CSS selectors to reduce their specificity is much more difficult to write initially simple rules with the addition of more complex sweat.

Lesson two: You have to start somewhere


You work alone or as a team - you need to start styles from the same thing. A reference point is a set of rules that determines what behavior you expect from your environment. This is usually important if you are working on styles all the time, and even more important if there are several developers. Everyone should see the same page, so having the same foundation is the best trick to help with this.

My reference point is Eric Meyer's CSS Reset. Unfortunately, using reset styles for production is a moot point. Experienced developers believe that this is unnecessary or simply bad, but in fact we all use a dump in one form or another. The reset problem is actually what it is called. This is not a reset, it is the foundation on which our expectations of browser behavior are built.

In fact, even if we don’t use CSS dumping, we still have to implement it, only in an even more sophisticated form. We repeat ourselves around, where necessary, in order to achieve the desired behavior. The most famous example is margins. Each browser for each item has its own default styles. No normal person can remember them all.

If you do not set your reference point, you have to work with the browser. This means that the development environment is becoming less predictable and controlled. This is actually scary.

I'm not saying CSS dumping is the holy grail of writing good code. Not at all. It can be your headache if you don't fit it properly. After all, many do not like any settings in the reset file, for example, disabling the fat content of an element. This is because someone else's reset file is just an example. You and your team need to refine it to your needs. If it is necessary that it is bold, correct the discharge. Over time, you will develop your reset.css (although you really should call it base.css). Key points of this lesson:
  • Own basic (fault) styles allow you to better control the environment.
  • For development teams, the same basic styles are the key to ease of collaboration.
  • Basic styles do not guarantee cross-browser compatibility, but still give the expected result.

Lesson Three: Rely on the Concreteness of the Rules, Not Their Order


The basic principle of CSS is that if you write two identical selectors, the last one will be prioritized. In other words, order is important. But this is quite dangerous - the order will affect if you write selectors of the same priority.

With the increase in styles, they are getting worse and worse. In order not to complicate the work, we divide the files into sections. Or even divide the rules into separate files.

The hope of order in our code makes it fragile and unreliable. After all, with the introduction of any code organization strategy, we can easily destroy the order in which the rules followed initially. And this is important, because, as I said, it is more convenient to write generalized rules first. This does not mean that for the organization of the basic code, the order should become fundamental. If you have two rules with the same weight that can conflict, you need to make one of them more “heavy” so that this code can then be used in the framework.

In addition, in most cases, when we have properties rewritable due to the order in which they follow, we are dealing with duplicate selectors. These cases are a perfect example of how code might need refactoring.

Key points are:
  • Styles that are rigidly tied to the order of the rules are unreliable and prone to problems associated with the reorganization of the code.
  • Rules that can be overridden due to their order of appearance in the code can or should be rewritten.

Lesson Four: Be Clear and Expressive


You need to have a good idea of ​​what you want. You must clearly know how and what should be done in your document. How is this done in CSS? Very simple - by commenting. We can provide enough documentation in our CSS files just by commenting them. Comments can be used for:
  • Descriptions of best practices.
  • Indication of organizational issues.
  • Providing links to resources.
There are two problems. First, few people use comments in style files. Second, many authors do not see this as necessary. The second, apparently, follows from the first.

Let's think about why we are not writing comments or documenting the code, even if it is useful. The first reason is that our files from this increase in size. Yes, this is true, but you can easily use the YUI Compressor, or write a simple script that automates the process of reducing files and removing comments from production code.

The second reason is that you are most likely the only one who will work with these styles. This is very short-sighted. Always, always (always!) Think that someone can ever work with this file except you. You will not work on this project forever. In other words, reckon with the fact that someone will probably add or edit your styles. You can either suggest how to do this best without you, or clean and rewrite everything yourself when you are asked to repair a broken site.

Being able to speak clearly is much harder than it sounds. What is the best way to tell you what you expect from the contribution of another developer? Personally, I write my best practices in the form of short tutorials with examples and comments at the beginning of the file. Something like this:


The point is that you can use comments to clearly and clearly explain the manner in which code should be written. Just format all your files in a certain way. Textmate users can use a special bundle for this. What you need to remember on this topic:
  • Use comments to indicate how code should be written and formatted by others.
  • Always remember that someone else can work on the file after you.
  • Use comments to partition code. Comments can help navigate documents.
Translator's note: experienced developers have nothing to read here, they should already know all this. On the other hand, a relatively recently written article touches on points that are rarely covered in textbooks and tutorials on HTML / CSS. At one time, I made the same conclusions on the basis of bitter experience, therefore, I think, for beginners who have not yet experienced all the sorrows and hardships of the incorrectly laid foundation of development, this article will greatly help. Still, really - best practices.
I take this opportunity to convey my regards and thanks to the developers of the translated.by service


Also popular now: