Update zh-CN translation

translations/zh-CN/README.md

@@ -1,6 +1,6 @@
 # 编写如一、符合习惯的CSS的原则
 
-以下文档将概述一个合理的CSS开发风格指导。本指导文件强烈鼓励开发者使用已经存在了的、常见的、合力的文风。您应该有选择地吸纳一些内容来创造您自己的风格指南。
+以下文档将概述一个合理的CSS开发风格指导。本指导文件强烈鼓励开发者使用现有的、通用的、合理的模式。您应该有选择地吸纳一些内容来创造您自己的风格指南。
 
 这个文档将持续更新，欢迎提出新的想法。还请多多贡献。
 
@@ -13,10 +13,7 @@
 2. [空格](#whitespace)
 3. [注释](#comments)
 4. [格式](#format)
-5. [命名](#naming)
-6. [实例](#example)
-7. [代码组织](#organization)
-8. [构建及部署](#build-and-deployment)
+5. [实例](#example)
 
 [致谢](#acknowledgements)
 
@@ -42,7 +39,7 @@
 * 在软缩进（使用空格）和真正的制表符间选择其一，并始终坚持这一选择。（推荐使用空格）
 * 如果使用空格进行缩进，选择每个缩进所使用的空格数。（推荐：4个空格）
 
-提示：将编辑器配置为“显示不可见内容”。这使你可以清除行尾的空格和不需要缩进的空行里的空格，同时可以避免对注释的污染。
+提示：将编辑器配置为“显示不可见内容”或者自动清楚行尾的空格。
 
 提示：确定好一种空格格式后，您可以用一个[EditorConfig](http://editorconfig.org/)文件（或者其他相同的东西）来帮助在代码库之间维持这种基本的空格约定。
 
@@ -96,14 +93,19 @@
 
 最终选择的代码风格必须保证：易于阅读，易于清晰地注释，最小化无意中引入错误的可能性，可生成有用的diff和blame。
 
-1. 在多个选择器的规则集中，每个单独的选择器独占一行。
-2. 在规则集的左大括号前保留一个空格。
-3. 在声明块中，每个声明独占一行。
-4. 每个声明前保留一级缩进。
-5. 每个声明的冒号后保留一个空格。
-6. 对于声明块的最后一个声明，始终保留结束的分号。
-7. 规则集的右大括号保持与该规则集的第一个字符在同一列。
-8. 每个规则集之间保留一个空行。
+* 在多个选择器的规则集中，每个单独的选择器独占一行。
+* 在规则集的左大括号前保留一个空格。
+* 在声明块中，每个声明独占一行。
+* 每个声明前保留一级缩进。
+* 每个声明的冒号后保留一个空格。
+* 使用小写和简写的十六进制值。例如：`#aaa`。
+* 使用单引号或双引号请保持一致。推荐使用双引号，例如：`content: ""`。
+* 选择器中的属性值用引号包含，例如：`input[type="checkbox"]`。
+* 如果可以的话，避免为零值指明单位，例如：`margin: 0`。
+* 使用逗号分隔的属性值或函数中的值，在逗号之后保留一个空格。
+* 对于声明块的最后一个声明，始终保留结束的分号。
+* 规则集的右大括号保持与该规则集的第一个字符在同一列。
+* 每个规则集之间保留一个空行。
 
 ```css
 .selector-1,
@@ -127,10 +129,9 @@
 
 #### 声明顺序
 
-样式声明的顺序应当遵守一个单一的原则。我的倾向是将相关的属性组合在一起，并且将对结构来说比较重要的属性（如定位或者盒模型）
-放在前面，先于排版、背景及颜色等属性。
+如果声明要始终如一地排列，则应遵循单一，简单的原则。
 
-小型的开发团体，可能会想要把相关的属性声明（比如说定位和箱模型）摆在一起。
+小型的开发团体，可能会想要把相关的属性声明（比如说定位和盒模型）摆在一起。
 
 ```css
 .selector {
@@ -187,13 +188,6 @@
 }
 ```
 
-#### 杂项
-
-* 在十六进制值中，使用小写，如`#aaa`。
-* 单引号或双引号的选择保持一致。推荐使用双引号，如`content: ""`。
-* 对于选择器中的属性值也加上引号，如`input[type="checkbox"]`。
-* *如果可以的话*，不要给0加上单位, 如`margin: 0`。
-
 ### 预处理：格式方面额外的考虑
 
 不同的CSS预处理有着不同的特性、功能以及语法。编码习惯应当根据使用的预处理程序进行扩展，以适应其特有的功能。推荐在使用SCSS时遵守以下指导。
@@ -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. 实例
 
 下面是含有上述约定的示例代码：
 
@@ -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/)许可证下的作品。该许可证适用于本代码栈中的所有文档，包括翻译文本。