Mozilla recommended CSS attribute writing order and naming rules_html/css_WEB-ITnose

传说中的Mozilla推荐 

Java代码  

1. /* mozilla.org Base Styles 
2.  * maintained by fantasai 
3.  */  
4. /* Suggested order: 
5.  * display 
6.  * list-style 
7.  * position 
8.  * float 
9.  * clear 
10.  * width 
11.  * height 
12.  * margin 
13.  * padding 
14.  * border 
15.  * background 
16.  * color 
17.  * font 
18.  * text-decoration 
19.  * text-align 
20.  * vertical-align 
21.  * white-space 
22.  * other text 
23.  * content 
24.  * 
25.  */  
26. ...  

来源：

Java代码  

1. http://www.mozilla.org/css/base/content.css  

在怿飞’s Blog的这篇文章里，又将上面的属性分成了三组：显示属性、自身属性和文本属性。在回复里，inG补充这还和浏览器的解析过程有关：浏览器先对DOM定位，然后解析自身属性，接着再解析内部对象。（没找到相关的英文资料，有知情者还望告知） 

在Mozilla官方，其实并没有推荐任何CSS书写顺序。很可能是某个开发者在阅读fantasai的这篇文章 mozilla.org Markup Reference 时，顺便对fantasai的CSS源文件产生了兴趣，因此才有了上面的发现。 
字母排序 

NETTUTS上时不时有些好文章，这不，前不久，Trevor Davis就分享了一篇：5 Ways to Instantly Write Better CSS. 这篇文章中，推荐CSS的属性按字母排序。 

优点是：简单，任何人只要遵守，一看就明白。 

缺点是：太简单，缺乏逻辑性。比如position, left, top等，这种紧关联的属性，如果都按字母排序，书写和维护起来都不方便。Andy Ford推荐的排序 

Andy Ford是HTML和CSS方面的专家，最近写了一篇文章：Order of the Day: CSS Properties. 文章推荐的CSS书写顺序为： 

Java代码  

1.  1. Display & Flow  
2.  2. Positioning  
3.  3. Dimensions  
4.  4. Margins, Padding, Borders, Outline  
5.  5. Typographic Styles  
6.  6. Backgrounds  
7.  7. Opacity, Cursors, Generated Content  
8.   
9. 例子：  
10.   
11. el {  
12.     display: ;  
13.     visibility: ;  
14.     float: ;  
15.     clear: ;  
16.   
17.     position: ;  
18.     top: ;  
19.     right: ;  
20.     bottom: ;  
21.     left: ;  
22.     z-index: ;  
23.   
24.     width: ;  
25.     min-width: ;  
26.     max-width: ;  
27.     height: ;  
28.     min-height: ;  
29.     max-height: ;  
30.     overflow: ;  
31.   
32.     margin: ;  
33.     margin-top: ;  
34.     margin-right: ;  
35.     margin-bottom: ;  
36.     margin-left: ;  
37.   
38.     padding: ;  
39.     padding-top: ;  
40.     padding-right: ;  
41.     padding-bottom: ;  
42.     padding-left: ;  
43.   
44.     border: ;  
45.     border-top: ;  
46.     border-right: ;  
47.     border-bottom: ;  
48.     border-left: ;  
49.   
50.     border-width: ;  
51.     border-top-width: ;  
52.     border-right-width: ;  
53.     border-bottom-width: ;  
54.     border-left-width: ;  
55.   
56.     border-style: ;  
57.     border-top-style: ;  
58.     border-right-style: ;  
59.     border-bottom-style: ;  
60.     border-left-style: ;  
61.   
62.     border-color: ;  
63.     border-top-color: ;  
64.     border-right-color: ;  
65.     border-bottom-color: ;  
66.     border-left-color: ;  
67.   
68.     outline: ;  
69.     list-style: ;  
70.   
71.     table-layout: ;  
72.     caption-side: ;  
73.     border-collapse: ;  
74.     border-spacing: ;  
75.     empty-cells: ;  
76.   
77.     font: ;  
78.     font-family: ;  
79.     font-size: ;  
80.     line-height: ;  
81.     font-weight: ;  
82.     text-align: ;  
83.     text-indent: ;  
84.     text-transform: ;  
85.     text-decoration: ;  
86.     letter-spacing: ;  
87.     word-spacing: ;  
88.     white-space: ;  
89.     vertical-align: ;  
90.     color: ;  
91.   
92.     background: ;  
93.     ;  
94.     background-image: ;  
95.     background-repeat: ;  
96.     background-position: ;  
97.   
98.     opacity: ;  
99.     cursor: ;  
100.     content: ;  
101.     quotes: ;  
102.     }  

Andy’s order is generally consistent with the order recommended by fantasai, but the details are more operable.
There is also a very lively discussion thread on SitePoint: How do you order your properties within a declaration block?

I like the writing order of fantasai and Andy, but in fantasai's order, the "self" attribute It's a little vague, and Andy's is too detailed to remember. I think we can learn from the classification of CSS properties in the CSS 2.1 Specification and slightly adjust Andy’s order:

1. Properties that affect document flow (such as: display, position, float, clear, visibility, table- layout, etc.)
2. Properties of its own box model (such as: width, height, margin, padding, border, etc.)
3. Typesetting-related properties (such as: font, line-height, text-align, text- indent, vertical-align, etc.)
4. Decorative attributes (such as: color, background, opacity, cursor, etc.)
5. Content-generated attributes (such as: content, list-style, quotes, etc.)

Things are never that simple, such as the following problems:

1. How to deal with shorthand? For example, border: 1px solid red; where border-width is related to the box model, but border-color is decorative. How to organize it?
2. Considering the skin-changing function, should color, background, border-color and other color-related items be put together? to facilitate future modifications.
3. How to deal with hacks? Is it better to put it alone at the end of the css file, or next to the hack attributes?
4. When maintaining a colleague’s CSS file, how should I comment on the newly added or modified attributes? How to write?
5. Also, considering CSS Sprite, all background image selectors are placed together? But that’s beyond the scope of this article: the order and organization of properties within CSS selectors.
6. Further discussion is: the structural organization within CSS files, and the organization of multiple CSS files.


CSS naming rules:

Like other programs, CSS has the concept of scope, with global and class-local effects.

For example:

p{background:#f00;}/* Scope: global*/

.div p{color:#000;}/* Scope: In div class */

Introducing several writing methods and weight comparison of Css

1) Tag: weight value is 0,0,0,1

2) Class: The weight is 0,0,1,0

3) Attribute selection: The weight is 0,0,1,1

4) ID: The weight is 0, 1,0,0

5) The weight of important is the highest 1,0,0,0

I believe that when you are writing Css, when the project is larger and the content is more , naming is a headache, and a block needs to express the styles of different states. Mastering the naming rules is a powerful tool, which can make your work more effective. It is roughly as follows: (Reprinted from: http://www.cssforest.org/blog /index.php?id=143, you can go here to read more technical articles)

To avoid when the status changes When the name loses its meaning, the most common ones are the class names used for layout, such as "left" and "right". When the left column is no longer the left column, the name "left" has no practical meaning. This goes against our recommendation of "naming should be meaningful", and using serial numbers is even more problematic. It seems to be true, but there has been a problem that has bothered me for a long time. If the same module appears more than once on a page, and the details are different, what should the name of the subsequent ones be called? Aren't "one" and "two" serial numbers? In fact, the situation we want to avoid is that when the state (performance) changes, the corresponding defined class name will not lose its meaning.

There are several situations where the so-called status (performance) changes:

1. The HTML remains unchanged and the style definition changes. If the name uses a name that represents a certain state, such as "red", "font14", etc., it will definitely cause inconsistency between the definition and the naming, which will have a relatively large impact on subsequent consequences.
2. The style definition remains unchanged, but the HTML changes. HTML changes mean that the class name can be replaced, that is, if the class name uses a name that represents a certain state, it will be more conducive to modification.
3. Both style definition and HTML have changed. Just consider not to have the consequences of the first scenario.

But the actual situation is not just one kind of situation, but more often it appears in a mixture.
Rules

[Module Prefix] _ Type_ (Function | Status) n _ [Position n]

Legend description:

* (Required): Required exist.
* [Optional]: You can choose according to your needs.
* |: Select one from more than one.
* n: There can be multiple.

Noun description:

Module prefix
The prefix used when defining a module.
Type
Defines the content type of the class. Such as input boxes, text, paragraphs, etc.
Function
Defines the function of the class, which is used to supplement the type.
Status
Defines the status of the class, used to supplement the type.
Position
Define the position used by the class, such as homepage, navigation, etc. The use of words like left and right is not excluded, but it should be avoided as much as possible.
* Each item can have its own abbreviation list, and the abbreviations of the same name should be as unified as possible.
* The words selected should be words that do not express a certain state (such as color, size, etc.) in detail to avoid the name losing its meaning when the state changes.
* Consists of lowercase letters (a-z) and numbers (0-9) that do not start with a number.
* Ensure the reusability of the class (.class) and the uniqueness of the object (#id). Avoid using reserved words for id.

Example:

Java code

1. Module prefix:
3. * Pop up
4. * Public global, gb
5. * Title title, tit
6. * Hint
7. * Menu menu
8. * Information info
9. * Preview pvw
10. * Tips tips
11. * Navigation nav
13. Type:
15. * button bt
16. * text tx
17. * paragraph p
18. * icon icon
19. * input input
20. * Color color,c
21. * Background bg
22. * Border bor
24. Function:
26. * Setting set
27. * Add add
28. * Delete del
29. * Operation op
30. * Password pw
31. * Import inc
33. Status:
35. * Success suc
36. * Failure Lost
37. * Transparent tran
39. Position:
41. * public gb
42. * border bor
43. * paragraph p
44. * popup
45. * title title,tit
46. * menu menu
47. * content cont
48. * navigation nav

Chinese explanation naming
Text input box.input_tx Paragraph text color .c_tx_p
Password input box.input_pw Album pop-up setting layer.pop_set_photo
Login password input box .input_pw_login Log setting successful prompt.hint_suc_blogset
Text color.c_tx Public prompt.hint_gb

Asking a few simple questions can help us complete the naming:

1. "What type of Definition? "?? is an input box, input.
2. "Type supplementary explanation"?? If the description of a word is unclear, then supplementary explanation of the type, text input box, input_tx.
3. “Where to use?”?? Where is the location to be used? The search text input box on the homepage, input_search_index.

Combined with "modularization" related methods to define, in fact, there are not many names that need to be defined. For example: "hint_tx" represents the text definition of the prompt module, and "hit_tx_hint" represents the definition of text emphasis in the prompt. As for whether to change the color or make it bold, it depends on the needs of different prompt modules.