Pay attention to the following points when CSS rules are stacked

The theoretical basis is necessary, and the practice is the method to improve and understand the theory. The two are equally important. Any design and development staff can leave the balance between the two, regardless of which side they prefer, will be fan or left or right errors. But what is the purpose of this method in actual application. Obviously, it cannot create rounded rectangle for us, nor partition layout for us. It is even more difficult to provide us with a navigation bar fixed in the document header. This Algorithm The practical application is: Good CSS programming specifications. This is a macro practice, which is equally important as the micro practice I just mentioned, but is even more difficult to grasp.

This article does not want to include all the good CSS programming specifications, nor is it possible. All I can provide is a summary of my individual CSS coding standards, I think these specifications are as close as possible to the nature of CSS operations.

Do not use inline CSS
User style is not under your control
Do not use important rules
Write CSS based on particularity from low to high
The first three are not my points. I will take them with me.

The special nature of inline CSS is the highest. If the attributes in your CSS file conflict with Inline CSS, the attributes in your CSS file are invalid, this is not consistent with our habit of debugging styles in CSS files only. Inline CSS is also ugly. It inserts styles into HTML documents, so you should discard using inline CSS.

If you set the user style to important, no matter how you write CSS rules, the user's important statement cannot be overwritten. Therefore, it is futile to try to overwrite all user styles. We are glad that we do not need to consider this.

Important rules are different from each other. They do not conform to the conventional way of thinking. No matter how we increase the particularity and order of CSS rules, important rules will cover the Rules competing with them, this will also disrupt the regular pattern of CSS rules and cause troubles for debug. If you want to use the important rule for the hack browser, you should apply the rule in a selector pointing to a unique element. (PS. Hack should be the final consideration in the solution because it looks too ugly .)

Finally, how can I write CSS from low to high according to the particularity?

The key lies in modular CSS.

Add global CSS
Add unified CSS for the current page
Divide the page into several modules
Use Id hooks for different modules and class hooks for the same module
Add unified CSS for each module
Divide each module into several sub-modules, and return to Step 1 to start the cycle until the style is added.
Compiling good CSS is a design issue, not an implementation issue. First, we should write global CSS content with very low specificity, that is, our commonly used reset.css. It is the default style of all pages on our entire website.

If a page has a unique unified style, for example, if the background of a page is different from that of other pages, you can add an ID to a page, then, write the unified CSS of the current page under the ID.

Body # Special {
Background-color: black;
}
After compiling the unified style, we divide the page into several modules. If these modules have basically the same style, use the class hook. If the style is not the same, use the ID hook, in the future, this principle should be followed every time we divide modules. Because the class is not very special, we should not use the class if it is not a seemingly similar module. The ID name can generally be used as the name of a module. Such as head and bottom. Id selector plays a key role in the cascade. Because ID is exclusive and has a high degree of particularity, it can prevent CSS rules from being inadvertently overwritten.

In a certain module, we may have some unified CSS, so we need to use ID selector to compile the unified style under the current module.

# Head P {
Color: red;
}
When adding a class hook, we recommend that you use the ID of the parent module (or the page itself) as the first part of the class name. If I add an independent page (body # Special), after dividing the page into modules, I should name the modules on this page as special_head and special_bottom.

Or head_col should be used when class hooks are used in some page modules. We do not need to use

# Head. Col {
/* Style of each column in the header */
}
You can directly use

. Head_col {
/* Style of each column in the header */
}
So you don't have to worry about naming conflicts.

The ID selector element is directly added to the module. You can directly use this selector and add the ID of the parent module before its name.

# Head_navigator {
/* Style of the navigation bar in the header */
}
To implement modular CSS, we should try our best to prevent the emergence of cross-module CSS. I think a good principle is: if a similar cross-module feature is not clear to you, do not use cross-module CSS. One exception is the global CSS or the unified CSS in the module. For those that are not clear at a glance and do not have a uniform style, we recommend that you define them under each submodule. This is like writing JavaProgramIn the same object-oriented design, we need to reduce the mutual dependency between modules so that the CSS rules of the same modules are separated if they are slightly different, which is not only easy to maintain, it can also ensure that CSS is compiled from low to high, so as to prevent CSS rules from being accidentally overwritten.