The legendary Mozilla recommendation
Java code
- /* mozilla.org Base Styles
- * Maintained by Fantasai
- */
- /* Suggested Order:
- * Display
- * List-style
- * Position
- * Float
- * Clear
- * Width
- * Height
- * Margin
- * Padding
- * Border
- * Background
- * Color
- * Font
- * Text-decoration
- * Text-align
- * Vertical-align
- * White-space
- * Other text
- * Content
- *
- */
- ...
Source:
Java code
- http://www.mozilla.org/css/base/content.css
In this article in Yiwen's blog, the above attributes are divided into three groups: Display properties, own attributes, and text attributes. In reply, ING added that this also relates to the parsing process of the browser: The browser first locates the DOM, parses its own properties, and then parses the inner object. (not found in the relevant English materials, some people also hope to inform)
In the Mozilla official, actually does not recommend any CSS writing order. It is likely that a developer reading Fantasai's article mozilla.org Markup Reference, and was interested in the Fantasai CSS source file, so it was discovered.
Alphabetical order
There are some good articles on nettuts, which is not, not so long ago, Trevor Davis shared an article: 5 Ways to instantly Write Better CSS. In this article, it is recommended that the properties of CSS be sorted alphabetically.
The advantage is: simple, anyone just abide by, one can understand.
The disadvantage is: too simple, lack of logic. For example, position, left, top, and so on, this kind of tightly related properties, if all alphabetically sorted, writing and maintenance is not convenient. Andy Ford's recommended sort
Andy Ford, an expert in HTML and CSS, recently wrote an article: Order of the Day:css Properties. The recommended CSS writing order for this article is:
Java code
- 1. Display & Flow
- 2. Positioning
- 3. Dimensions
- 4. Margins, Padding, Borders, Outline
- 5. Typographic Styles
- 6. Backgrounds
- 7. Opacity, Cursors, Generated Content
- Example:
- El {
- Display:;
- Visibility:;
- float:;
- Clear:;
- Position:;
- Top:;
- Right:;
- Bottom:;
- Left:;
- Z-index:;
- Width:;
- Min-width:;
- Max-width:;
- Height:;
- Min-height:;
- Max-height:;
- Overflow:;
- margin:;
- Margin-top:;
- Margin-right:;
- Margin-bottom:;
- Margin-left:;
- padding:;
- Padding-top:;
- Padding-right:;
- Padding-bottom:;
- Padding-left:;
- border:;
- Border-top:;
- Border-right:;
- Border-bottom:;
- Border-left:;
- Border-width:;
- Border-top-width:;
- Border-right-width:;
- Border-bottom-width:;
- Border-left-width:;
- Border-style:;
- Border-top-style:;
- Border-right-style:;
- Border-bottom-style:;
- Border-left-style:;
- Border-color:;
- Border-top-color:;
- Border-right-color:;
- Border-bottom-color:;
- Border-left-color:;
- Outline:;
- List-style:;
- Table-layout:;
- Caption-side:;
- Border-collapse:;
- Border-spacing:;
- Empty-cells:;
- Font:;
- Font-family:;
- Font-size:;
- Line-height:;
- Font-weight:;
- Text-align:;
- Text-indent:;
- Text-transform:;
- Text-decoration:;
- Letter-spacing:;
- Word-spacing:;
- White-space:;
- Vertical-align:;
- Color:;
- Background:;
- ;
- Background-image:;
- Background-repeat:;
- Background-position:;
- Opacity:;
- Cursor:;
- Content:;
- Quotes:;
- }
The order of Andy is generally consistent with the order recommended by Fantasai, but the details are more operable.
SitePoint also has a very warm discussion on the post: how does the order your properties within a declaration block?
I like the Fantasai and Andy's writing order, but in the Fantasai order, the "self" attribute is a little vague and Andy's is too thin to remember. I think the CSS 2.1 specification can be used for reference to the classification of CSS properties, the order of Andy slightly adjusted:
1. Properties that affect the flow of the document (e.g. display, position, float, clear, visibility, table-layout, etc.)
2. Properties of the Self-box model (e.g. width, height, margin, padding, border, etc.)
3. Typography related attributes (e.g. font, line-height, Text-align, text-indent, vertical-align, etc.)
4. Decorative properties (e.g. color, background, opacity, cursor, etc.)
5. Properties of the generated content (for example: content, List-style, quotes, etc.)
Things are never that simple, such as the following:
1. What do I do with shorthand? such as border:1px solid red; The border-width is related to the box model, but the border-color is decorative. How is it organized?
2. Considering the skin-changing function, should I put a color, background, border-color and other colors in a piece? To facilitate later modification.
3. How do I handle hacks? Do you put it in the last side of the CSS file, or with the properties of hack next to each other?
4. How do I annotate a newly added or modified property while maintaining a colleague's CSS file? How to write?
5. Also, considering the CSS Sprite, all the background map selectors are put together? However, this is beyond the topic of this article: the Order and organization of attributes within the CSS selector.
6. A further discussion is the structure of the CSS file, as well as the organization of multiple CSS files.
CSS Naming conventions:
CSS, like other programs, has the concept of scope, which has a global, class-local role in these ways.
As an example:
P{background: #f00;} /* Scope: Global */
. Div p{color: #000;} /* Scope: div class */
Introduction to several methods of writing CSS and weight comparison
1) Tag: Weight value is 0,0,0,1
2) Class: Weight value is 0,0,1,0
3) Attribute selection: Weight value is 0,0,1,1
4) ID: The weight value is 0,1,0,0
5) The weight of the important is the highest 1,0,0,0
I believe that when you write CSS, when the project is relatively large, the content of a lot of time, the name is a very headache, and a block inside to show the style of different states, which is a master naming rules is a tool, can let you work together with more effort. Roughly as follows: (Reprinted from: http://www.cssforest.org/blog/index.php?id=143, we can go here to see, more technical articles)
To avoid the loss of meaning when the state changes, the most common is the class name for the layout, such as "left" and "right", which is meaningless when the leftmost column is no longer the left column. This is contrary to what we recommend "naming to be meaningful", and the use of serial numbers is even more problematic. It seems to be true, but for a long time there is a problem that bothers me, if a page in the same module appears more than once, and the details are not the same, then what should be called after the name? Is "one", "one" and "the other" not serial number? In fact, we have to avoid the situation is that when the state (performance) changes, the corresponding definition of the class name will not lose meaning.
The so-called state (performance) changes, there are several situations:
1. The HTML is unchanged, and the style definition changes. If naming uses a name that represents a state, such as "Red", "font14", and so on, it is bound to cause the definition and naming do not match the situation, the subsequent impact will have a relatively large impact.
2. The style definition does not change, 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 state, it is more beneficial to modify.
3. The style definition and HTML are changed. Just consider not having the result of the first case.
And the actual situation is not a simple situation, more time is mixed with the appearance.
Rules
[Module Prefix] _ type _ (Action | state) n _ [position n]
Legend Description:
* (required): must exist.
* [OPTIONAL]: can be selected as required.
* |: Choose one more.
* N: can have more than one.
Noun Description:
Module prefix
The prefix used when the module is defined.
Type
Defines the content type of the class. such as input boxes, text, paragraphs, and so on.
Role
Defines the role of the class, which is used to supplement the type.
State
Defines the state of the class, which is used to supplement the type.
Position
Define the location used by the class, such as home page, navigation and so on, do not exclude the use of the left and right words, but should try to avoid.
* Each item can have its own abbreviation table, the same name abbreviation as far as possible unified.
* Select words that are not too specific to represent a certain state (such as color, size, etc.) to avoid the loss of meaning when the state changes.
* Consists of lowercase letters (A-Z) and Numbers (0-9) that do not begin with a number.
* Ensure that the reusability of the class (. Class) is unique to the object (#id), and the ID avoids the use of reserved words.
Cases:
Java code
- Module prefix:
- * Pop POPs
- * Public GLOBAL,GB
- * Title Title,tit
- * Hint hint
- * Menu
- * Info Info
- * Preview PVW
- * Tips Tips
- * Nav Nav
- Type:
- * Button BT
- * Text TX
- * Paragraph P
- * Icons icon
- * Input Input
- * Color Color,c
- * Background BG
- * Border Bor
- Role:
- * Setting Set
- * Adding add
- * Delete del
- * Operation op
- * Password PW
- * Import Inc
- State:
- * Successful SUC
- * Failure lost
- * Transparent Tran
- Position:
- * Public GB
- * Border Bor
- * Paragraph P
- * Pop POPs
- * Title Title,tit
- * Menu
- * Content cont
- * Nav Nav
Chinese interpretation naming Chinese interpretation naming The
Text entry box. Input_tx paragraph text color . c_tx_p
Password entry box. INPUT_PW album pop-up settings layer. pop_set_ photo
Login password entry box. Input_pw_login log Settings successful prompt. hint_suc_blogset
text color. C_tx public tips. hint_gb
Ask a few simple questions that can help us complete the naming:
1. "What type of definition?" "--is an input box.
2. "Type Supplemental Notes"--if a word is not clear, then the supplemental description type, text input box, Input_tx.
3. "Where to use?" "--Define where you want to use the location? Homepage of the Search text input box, Input_search_index.
in conjunction with "modular" related methods to define, actually need to define the name does not need a lot. such as: "Hint_tx" indicates the text definition of the hint module, "hit_tx_hint" means the definition of the text in the hint, as to whether to change the color or bold, this depends on the needs of different cue modules.