1. Use two spaces instead of tabs - this is the only way to ensure consistent presentation in all environments.
2. When grouping selectors, put individual selectors on a separate line.
3. For code readability, add a space before the opening brace of each declaration block.
4. The closing brace of a declaration block should be on a separate line.
5. A space should be inserted after : in each declaration statement.
6. For more accurate error reporting, each statement should be on its own line.
7. All declaration statements should end with a semicolon. The semicolon after the last declaration statement is optional, but if you omit it, your code may be more error-prone.
8. For comma-separated attribute values, a space should be inserted after each comma (for example, box-shadow).
9. Do not insert spaces after commas inside rgb(), rgba(), hsl(), hsla(), or rect() values. This helps distinguish multiple color values (only commas, no spaces) from multiple attribute values (commas and spaces).
10. For attribute values or color parameters, omit the leading 0 for decimals less than 1 (for example, .5 instead of 0.5; -.5px instead of -0.5px).
11. Hexadecimal values should be all lowercase, for example, #fff. Lowercase characters are easier to read when scanning a document because their form is easier to distinguish.
12. Try to use abbreviated hexadecimal values, for example, use #fff instead of #ffffff.
13. Add double quotes to the attributes in the selector, for example, input[type="text"]. It is only optional in some cases, but for code consistency it is recommended to use double quotes.
14. Avoid specifying units for 0 values, for example, use margin: 0; instead of margin: 0px;.
/* Bad CSS */
.selector,.selector-secondary,.selector[type=text] {
padding:15px;
margin:0px0px15px;
background-color:rgba(0,0,0,0.5);
box-shadow:0px1px2px#CCC,inset01px0#FFFFFF
}
/* Good CSS */
.selector,
.selector-secondary,
.selector[type="text "] {
padding:15px;
margin-bottom:15px;
background-color: rgba(0,0,0,.5);
box-shadow:01px2px#ccc,inset01px0#fff;
}
Related attribute declarations should be grouped together and in accordance with The following order is arranged:
Positioning
Box model
Typographic
Visual
Due to the positioning (positioning), it can be obtained from the normal document Removes elements from the flow and can also override box model related styles, so it comes first. The box model comes second because it determines the size and placement of components.
Other properties only affect the inside of the component or do not affect the first two groups of properties, so they are ranked behind.
.declaration-order {
/* Positioning */
position:absolute;
top:0;
right: 0;
bottom:0;
left:0;
z-index:100;
/* Box- model */
display:block;
float:right;
width:100px;
height:100px;
/* Typography */
font:normal13px"HelveticaNeue",sans-serif;
line-height:1.5;
color:#333;
text-align:center;
/* Visual */
background-color:#f5f5f5;
border: 1pxsolid#e5e5e5;
border-radius:3px;
/* Misc */
opacity:1;
}
Compared with the tag, the @import command is much slower, not only increasing the number of additional requests, but also causing unpredictable problems. Alternatives include the following:
Use multiple elements
Compile multiple CSS files into one file through a CSS preprocessor like Sass or Less
CSS file merging function provided through Rails, Jekyll or other systems
Place the media query in as close to relevant rules as possible. Don't package them in a single style file or place them at the bottom of the document. If you separate them, they will only be forgotten by everyone in the future. A typical example is given below.
.element { ... }
.element-avatar { ... }
.element-selected { ... }
@media(min-width:480px) {
.element { ...}
.element-avatar { ... }
. element-selected { ... }
}
When using prefixed attributes of a specific vendor, by indentation , so that the value of each attribute is vertically aligned, which facilitates multi-line editing.
In Textmate, use Text → Edit Each Line in Selection(??A). In Sublime Text 2, use Selection →Add Previous Line (??↑) and Selection → Add NextLine (??↓).
/* Prefixed properties */
.selector {
-webkit-box-shadow:01px2px rgba(0,0,0,.15);
box-shadow:01px2px rgba(0,0,0,.15);
}
for only contains A statement style. For legibility and quick editing, it is recommended to put the statements on the same line. For styles with multiple declarations, the declarations should still be divided into multiple lines.
The key factor in doing this is for error detection -- for example, the CSS validator indicates that there is a syntax error on line 183. If it is a single statement on a single line, you will not ignore the error; if it is multiple statements on a single line, you must analyze it carefully to avoid missing the error.
/* Single declarations on oneline */
.span1 {width:60px; }
.span2 {width:140px; }
.span3 {width:220px; }
/* Multiple declarations, oneper line */
.sprite {
display:inline-block;
width:16px;
height:15px;
background-image:url(../img/sprite.png);
}
.icon { background-position:00; }
.icon-home { background-position:0-20px; }
.icon-account { background-position:0- 40px; }
In situations where all values need to be set explicitly, the use of abbreviated property declarations should be limited as much as possible. Common abuses of abbreviated attribute declarations are as follows:
padding
margin
font
background
border
border-radius
In most cases, we don’t need to specify all values for the shorthand property declaration. For example, the HTML heading element only needs to set the top and bottom margin values, so you only need to override these two values when necessary. Excessive use of shorthand property declarations can lead to cluttered code and can cause unintended side effects by causing unnecessary overrides of property values.
/* Bad example */
.element {
margin:0010px;
background:red;
background:url ("image.jpg");
border-radius:3px3px00;
}
/* Good example */
.element {
margin-bottom:10px;
background-color:red;
background-image:url("image.jpg");
border-top-left-radius:3px;
border-top-right-radius:3px;
}
to avoid unnecessary nesting. This is because although you can use nesting, it doesn't mean you should. Use nesting only when styles must be restricted to the parent element (i.e., descendant selectors) and there are multiple elements that need to be nested.
// Without nesting
.table>thead>tr>th {… }
.table>thead>tr>td {… }
// With nesting
.table>thead>tr {
>th { … }
>td { … }
}
Code is written and maintained by people. Make sure your code is self-describing, well-commented, and easy for others to understand. Good code comments convey context and purpose of the code. Don't simply restate component or class names.
For longer comments, be sure to write complete sentences; for general comments, you can write concise phrases.
/* Bad example */
/* Modal header */
.modal-header {
...
}
/* Good example */
/* Wrapping element for.modal-title and .modal-close */
.modal- header {
...
}
Only lowercase characters and dashes (not underscores, nor camel case) can appear in class names. Dashes should be used in naming related classes (similar to namespaces) (e.g., .btn and .btn-danger).
Avoid overly arbitrary abbreviations. .btn represents button, but .s cannot express any meaning.
Class names should be as short as possible and have clear meaning.
Use meaningful names. Use names that are organized or purposeful, not presentational.
Prefix the new class based on the nearest parent class or base class.
Use .js-* classes to identify behaviors (as opposed to styles), and do not include these classes into CSS files.
You can also refer to the specifications listed above when naming Sass and Less variables.
/* Bad example */
.t {... }
.red {... }
.header {... }
/* Good example */
.tweet {... }
.important { ... }
.tweet-header { ... }
Use class for common elements, which will help optimize rendering performance.
Avoid using attribute selectors (e.g., [class^="..."]) for frequently occurring components. Browser performance can be affected by these factors.
The selector should be as short as possible, and try to limit the number of elements that make up the selector. It is recommended not to exceed 3.
Only restrict the class to the nearest parent element (that is, the descendant selector) when necessary (for example, when not using a prefixed class - the prefix is similar to naming space).
/* Bad example */
span {... }
.page-container#stream.stream-item.tweet.tweet-header.username { . .. }
.avatar {... }
/* Good example */
.avatar {... }
.tweet-header.username { ... }
.tweet.avatar { ... }
Organized in units of components code snippet.
Develop consistent annotation conventions.
Use consistent whitespace to separate code into chunks, making it easier to scan larger documents.
If using multiple CSS files, split them into components rather than pages, as pages will be reorganized and components will only be moved.
/*
* Component section heading
*/
.element { ... }
/*
* Component section heading
*
* Sometimes you need to include optionalcontext for the entire component. Do that up here if it's important enough.
*/
.element { ... }
/* Contextual sub-component ormodifer */
.element-heading { ... }
Set your editor according to the following configuration , to avoid common code inconsistencies and differences:
Replace tab characters with two spaces (soft-tab means using spaces to represent tab characters).
Remove trailing whitespace characters when saving the file.
Set file encoding to UTF-8.
Adds a blank line to the end of the file.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
