CSS SASS Style Programming Guide_HTML/Xhtml_Web Page Production

As more and more developers use SASS, we need to pay attention to the number of SASS codes. We can start from the syntax of CSS (cascading style sheets) to explain some of the special features of SASS syntax. After all, CSS style guides are very common.

This article mainly introduces some features that I am personally interested in. You may be able to benefit from them and form your own set of SASS usage guides.
Continue to maintain your usual CSS formatting rules and style guides

This article focuses on some aspects of SASS, but on this basis, developers should maintain their existing and good formatting rules. If you haven’t developed your own set of formatting rules yet, here’s a review of some style guides that should help you develop your own CSS writing habits. Here are just a few of the things included:

1. Keep the line indentation consistent
2. Keep the number of spaces before and after the colon/braces consistent
3. Keep one selector per line and one rule per line
4. Try to write relevant attributes in Together
5. Have a plan for class name naming rules
6. Avoid using CSS id selectors
7. Wait

Next let’s learn how to write beautiful SASS code, taking writing a property of the .weather class as an example:
First list @extend(s)

Doing this can enable developers to maintain a clear idea, be able to immediately know the relationship between this class and its attributes and other classes and their attributes, and maintain a clear idea of ​​attribute consistency and attribute reuse.
Normal style

This allows developers to see the deployment of @extend(s) and @include(s) at a glance, making it easier for themselves and other developers to interpret the code. You may also decide whether to distinguish between custom @includes and public source @includes in some cases (especially considering code reusability and timeliness)
Selector nesting

Within the nested section, continue to use the above style rules. Nested parts should always come last.
All vendor prefixes use @mixins

Vendor prefix (CSS prefix) is very time-sensitive. Due to updates to modern browsers, these prefixes will be used less and less. You can adapt to these changes by updating the contents of your mixins (or some libraries used in your mixins will be updated automatically). Even if the mixin is only one line, it doesn't matter.
But when the privatization of some vendor prefixes is very serious, these prefixes will be very difficult to standardize and applying other prefixes or unprefixed versions will not be worth the gain. I will choose to abandon @mixin these vendor prefixes. For example -webkit-line-clamp, -mscontent-zoom-chaining or similar situations.
Do not nest more than 3 levels

If you nest more than three times, you are likely to write a cheating (bad?) selector. The reason for the cheating is that this selector relies too much on the structure of HTML (unstable), is too detailed (the function is too powerful and has no flexibility), or the reusability is too poor (not very usable). At the same time, too many nesting levels can easily lead to code that is obscure and difficult to understand.

Sometimes there is too much code related to a class, so you have to use a tag selector. You may need to be very specific about a class to avoid unnecessary cascading. Even if possible, use extend to take advantage of some of the reusability features in CSS.

Nested code should not exceed 50 lines

If there are more than 50 lines of nesting in SASS, it is likely that it will not be fully displayed on one page of the compiler, which will make the code difficult to read and understand. Nesting is originally intended to facilitate and simplify thinking and code organization. If it violates readability, please do not nest.
Global and regional SASS file sequences are equivalent to table content

In other words, they don’t have any fixed style. Developers should remind themselves to keep the style of all parts consistent and orderly.

First list the vendor/global libraries, then list the custom libraries, then the modes, and finally the libraries used by each division.

In this way, the ‘directory’ looks like the following example, which is clear at a glance:

These files are like a compass, the colors and mixins do not produce compiled CSS code, they are purely standalone libraries. Patterns were introduced after this to make rewriting safer without specificity conflicts.
Reasonably split SASS into multiple small files

There is nothing wrong with doing this. When circumstances permit, try to use multiple files that are small and precise, so that developers can find specific files instead of looking for needles in a haystack in several large files with lengthy code.

...

What I often do is to reference these files one by one in a global scss file, instead of referencing a _header.scss file, and then refer to them one by one in the _header.scss file. Doing so can reduce indexing time and improve reading efficiency.

You may use globbing when there are too many files and the import sequence is too long.
Remember to name Partials _partial.scss

This is a common naming for files that cannot be compiled by themselves. Such a file will depend on other files to some extent, making it impossible to complete the compilation independently. I personally like to add an underscore before the file name, such as _dropdown-menu.scss
Add line mapping

See here, this means that the development tool can tell you the source of every rule, even if it is an imported partial file.
When deploying, remember to compile the streamlined files

A running web page should always use minimal CSS.
No need to submit .css file

It may take some time, but it can be a very nice thing to not have .css files in the repository. The compilation of the files is done at deployment time. So the only thing you can see are those beautifully formatted sass files that have been streamlined. This makes the description of the file very useful. The file description is used to compare some changes made by the version publisher. For already streamlined .css files, file descriptions are basically unnecessary.
Generous usage notes

Rarely do people regret leaving comments in their code. Whether they are useful or inconspicuous comments, they will eventually be erased when compiled into a streamlined CSS file, at no additional cost to the developer.

.overlay {
/* modals are 6000, saving messages are 5500, header is 2000 */
z-index: 5000;
}

Speaking of annotations, you may also need to make some standardization adjustments to them. In SASS, '//' is great for adding comments, and '//' makes commenting and uncommenting very convenient.
　Convert some commonly used values ​​and values ​​with special meanings into variables

If you find yourself reusing a value (which is very common in front-end design), you'd better convert it into a variable. This way you can remind yourself of the meaning of the value by naming it, and maintain consistency when writing code. Yes, you don't need to adjust line by line when changing this value.

If a number has an obvious meaning, then converting it into a variable is essential.

These numbers may be stored in a single file and imported as @imported. This method allows you to perform unified management of all z-index or other variables
and convert colors into variables

Except black and white. Many colors are not meant to be used just once, even if you think you won’t use them again. But if you convert it into a variable, you might find it used elsewhere. For color variables, there are color functions in Sass that can handle them, such as lighten() and darkern(). This gives you easy overall color control (change once, forget it)
Nest and name your media libraries

The function of nesting media libraries in Sass means that 1. you don’t need to rewrite selectors in other places and cause unnecessary errors; 2. the rules you rewrite become clear and clear, and when these This can get very confusing when the code is at the end of your css code or in other files.

There is a more detailed explanation here: http://css-tricks.com/naming-media-queries/
Put Shame at the end

In your global style sheet, introduce a _shame.scss file at the end.

If you need to make some quick changes, you can modify it here. If you have appropriate time and energy in the future, you can better organize and structure the modifications to the overall architecture made in
_shame.scss. For details, please see: http://csswizardry.com/2013/04/shame-css/
You are the leader who decides everything

Sass won’t do anything you don’t tell it to do, so the final output of the sass file is different for everyone. Writing css files with sass is like not using sass, you are the leader of the code.