Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
92 changes: 20 additions & 72 deletions translations/zh-CN/README.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# 编写如一、符合习惯的CSS的原则

以下文档将概述一个合理的CSS开发风格指导。本指导文件强烈鼓励开发者使用已经存在了的、常见的、合力的文风。您应该有选择地吸纳一些内容来创造您自己的风格指南。
以下文档将概述一个合理的CSS开发风格指导。本指导文件强烈鼓励开发者使用现有的、通用的、合理的模式。您应该有选择地吸纳一些内容来创造您自己的风格指南。

这个文档将持续更新,欢迎提出新的想法。还请多多贡献。

Expand All @@ -13,10 +13,7 @@
2. [空格](#whitespace)
3. [注释](#comments)
4. [格式](#format)
5. [命名](#naming)
6. [实例](#example)
7. [代码组织](#organization)
8. [构建及部署](#build-and-deployment)
5. [实例](#example)

[致谢](#acknowledgements)

Expand All @@ -42,7 +39,7 @@
* 在软缩进(使用空格)和真正的制表符间选择其一,并始终坚持这一选择。(推荐使用空格)
* 如果使用空格进行缩进,选择每个缩进所使用的空格数。(推荐:4个空格)

提示:将编辑器配置为“显示不可见内容”。这使你可以清除行尾的空格和不需要缩进的空行里的空格,同时可以避免对注释的污染
提示:将编辑器配置为“显示不可见内容”或者自动清楚行尾的空格

提示:确定好一种空格格式后,您可以用一个[EditorConfig](http://editorconfig.org/)文件(或者其他相同的东西)来帮助在代码库之间维持这种基本的空格约定。

Expand Down Expand Up @@ -96,14 +93,19 @@

最终选择的代码风格必须保证:易于阅读,易于清晰地注释,最小化无意中引入错误的可能性,可生成有用的diff和blame。

1. 在多个选择器的规则集中,每个单独的选择器独占一行。
2. 在规则集的左大括号前保留一个空格。
3. 在声明块中,每个声明独占一行。
4. 每个声明前保留一级缩进。
5. 每个声明的冒号后保留一个空格。
6. 对于声明块的最后一个声明,始终保留结束的分号。
7. 规则集的右大括号保持与该规则集的第一个字符在同一列。
8. 每个规则集之间保留一个空行。
* 在多个选择器的规则集中,每个单独的选择器独占一行。
* 在规则集的左大括号前保留一个空格。
* 在声明块中,每个声明独占一行。
* 每个声明前保留一级缩进。
* 每个声明的冒号后保留一个空格。
* 使用小写和简写的十六进制值。例如:`#aaa`。
* 使用单引号或双引号请保持一致。推荐使用双引号,例如:`content: ""`。
* 选择器中的属性值用引号包含,例如:`input[type="checkbox"]`。
* 如果可以的话,避免为零值指明单位,例如:`margin: 0`。
* 使用逗号分隔的属性值或函数中的值,在逗号之后保留一个空格。
* 对于声明块的最后一个声明,始终保留结束的分号。
* 规则集的右大括号保持与该规则集的第一个字符在同一列。
* 每个规则集之间保留一个空行。

```css
.selector-1,
Expand All @@ -127,10 +129,9 @@

#### 声明顺序

样式声明的顺序应当遵守一个单一的原则。我的倾向是将相关的属性组合在一起,并且将对结构来说比较重要的属性(如定位或者盒模型)
放在前面,先于排版、背景及颜色等属性。
如果声明要始终如一地排列,则应遵循单一,简单的原则。

小型的开发团体,可能会想要把相关的属性声明(比如说定位和箱模型)摆在一起。
小型的开发团体,可能会想要把相关的属性声明(比如说定位和盒模型)摆在一起。

```css
.selector {
Expand Down Expand Up @@ -187,13 +188,6 @@
}
```

#### 杂项

* 在十六进制值中,使用小写,如`#aaa`。
* 单引号或双引号的选择保持一致。推荐使用双引号,如`content: ""`。
* 对于选择器中的属性值也加上引号,如`input[type="checkbox"]`。
* *如果可以的话*,不要给0加上单位, 如`margin: 0`。

### 预处理:格式方面额外的考虑

不同的CSS预处理有着不同的特性、功能以及语法。编码习惯应当根据使用的预处理程序进行扩展,以适应其特有的功能。推荐在使用SCSS时遵守以下指导。
Expand All @@ -214,35 +208,8 @@
}
```


<a name="naming"></a>
## 5. 命名

不要试着把自己当作编译器或者预处理器,因此命名的时候尽量采用清晰的、有意义的名字。另外,对于
html文件和css文件中的代码,尽量采用一致的命名规则。


```css
/* 没有意义的命名 */
.s-scr {
overflow: auto;
}
.cb {
background: #000;
}

/* 比较有意义的命名方式 */
.is-scrollable {
overflow: auto;
}
.column-body {
background: #000;
}
```


<a name="example"></a>
## 6. 实例
## 5. 实例

下面是含有上述约定的示例代码:

Expand Down Expand Up @@ -328,29 +295,10 @@ html文件和css文件中的代码,尽量采用一致的命名规则。
}
```


<a name="organization"></a>
## 7. 代码组织

对于css代码库来说,如何组织代码文件是很重要的,尤其对于那些很大的代码库显得更加重要。这里介绍
几个组织代码的建议:

* 逻辑上对不同的代码进行分离。
* 不同的组件(component)的css尽量用不同的css文件(可以在build阶段用工具合并到一起)
* 如果用到了预处理器(比如less),把一些公共的样式代码抽象成变量,例如颜色,字体等等。


<a name="build-and-deployment"></a>
## 8. 构建及部署

任何一个项目,都应该有一个build的过程,在这个阶段我们可以通过工具对代码进行检测,测试,压缩等等,还
可以为生产环境准备好带有版本号的代码。在这里我推荐一下[grunt](https://github.com/cowboy/grunt)这个工具,我感觉它很不错。


<a name="acknowledgements"></a>
## 致谢

感谢所有对[idiomatic.js](https://github.com/rwldrn/idiomatic.js)作出贡献的网友。
感谢所有提供翻译和对[idiomatic.js](https://github.com/rwldrn/idiomatic.js)作出贡献的网友。这是启发,引用和指导的源泉

##许可
_Principles of writing consistent, idiomatic CSS_ 是Nicolas Gallagher发布在[Creative Commons Attribution 3.0 Unported License](http://creativecommons.org/licenses/by/3.0/)许可证下的作品。该许可证适用于本代码栈中的所有文档,包括翻译文本。
Expand Down