A guide to writing flexible, stable, high-quality HTML and CSS code standards

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

1. Grammar:
1. Use two spaces instead of tabs;
2. Nested elements should be indented once (two spaces);
3. For the definition of attributes, make sure to use double quotes and never use single quotes;
4. Don’t add a slash to the end of self-closing elements—the 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 end tag;
6. Add a standard mode declaration to the first line of each HTML page to ensure that it is displayed in each browser;

2. Language attributes:
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 speech synthesis tools determine the pronunciation it should use, help translation tools determine the rules to follow when translating, and so on. List of lang attributes: http://www.sitepoint.com/web-foundations/iso-2-letter-language-codes/

3. IE compatibility mode:
IE supports specific tags to determine the IE version that should be used to display the current page. Unless there is a strong requirement, it is best to set it to edge mode to force IE to use the latest mode it supports.

4. Character encoding:
By declaring the character encoding, you can ensure that the browser can quickly and easily determine how to render the page content. Doing so avoids using character entity tags in HTML, so that everything is consistent with the document encoding.

5. Import css and JavaScript files:
According to the HTML5 specification, you generally do not need to specify the type attribute when importing CSS and JavaScript files, because text/css and text/javascript are their default values ​​respectively.

6. Practicality is king:
Try to follow HTML standards and semantics, but don't sacrifice usability. Always use the fewest tags and keep complexity to a minimum.

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 ranked first.

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

9. Tags generated by JavaScript <br /> Tags generated by JavaScript make content difficult to find and edit, and affect performance. Try to avoid them if possible.

10. CSS syntax:
1. Use two spaces instead of tabs;
2. When grouping selectors, place each selector on its own line;
3. For code readability, add a space before the left curly brace of each declaration block;
4. The closing curly brace of the declaration block should be on a separate line;
5. A space should be inserted after each declaration statement:
6. To get more accurate error reports, 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 it is omitted, the code may be easier to print;
8. For attribute values ​​separated by commas, a space should be inserted after each comma;
9. For attribute values ​​or color parameters, omit the leading zero for decimals less than 1 (e.g. .5 instead of 0.5);
10. Hexadecimal values ​​should be all lowercase, for example: #fff. Try to use abbreviated hexadecimal values, for example, use #fff instead of #ffffff.
11. Add double quotes to the selected attributes, for example, input[type="text"];
12. Avoid specifying units for zero 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; );

Positioning comes first because it removes elements from the normal document flow and can override styles related to the box model. The box model comes second because it determines the size and position of components. Other properties only affect the inside of components or do not affect the first two groups of properties, so they come later.

12. Don’t use @import
Compared to tags, the @import directive is much slower, not only adding extra requests, but also causing unexpected problems. There are several alternatives:
1. Use multiple elements;
2. Use sass or less-like CSS preprocessors to convert multiple CSS files into one file;
3. Provide CSS file merging function through rails, jekyll or other systems.

13. Media query location
Place media queries as close to related rules as possible. Don’t bundle them into a single style sheet or put them at the bottom of the document.

14. Attributes with prefixes:
When using vendor-specific prefixed attributes, lock the values ​​of each attribute to align vertically, which facilitates multi-line editing. For example:

15. Statement of Single Rules:
For styles that contain a single declaration, it is recommended to put the statement on the same line for readability and quick editing. For styles with multiple declarations, you should still split the declarations into multiple lines. The key factor in doing this is error detection. For example, the CSS validator has a syntax error on line 180. If it is a single line and a single declaration, you will not ignore this error. If it is a single line and multiple declarations, you will have to analyze it carefully to avoid missing the error.

16. Nesting in Less and Sass <br /> Avoid unnecessary nesting. This is because although you can use nesting, it does not mean that you should use nesting. 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. Notes:
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;
Do not simply reiterate component or class names;
For longer comments, be sure to write complete sentences, and for general comments, you can write concise phrases.

18. Class naming
Only commas and dashes may appear in class names (not underscores or camelCase). Dashes should be used in names of related classes (similar to namespaces, such as .btn and .btn-danger).
Avoid overly arbitrary abbreviations. .btn stands for button, but .s doesn’t mean anything;
Class names should be as short as possible and have clear meanings;
Use meaningful names, use organizational or purposeful names, not expressive names;
Use the nearest class or base class as a prefix for the new class;
Use .js-* classes to identify behavior (as opposed to style), and don’t include these classes in your CSS files;
You can also refer to the above specifications when naming Sass and Less variables.

19. Selector <br />Use class for common elements, which is conducive to optimizing rendering performance;
Avoid using attribute selectors (e.g. [class^="···"]) for frequently appearing components, as browser performance will be affected by these factors;
The selector should be as short as possible, and the number of elements that make up the selector should be limited to no more than 3.
Limit a class to its immediate parent element only when necessary.

20. Code organization:
Organize code segments by component;
Specify consistent annotation conventions;
Use consistent whitespace to separate code into blocks, which makes it easier to scan larger documents;
If you use multiple CSS files, split them up by components instead of 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 help you write standardized, flexible, stable, and high-quality HTML and CSS codes.

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