Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/chadluo/CSS-Guidelines
a zh-CN translation
https://github.com/chadluo/CSS-Guidelines
Last synced: about 2 months ago
JSON representation
a zh-CN translation
- Host: GitHub
- URL: https://github.com/chadluo/CSS-Guidelines
- Owner: chadluo
- Fork: true (csswizardry/CSS-Guidelines)
- Created: 2013-04-21T16:08:56.000Z (over 11 years ago)
- Default Branch: master
- Last Pushed: 2014-11-18T12:22:40.000Z (almost 10 years ago)
- Last Synced: 2024-05-01T13:21:51.194Z (5 months ago)
- Homepage:
- Size: 771 KB
- Stars: 654
- Watchers: 38
- Forks: 160
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
- awesome - chadluo/CSS-Guidelines - a zh-CN translation (Others)
README
# 通用 CSS 笔记、建议与指导
---
[原文](https://github.com/csswizardry/CSS-Guidelines)
在参与规模庞大、历时漫长且参与人数众多的项目时,所有开发者遵守如下规则极为重要:
+ 保持 CSS 易于维护
+ 保持代码清晰易懂
+ 保持 CSS 的可拓展性为了实现这一目标,我们要采用诸多方法。
本文档第一部分将探讨语法、格式以及分析 CSS 结构;第二部分将围绕方法论、思维框架以及编写与规划 CSS 的看法。
## 目录
**第一部分**
* [CSS 文档分析](#css-%E6%96%87%E6%A1%A3%E5%88%86%E6%9E%90)
* [总则](#%E6%80%BB%E5%88%99)
* [单一文件与多文件](#%E5%8D%95%E4%B8%80%E6%96%87%E4%BB%B6%E4%B8%8E%E5%A4%9A%E6%96%87%E4%BB%B6)
* [目录](#%E7%9B%AE%E5%BD%95-1)
* [区块标题](#%E5%8C%BA%E5%9D%97%E6%A0%87%E9%A2%98)
* [代码顺序](#%E4%BB%A3%E7%A0%81%E9%A1%BA%E5%BA%8F)
* [CSS 规则集分析](#css-%E8%A7%84%E5%88%99%E9%9B%86%E5%88%86%E6%9E%90)
* [命名规范](#%E5%91%BD%E5%90%8D%E8%A7%84%E8%8C%83)
* [JavaScript 钩子](#javascript-%E9%92%A9%E5%AD%90)
* [I18n](#i18n)
* [注释](#%E6%B3%A8%E9%87%8A)
* [注释的拓展用法](#%E6%B3%A8%E9%87%8A%E7%9A%84%E6%8B%93%E5%B1%95%E7%94%A8%E6%B3%95)
* [准修饰选择器](#%E5%87%86%E4%BF%AE%E9%A5%B0%E9%80%89%E6%8B%A9%E5%99%A8)
* [代码标签](#%E4%BB%A3%E7%A0%81%E6%A0%87%E7%AD%BE)
* [继承标记](#%E7%BB%A7%E6%89%BF%E6%A0%87%E8%AE%B0)**第二部分**
* [编写 CSS](#%E7%BC%96%E5%86%99-css)
* [编写新组件](#%E7%BC%96%E5%86%99%E6%96%B0%E7%BB%84%E4%BB%B6)
* [面向对象 CSS](#%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1-css)
* [布局](#%E5%B8%83%E5%B1%80)
* [UI 尺寸](#ui-%E5%B0%BA%E5%AF%B8)
* [字号](#%E5%AD%97%E5%8F%B7)
* [简写](#%E7%AE%80%E5%86%99)
* [ID](#id)
* [选择器](#%E9%80%89%E6%8B%A9%E5%99%A8)
* [过修饰选择器](#%E8%BF%87%E5%BA%A6%E4%BF%AE%E9%A5%B0%E7%9A%84%E9%80%89%E6%8B%A9%E5%99%A8)
* [选择器性能](#%E9%80%89%E6%8B%A9%E5%99%A8%E6%80%A7%E8%83%BD)
* [使用 CSS 选择器的目的](#%E4%BD%BF%E7%94%A8-css-%E9%80%89%E6%8B%A9%E5%99%A8%E7%9A%84%E7%9B%AE%E7%9A%84)
* [`!important`](#important)
* [魔数与绝对定位](#%E9%AD%94%E6%95%B0%E4%B8%8E%E7%BB%9D%E5%AF%B9%E5%AE%9A%E4%BD%8D)
* [条件判断](#%E6%9D%A1%E4%BB%B6%E5%88%A4%E6%96%AD)
* [Debugging](#debugging)
* [CSS 预处理器](#css-%E9%A2%84%E5%A4%84%E7%90%86%E5%99%A8)---
## CSS 文档分析
无论编写什么文档,我们都应当维持统一的风格,包括统一的注释、统一的语法与统一的命名规范。
### 总则
将行宽控制在 80 字节以下。渐变(gradient)相关的语法以及注释中的 URL 等可以算作例外,毕竟这部分我们也无能为力。
我倾向于用 4 个空格而非 Tab 缩进,并且将声明拆分成多行。
### 单一文件与多文件
有人喜欢在一份文件文件中编写所有的内容,而我在迁移至 Sass 之后开始将样式拆分成多个小文件。这都是很好的做法。无论你选择哪种,下文的规则都将适用,而且如果你遵守这些规则的话你也不会遇到什么问题。这两种写法的区别仅仅在于目录以及区块标题:
### 目录
在 CSS 的开头,我会维护一份目录,就像这样:
/*------------------------------------*\
$CONTENTS
\*------------------------------------*/
/**
* CONTENTS............You’re reading it!
* RESET...............Set our reset defaults
* FONT-FACE...........Import brand font files
*/这份目录可以告诉其他开发者这个文件中具体含有哪些内容。这份目录中的每一项都与其对应的区块标题相同。
如果你在维护一份单文件 CSS,对应的区块将也在同一文件中。如果你是在编写一组小文件,那么目录中的每一项应当对应相应的 @include 语句。
### 区块标题
目录应当对应区块的标题。如下:
/*------------------------------------*\
$RESET
\*------------------------------------*/区块标题前缀 `$` 可以让我们使用 [Cmd|Ctrl]+F 命令查找标题名时将搜索范围限制在区块标题中。
如果你在维护一份大文件,那么在区块之间空 5 行,如下:
/*------------------------------------*\
$RESET
\*------------------------------------*/
[Our
reset
styles]
/*------------------------------------*\
$FONT-FACE
\*------------------------------------*/在大文件中快速翻动时这些大块的空档有助于区分区块。
如果你在维护多份以 include 连接的 CSS 的话,在每份文件头加上标题即可,不必这样空行。
## 代码顺序
尽量按照特定顺序编写规则,这将确保你充分发挥 CSS 中第一个 C 的意义:cascade,层叠。
一份规划良好的 CSS 应当按照如下排列:
1. **Reset** 万物之根源
2. **元素类型** 没有 class 的 `h1`、`ul` 等
3. **对象以及抽象内容** 最一般、最基础的设计模式
4. **子元素** 由对象延伸出来的所有拓展及其子元素
5. **修补** 针对异常状态如此一来,当你依次编写 CSS 时,每个区块都可以自动继承在它之前区块的属性。这样就可以减少代码相互抵消的部分,减少某些特殊的问题,组成更理想的 CSS 结构。
关于这方面的更多信息,强烈推荐 Jonathan Snook 的 [SMACSS](http://smacss.com)。
## CSS 样式集分析
[selector]{
[property]:[value];
[<- Declaration ->]
}[选择器]{
[属性]:[值];
[<- 声明 ->]
}编写 CSS 样式时,我习惯遵守这些规则:
* class 名称以连字符(-)连接,除了下文提到的 BEM 命名法;
* 缩进 4 空格;
* 声明拆分成多行;
* 声明以相关性顺序排列,而非字母顺序;
* 有前缀的声明适当缩进,从而对齐其值;
* 缩进样式集从而反映 DOM;
* 保留最后一条声明结尾的分号。例如:
.widget{
padding:10px;
border:1px solid #BADA55;
background-color:#C0FFEE;
-webkit-border-radius:4px;
-moz-border-radius:4px;
border-radius:4px;
}
.widget-heading{
font-size:1.5rem;
line-height:1;
font-weight:bold;
color:#BADA55;
margin-right:-10px;
margin-left: -10px;
padding:0.25em;
}我们可以发现,`.widget-heading` 是 `.widget` 的子元素,因为前者的样式集比后者多缩进了一级。这样通过缩进就可以让开发者在阅读代码时快速获取这样的重要信息。
我们还可以发现 `.widget-heading` 的声明是根据其相关性排列的:`.widget-heading` 是行间元素,所以我们先添加字体相关的样式声明,接下来是其它的。
以下是一个没有拆分成多行的例子:
.t10 { width:10% }
.t20 { width:20% }
.t25 { width:25% } /* 1/4 */
.t30 { width:30% }
.t33 { width:33.333% } /* 1/3 */
.t40 { width:40% }
.t50 { width:50% } /* 1/2 */
.t60 { width:60% }
.t66 { width:66.666% } /* 2/3 */
.t70 { width:70% }
.t75 { width:75% } /* 3/4*/
.t80 { width:80% }
.t90 { width:90% }在这个例子(来自[inuit.css’s table grid system](https://github.com/csswizardry/inuit.css/blob/master/inuit.css/partials/base/_tables.scss#L88))中,将 CSS 放在一行内可以使得代码更紧凑。
## 命名规范
一般情况下我都是以连字符(-)连接 class 的名字(例如 `.foo-bar` 而非 `.foo_bar` 或 `.fooBar`),不过在某些特定的时候我会用 BEM(Block, Element, Modifier)命名法。
BEM 命名法可以使得选择器更规范,更清晰,更具语义。
该命名法按照如下格式:
.block{}
.block__element{}
.block--modifier{}其中:
* `.block` 代表某个基本的抽象元素;
* `.block__element` 代表构成 `.block` 的一个子元素;
* `.block--modifier` 代表 `.block` 的某个不同状态或版本。打个比方:
.person{}
.person--woman{}
.person__hand{}
.person__hand--left{}
.person__hand--right{}这个例子中我们描述的基本元素是一个人,然后这个人可能是一个女人。我们还知道人拥有手,这些是人体的一部分,而手也有不同的状态,如同左手与右手。
这样我们就可以根据亲元素来划定选择器的命名空间并传达该选择器的职能,例如根据这个选择器是一个子元素(`__`)还是其亲元素的不同状态(`--`)。
由此,`.page-wrapper` 是一个独立的选择器。这是一个符合规范的命名,因为它不是其它元素的子元素或其它状态;然而 `.widget-heading` 则与其它对象有关联,它应当是 `.widget` 的子元素,所以我们应当将其重命名为 `.widget__heading`。
BEM 命名法虽然不太好看,而且相当冗长,但是它使得我们可以通过名称快速获知元素的功能和元素之间的关系。与此同时,BEM 语法中的重复部分非常有利于 gzip 的压缩算法。
无论你是否使用 BEM 命名法,你都应当确保 class 命名得当,力保一字不多、一字不少;将元素命名抽象化以提高复用性(例如 `.ui-list`,`.media`)。子元素的命名则要尽量精准(例如 `.user-avatar-link`)。不用担心 class 名的数量或长度,因为写得好的代码 gzip 也能有效压缩。
### HTML 中的 class
为了确保易读性,在 HTML 标记中用两个空格隔开 class 名,例如: