Detailed explanation of html, CSS and JavaScript front-end naming conventions

I accidentally found such a file in my folder. I can’t remember where it came from. After taking a closer look, I found that the summary is quite good, so I posted it to share it.

Whether it is from a technical perspective or a development perspective, there are certain standards for web front-end development specification documents. This article summarizes a series of web development documents on the development prospects of css3 and html5. Only For reference.

Purpose of specification:

In order to improve the efficiency of team collaboration and facilitate back-end personnel to add functions and front-end post-optimization maintenance, Output high-quality documents, and this document is specially formulated. Once this specification document is confirmed, front-end developers must develop the front-end page according to the specifications of this document. If there is something wrong or inappropriate in this document, please report it in time, and it can be changed after discussion and decision. .

Basic guidelines:

Conform to web standards, semantic HTML, separation of structure, performance and behavior, excellent compatibility . In terms of page performance, the code is required to be concise, clear and orderly, to reduce the server load as much as possible and ensure the fastest parsing speed.

File specification

1. html, css, js, images files are all archived in the directory agreed upon in the ;

2. html files Naming: English name, suffix .htm. At the same time, place the corresponding interface draft in the same directory. If the interface draft is named in Chinese, please rename it with the same name as the html file to facilitate finding the corresponding page when adding functions to the backend;

3. css file naming: English name, suffix .css. Common base.css, homepage index.css, other pages are named according to actual module requirements.;

4. Js file naming: English naming, suffix.js. Common.js is shared, and other names are based on actual module requirements.

html writing standards

1. Document type declaration and encoding: unified to html5 declaration type ; unified encoding to , used when writing IDE implements clear-level indentation;

2. Except in special circumstances, the style file must be externally linked to …; Except in special circumstances, JavaScript The file must be linked to the bottom of the page;

3. When introducing style files or JavaScript files, the default type declaration must be omitted and written as follows:

<link rel=”stylesheet” href=”…” /> 
<style>…</style> 
<script src=”…”></script>

#4. Introduce the JS library file. The file name must include the library name and version number and whether it is a compressed version, such as jquery-1.4.1.min.js ; Introduce the plug-in, the file name format is library name + plug-in name, such as jQuery.cookie.js;

5. All coding follows the xhtml standard, tags & attributes & attribute naming must be It consists of lowercase letters and underlined numbers, and all tags must be closed, including br (
), hr (

---

), etc.; attribute values ​​must be enclosed in double quotes;

6. Make full use of HTML tags that have no compatibility issues, such as span, em, strong, optgroup, label, etc.; when you need to add custom attributes to HTML elements, you must first consider whether there is a default There are existing appropriate tags to set. If not, you can use "data-" as the prefix to add custom attributes to avoid using "data:" and other naming methods;

7. Semantic HTML, such as using h* for titles (the same page can only have one h1), p for paragraph tags, and ul for lists. Block-level elements cannot be nested in inline elements;

8. Reduce p nesting as much as possible, such as

Welcome to XXX, your user name is

Username

can be completely replaced by the following code:

Welcome to XXX, your The username isusername

;

9. When writing link addresses, redirects must be avoided, for example :href="http://itaolun.com/", that is, "/" must be added after the URL address;

10. 在页面中尽量避免使用style属性,即style=”…”;

11. 必须为含有描述性表单元素(input, textarea)添加label, 如

<p>姓名: <input type=”text” id=”name” name=”name” /></p>须写成:<p><label for=”name”>姓名: </label><input type=”text” id=”name” /></p>

12. 能以背景形式呈现的图片, 尽量写入css样式中;

13. 重要图片必须加上alt属性; 给重要的元素和截断的元素加上title;

14. 给区块代码及重要功能(比如循环)加上注释, 方便后台添加功能;

15. 特殊符号使用: 尽可能使用代码替代: 比如 <(<) & >(>) & 空格( ) & ?(?) 等等;

16. 书写页面过程中, 请考虑向后扩展性;

17. class & id 参见 css书写规范.

css书写规范

1. 编码统一为utf-8;

2. 协作开发及分工: i会根据各个模块, 同时根据页面相似程序, 事先写好大体框架文件, 分配给前端人员实现内部结构&表现&行为; 共用css文件base.css由i书写, 协作开发过程中, 每个页面请务必都要引入, 此文件包含reset及头部底部样式, 此文件不可随意修改;

3. class与id的使用: id是唯一的并是父级的, class是可以重复的并是子级的, 所以id仅使用在大的模块上, class可用在重复使用率高及子级中; id原则上都是由我分发框架文件时命名的, 为JavaScript预留钩子的除外;

4. 为JavaScript预留钩子的命名, 请以 js_ 起始, 比如: js_hide, js_show;

5. class与id命名: 大的框架命名比如header/footer/wrapper/left/right之类的在2中由i统一命名.其他样式名称由 小写英文 & 数字 & _ 来组合命名, 如i_comment, fontred, width200; 避免使用中文拼音, 尽量使用简易的单词组合; 总之, 命名要语义化, 简明化.

6. 规避class与id命名(此条重要, 若有不明白请及时与i沟通):

a, 通过从属写法规避, 示例见d;

b, 取父级元素id/class命名部分命名, 示例见d;

c, 重复使用率高的命名, 请以自己代号加下划线起始, 比如i_clear;

d, a,b两条, 适用于在2中已建好框架的页面, 如, 要在2中已建好框架的页面代码

中加入新的p元素,

按a命名法则:

…

,

样式写法: #mainnav .firstnav{…….}

按b命名法则:

…

,

样式写法: .main_firstnav{…….}

7. css属性书写顺序, 建议遵循 布局定位属性–>自身属性–>文本属性–>其他属性. 此条可根据自身习惯书写, 但尽量保证同类属性写在一起. 属性列举: 布局定位属性主要包括: margin ＆ padding ＆ float（包括clear） ＆ position（相应的 top,right,bottom,left） ＆ display ＆ visibility ＆ overflow等； 自身属性主要包括: width & height & background & border; 文本属性主要包括： font ＆ color ＆ text-align ＆ text-decoration ＆ text-indent等；其他属性包括: list-style(列表样式) ＆ vertical-vlign ＆ cursor ＆ z-index(层叠顺序) ＆ zoom等. 我所列出的这些属性只是最常用到的, 并不代表全部;

8. 书写代码前, 考虑并提高样式重复使用率;

9. 充分利用html自身属性及样式继承原理减少代码量, 比如:

• 这儿是标题列表2010-09-15

定义

ul.list li{position:relative} ul.list li span{position:absolute; right:0}

即可实现日期居右显示

10. 样式表中中文字体名, 请务必转码成unicode码, 以避免编码错误时乱码;

11. 背景图片请尽可能使用sprite技术, 减小http请求, 考虑到多人协作开发, sprite按模块制作;

12. 使用table标签时(尽量避免使用table标签), 请不要用width/ height/cellspacing/cellpadding等table属性直接定义表现, 应尽可能的利用table自身私有属性分离结构与表现, 如

thead,tr,th,td,tbody,tfoot,colgroup,scope; (cellspaing及cellpadding的css控制方法: 
table{border:0;margin:0;border-collapse:collapse;} table th, table td{padding:0;} ,

base.css文件中我会初始化表格样式)

13. 杜绝使用 兼容ie8;

14. 用png图片做图片时, 要求图片格式为png-8格式,若png-8实在影响图片质量或其中有半透明效果, 请为ie6单独定义背景:

_background:none;_filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(sizingMethod=crop, src=’img/bg.png’);

15. 避免兼容性属性的使用, 比如text-shadow || css3的相关属性;

16. 减少使用影响性能的属性, 比如position:absolute || float ;

17. 必须为大区块样式添加注释, 小区块适量注释;

18. 代码缩进与格式: 建议单行书写, 可根据自身习惯, 后期优化i会统一处理;

JavaScript书写规范

1. 文件编码统一为utf-8, 书写过程过, 每行代码结束必须有分号; 原则上所有功能均根据XXX项目需求原生开发, 以避免网上down下来的代码造成的代码污染(沉冗代码 || 与现有代码冲突 || …);

2. 库引入: 原则上仅引入jQuery库, 若需引入第三方库, 须与团队其他人员讨论决定;

3. 变量命名: 驼峰式命名. 原生JavaScript变量要求是纯英文字母, 首字母须小写, 如iTaoLun;

jQuery变量要求首字符为’_’, 其他与原生JavaScript 规则相同, 如: _iTaoLun;

另, 要求变量集中声明, 避免全局变量.

4. 类命名: 首字母大写, 驼峰式命名. 如 ITaoLun;

5. 函数命名: 首字母小写驼峰式命名. 如iTaoLun();

6. 命名语义化, 尽可能利用英文单词或其缩写;

7. 尽量避免使用存在兼容性及消耗资源的方法或属性, 比如eval() & innerText;

8. 后期优化中, JavaScript非注释类中文字符须转换成unicode编码使用, 以避免编码错误时乱码显示;

9. 代码结构明了, 加适量注释. 提高函数重用率;

10. 注重与html分离, 减小reflow, 注重性能.

 

图片规范

1. 所有页面元素类图片均放入img文件夹, 测试用图片放于img/demoimg文件夹;

2. 图片格式仅限于gif || png || jpg;

3. All names should use a combination of lowercase English letters || numbers || _, which must not contain Chinese characters || spaces || special characters; try to use easy-to-understand vocabulary to facilitate understanding by other team members; in addition, The name is divided into two parts, the first and last parts, separated by underscores, such as ad_left01.gif || btn_submit.gif;

4. Select the smallest image format and image quality while ensuring the visual effect. , to reduce loading time;

5. Try to avoid using translucent png images (if used, please refer to the relevant instructions of the css specification);

6. Use css sprite technology to focus on small background images or icons to reduce page http requests, but please be sure to draw reference lines in the corresponding sprite psd source image and save it to the img directory.

Comment specification

1. html comment: Comment format, ‘–’ can only be used at the beginning and end of the comment, and cannot be placed in the comment text area;

2. css comment: Comment format/*Comment here */;

3. JavaScript comments, single-line comments use '//This is a single-line comment', multi-line comments use /* This is a multi-line comment*/;

Development and testing tool convention

It is recommended to use Aptana || Dw | | Vim, you can also choose according to your own preferences, but you must follow the following principles:

1. Do not use the IDE's view mode to 'draw' code;

2. You cannot use IDE to generate related function codes, such as some functional js built into Dw;

3. The coding must be formatted, such as indentation;

Testing tools: only test FireFox & IE6 & IE7 & IE8 in the early stage of development, and add Opera & Chrome & Safari during later optimization;

Recommended test order: FireFox–> ;IE7–>IE8–>IE6–>Opera–>Chrome–>Safari, it is recommended to install firebug and IE Tab Plus plug-ins.

Other specifications

1. During the development process, complete the page strictly according to the division of labor to improve the css reuse rate and avoid repeated development;

2. Reduce redundant code, Write code that everyone can understand. Being concise and easy to understand is a virtue. Think about the users and the server.

The above is the detailed content of Detailed explanation of html, CSS and JavaScript front-end naming conventions. For more information, please follow other related articles on the PHP Chinese website!