Guide to writing flexible, stable, high-quality HTML and CSS code specifications_HTML/Xhtml

Golden Rule
Always follow the same set of coding standards. No matter how many people work on the same project, make sure every line of code looks like it was written by the same person.

1. Grammar:
1. Use two spaces to replace the tab character (tab);
2. Nested elements should be indented once (two spaces);
3. For the definition of attributes, make sure to use double quotes, never single quotes;
4. Do not add a slash at the end of a self-closing element--HTML5 specification (https://dev. w3.org/html5/spec-author-view/syntax.html#syntax-start-tag) clearly states that this is optional;
5. Do not omit the optional closing tag;
6. Add a standard mode declaration to the first line of each HTML page to ensure that one is displayed in each browser;

2. Language attribute:
According to the HTML5 specification, it is recommended to specify the lang attribute for the HTML root element to set the correct language for the text. This will help the speech synthesis tool determine which language it should use The pronunciation of , helps translation tools determine the rules that should be followed during translation, etc. lang attribute list: http://www.sitepoint.com/web-foundations/iso-2-letter-language-codes/

3. IE compatibility mode:
IE supports using specific tags to determine the IE version that the current page of the receipt should use. Unless there is a strong requirement, it is best to set it to edge mode. Thus ruling IE to adopt the latest mode it supports.

4. Character encoding:
By declaring the character encoding, it can ensure that the browser can quickly and easily determine the rendering method of the page content. This can avoid using character entity tags in HTML, thus All are consistent with the document encoding.

5. Import css and JavaScript files:
According to the HTML5 specification, there is generally no need to specify the type attribute when introducing css and JavaScript files, because text/css and text/javascript are their respective Default value.

6. Practicality is king:
Try to follow HTML standards and semantics, but do not sacrifice practicality. Try to use the fewest tags and maintain the minimum complexity at all times.

7. Attribute order:
HTML attributes should be arranged in the following order to ensure the readability of the code:
1.class
2.id,name　
3.data-*　
4.src,for,type,href　　
5.title,alt　　
6.Aria,role　
class is used to mark highly reusable components, so it should be arranged In the first place.

8. Reduce the number of tags
When writing HTML code, try to avoid redundant parent elements. Many times, this requires iteration and refactoring to achieve.

9. Tags generated by JavaScript
Tags generated by JavaScript make it difficult to find and edit content, and affect performance. Avoid it as much as possible.

10. CSS syntax:
1. Use two spaces to replace the tab character (tab);
2. When grouping selectors, place individual selectors separately. On one line;
3. For code readability, add a space between the left curly brace of each declaration block;
4. The right curly brace of the declaration block should be on a separate line;
5. Each Declaration statements: A space should be inserted after them;
6. In order to obtain more accurate error reporting, each statement should be on its own line;
7. All declaration statements should end with a semicolon, and the last statement The semicolon after the statement is optional, but if you omit this semicolon, the code may be easier to write;
8. For comma-separated attribute values, a space should be inserted after each comma;
9 .For attribute values or color parameters, omit the 0 in front of decimals less than 1 (for example, .5 instead of 0.5);
10. Hexadecimal values should be all lowercase, for example: #fff, try to use the abbreviated hexadecimal form Base value, for example, use #fff instead of #ffffff;
11. Add double quotes to the selected attributes, such as input[type="text"];
12. Avoid specifying units for 0 values, for example, use margin:0 instead of margin:0px.

11. Declaration order:

Related property declarations should be grouped together and arranged in the following order:

1.positioning(position: absolute; top: 0; bottom: 0; right: 0; left: 0; z-index: 100;);
2.box model(display: block; float: left ; width: 100px; height: 100px;);
3.typographic(font: normal 13px "Microsoft YaHei"; line-height: 1.5em; color: #333; text-align:center;);
4.visual(background: yellow; border: 1px solid #c00; border-radius: 3px; opacity: 1; );
　
Elements can be removed from the normal document flow due to positioning, and It can also cover the styles related to the box model, so it is ranked first. The box model is ranked second, because it determines the size and position of the component. Other attribute knowledge affects the inside of the component or does not affect it. The first two sets of attributes are therefore ranked behind.

12. Do not use @import　
Compared with tags, the @import command is much slower. It not only increases the number of additional requests, but also causes unpredictable problems. Alternative methods are Here are a few:
1. Use multiple elements;
2. Convert multiple css files into one file through a css preprocessor similar to sass or less;
3. Through rails, jekyll or other The system provides css file merging function.

13. Position of media query
Place media queries as close to relevant rules as possible. Do not package them in a single style file or place them in the document Bottom.

14. Prefixed attributes:
When using prefixed attributes of a specific manufacturer, it is convenient to lock the values of each attribute in the vertical direction. Multi-line editing. For example:

CSS CodeCopy content to clipboard

.selector { 　　　
- webkit-box-shadow: 0 1px 2px rgba(0,0,0,.15 ); 　　　　
　　　　　　box-shadow: 0 1px 2px rgba(0,0,0,.15); 🎜>
}

15. Single-line rule declaration:
For styles whose value contains one declaration, for the sake of readability and quick editing, it is recommended to put the statement on the same line. For styles with multiple declarations style, the declaration should still be divided into multiple lines. The key factor in doing this is for error detection. For example, there is a syntax error in the css validator on line 180. If it is a single line and a single declaration, you will not ignore this error. If there are multiple statements on a single line, you need to analyze them carefully to avoid missing errors.

16. Nesting in Less and Sass Avoid unnecessary nesting. This is because although you can use nesting, it does not mean that you should use nesting. Only Nesting can only be used when the style must be limited to the parent element (that is, the descendant selector), and there are multiple elements that need to be nested.

17. Comments: 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 can convey context and code purpose;
Do not simply restate component or class names;
For longer comments, be sure to write complete sentences, and for general comments, you can write introductory phrases.

18. Class naming Only small characters and dashes can appear in class names (not underline or camel case). Dashes should be used for naming related classes (similar to namespaces , such as .btn and .btn-danger)
Avoid excessively 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 organized or purposeful names, do not use expressive names;
Prefix new classes based on the most recent class or basic 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.

19. Selectors Use class for common elements, which will help optimize rendering performance;
For frequently occurring components, avoid using attribute selectors (for example: [class^ ="···"]), browser performance will be affected by these factors;
Make the selector 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 Only limit classes to the nearest parent element when necessary.

20. Code organization: Organize code segments in units of components;
Specify consistent comment specifications;
Use consistent whitespace to separate code into blocks, so Favorable for scanning larger documents;
If multiple css files are used, split them into components rather than pages, because pages will be reorganized and components will only be moved.

The above is the entire content of this article. I hope it will be helpful to everyone in writing standardized, flexible, stable, and high-quality HTML and CSS codes.

Original text:

http://www.cnblogs.com/codinganytime/p/5258223.html

Guide to writing flexible, stable, high-quality HTML and CSS code specifications_HTML/Xhtml_Web page production