Web front-end Development specification documentation

Specification description

This is the code writing specification that the front-end development team follows and conventions, and is intended to improve the normative and maintainability of the code.

Basic guidelines

Conform to Web standards, semantic HTML, structural performance behavior separation, good compatibility. Page performance, code requirements concise and clear order, as far as possible to reduce the server load, to ensure the fastest resolution speed.

General specification

1. Ignore (OMIT) agreement: such as Background:url (Http://www.google.com/images/example); Background:url (//www.google.com/images/example) should be written to facilitate HTTP-to-HTTPS protocol switching unless a protocol must be used

2. Use the IDE to achieve a structured indentation when writing. The TAB key is replaced with four spaces.

Because the editing tools in different systems do not have the same tab resolution, the TAB key under Windows is four spaces, and under Linux it becomes a eight space (unless you set the TAB key position length yourself).

such as sublime text, the TAB key can be set in this tool.

3. Label properties using lowercase

4. Do not leave a blank space at the end to prevent diff

5. Using UTF-8 (no BOM), <meta charset= "is also included in the document" Utf-8″>

6. File naming uniform use lowercase ". js", while recommending "-" instead of "_"

7.TODO (Contact) and todo:action item, do not use @@

HTML Refinement Specification

1. Use the HTML5 specification <! DOCTYPE html>

2. label default default format: Avoid src= "" issue

3.<a> label default format: <a href= "# # #" title= "link name" >xxx</> Note: target= "_blank" depends on demand

4.<a> tag reserved link placeholder using # # #, see: A tag placeholder problem

5. When writing the link address, you must avoid redirection, for example: href= "http://itaolun.com/", that is, to add "/" after the URL address

6. All labels are subject to XHTML standard closure

7. Uniform label end slash writing form: <br/>

8. Avoid using outdated labels such as:<b> <u> <i> instead of <strong> <em>

9. Use data-xxx to add custom data, such as: <input data-xxx= "yyy"/>

10. Avoid using style= "XXX:XXX;" The inline style sheet

Special symbols using reference HTML symbol entities

11. You must add a label to the containing descriptive form element (input, textarea), such as <p> name: <input type= "text" id= "name" name= "name"/></p> must be written : <p><label for= "Name" > Name: </label><input type= "text" id= "name"/></p>

CSS Refinement Specification

1. Add ";" after each style attribute

Convenient compression Tool "segmentation".

2. Class is named with a "-" [minus connector] to separate the letters in class:

• Separating with "-" is clearer than using a hump.

• Product line-product-module-sub-module, the name of the time can also be used in this way

ID: Small Hump-like naming method:

FirstName topboxlist Footercopyright

3. Use of spaces, the following rules are enforced:

. hotel-content {

Font-weight:bold;

}

• Selector and {preceded by a space

• Property name: After a space

• Property name: Front (forbidden) plus space

One reason is beautiful, followed by IE 6 there is a bug, Poke bug

4. (recommended) The writing order of attributes, for example:

. hotel-content {/     * location */     Display:block;     Position:absolute;     left:0;     top:0;     /* Box model */     width:50px;     height:50px;     margin:10px;     border:1px solid black;     /* Other */     color: #efefef;}

• Location-related, common are: Display position left top float, etc.

• box model related, common are: width height margin padding border, etc.

• Other properties

Write in this order to see how the browser renders the DOM performance

For example, the picture in the Web page, if not set width and height, before the picture loaded, he occupied a space of 0, but when he finished loading, the block of 0 of space suddenly was open, which will lead to his following elements rearranged and rendered, Cause repainting (repaint) and Reflow (reflow). When we write CSS, we put the positioning of the elements in front of the first, let the browser know whether the element is within the text flow or outside, specific in the page, and then let the browser know their width and height, border and so on these occupy space properties, the other properties are in this fixed area of the rendering, That's pretty much what it means.

Recommended article: Poll results:how do you order your CSS properties?

Http://www.mozilla.org/css/base/content.css

5. (recommended) When writing a style for a specific HTML structure, use the element name + class name

/* All NAV is written for ul */ul.nav {     ...}

". A div" and ". A div.b", why is the latter good? If the demand has changed, under ". A" has added a Div, ask, the beginning of the style will affect the later Div AH ~

6. (not recommended) IE uses filter, (forbidden) to use expression

Here is mainly the efficiency of the problem, should be careful, to use less burning CPU things ~

7. CSS comments with "/* * * * * * * * *", when a single-line comment, the annotated object and the front and back of the comment on each left a space, and a separate row, and a multiline comment, the start and end of the comment line. For example:

/* Comment css *//* table {    border-collapse:collapse;} */

JS Refinement Specification

1. Line break

• Each line of code should be less than 120 characters, more than this number, you can consider line-wrapping, "." or "+" operators should be placed at the end of a line, and the code after wrapping must be indented more than one layer before wrapping.

• If the arguments in the function or method are longer, make the appropriate partitioning.

• Prevents line breaks between the return keyword and the expression to be returned. For example:

// The actual return is undefined, not 1 . function Test () {    return        1;}

2. Line of code

• It is forbidden to write multiple phrase sentences in one line, that is, a single statement is written on a line.

• Statements such as if, for, do, while, switch, case, default, break, continue, and so on, occupy a single row.

• The "{}" is required to enclose all the loop bodies and the judgment body's execution statements in the IF, for, does, while, and so on, prohibiting the ellipsis of curly braces. For example:

  // of the wrong if (I < 5) i + =1//  correct if (i < 5) {    + = 1}

3. Align

• The code block's delimiter {}, "{" follows the previous line, and there is a space separated by the front, "}" should have a single row and be in the same column, and align to the left of the statement referencing them.

• The beginning of the function body, the definition of the class, and the procedures in the If, for, do, while, switch, case statements are indented as above.

4. Spaces

• You must have a space after the keyword to highlight the keyword.

• The function name, method name, and opening parenthesis "(" cannot hold spaces between them, for example:

// of the wrong function GetInfo () {    //  code//  correct function  GetInfo () {    //  code

• When declaring a function expression, there is no space between function and the opening parenthesis "(", for example:

  // of the wrong var function () {    //  code//  correct varfunction () {    //  code}

• Add a space after the comma.

• Assignment operators, comparison operators, arithmetic operators, logical operators, bit field operators, such as "=", "+ =" ">=", "<=", "+", "*", "%", "&&", "| |" Wait for the two-dollar operator before and after the space should be added.

• "!", "~", "+ +", "--", "&" (address operator) are not preceded by a space before or after the monocular operator.

• ".", "[]" before and after no spaces.

5. Blank Line

• After each class declaration, a blank line is added after the end of each function definition.

• In a function body, there is no blank line between the closely related statements on the IBO, and the other places should be separated by a blank line.

6. Use strict conditional judgments. Use = = = instead of = =, replace! = with!==

7. Avoid the extra comma. such as: var arr = [All in all,]

8. Statements must all have a semicolon ending, except For,function,if,switch,try,while.

9. The left curly brace is placed at the end of the line and the right curly brace is placed at the beginning.

10. The following types of objects are not recommended for new constructs: New Number,new string,new Boolean,new object (in lieu of {}), and the new Array (replaced with []).

11. A space is required after the "," between the members of the array.

12. Prohibit the use of JavaScript in Js/json to keep key words named, in IE easy to cause errors. Keywords (break, case, catch, continue, default, delete, do, else, finally, for, function, if, in, instanceof, new, return, switch, This, throw, try, typeof, Var, void, if, with), keywords (abstract, Boolean, Byte, Char, class, const, debugger, double, enum, Export, extends, fimal, float, Goto, implements, import, int, interface, long, mative, package, private, protected, public, Short, static, super, synchronized, throws, transient, volatile).

13. It is recommended that you use "+" as a newline connector instead of "\".

14. The information is forbidden to use generalized general language description, should be concise and clear, see the information can immediately locate the error, such as prompting the user information error with "The user does not exist", instead of "back to the background data error", "Network timeout."