Maison >interface Web >tutoriel HTML >Spécifications d'écriture d'utilisation CSS
Peut-être que différentes équipes ont leurs propres spécifications, ou que beaucoup de gens écrivent encore ce qu'ils pensent lorsqu'ils écrivent du CSS, sans trop de contraintes.
Je pense que les normes de code CSS sont toujours nécessaires, notamment dans le travail d'équipe et la collaboration à plusieurs personnes, les normes sont particulièrement importantes.
Ce qui est répertorié dans cet article est un ensemble relativement bon de spécifications d'écriture CSS dérivées de la pratique. Je n'espère pas que tout le monde les adoptera complètement, mais vous pouvez en développer une en fonction de vos propres besoins. besoins de votre propre équipe. Définissez les spécifications de code CSS qui vous conviennent.
J'espère aussi avoir plus de suggestions et m'améliorer ensemble. Cette spécification peut également être consultée sur mon Github. Vous êtes invités à laisser un message ou à soumettre un PR.
utilise l'encodage UTF-8
et est utilisé dans le code CSS header :
@charset "utf-8";
Notez qu'il doit être défini devant tous les caractères du fichier CSS (y compris les commentaires d'encodage) pour
@charset
pour prendre effet.
Par exemple, les exemples suivants rendront @charset
invalide :
/* 字符编码 */ @charset "utf-8"; html, body { height: 100%; } @charset "utf-8";
Mise en page : g est l'espace de noms, par exemple : .g- wrap, .g-header, .g-content.
Statut : avec s comme espace de noms, il représente un statut dynamique et interactif, tel que : .s-current, s-selected.
Outils : Avec u comme espace de noms, il représente des outils réutilisables qui ne sont pas couplés à une logique métier, tels que : u-clearfix, u-ellipsis.
Composant : m est l'espace de noms, représentant des modules de composants réutilisables et portables, tels que : m-slider, m-dropMenu.
Hook : Avec j comme espace de noms, il représente le nom de classe spécifique aux appels JavaScript, tels que : j-request, j-open.
Pas de choix BEM
Ce type de dénomination est trop strict et le nom du style l'est trop Les vilaines règles adoptent une solution plus de compromis.
Économisez les opérations et moins de temps en tapant Appuyer sur une touche shift
peut bien distinguer le nom des variables JavaScript
Lorsqu'une règle contient plusieurs sélecteurs, chaque sélecteur occupe sa propre ligne.
, +, ~, > laissez un espace de chaque côté du sélecteur.
.g-header > .g-header-des, .g-content ~ .g-footer { }
当规则声明块中有多个样式声明时,每条样式独占一行。
在规则声明块的左大括号 { 前加一个空格。
在样式属性的冒号 : 后面加上一个空格,前面不加空格。
在每条样式后面都以分号 ; 结尾。
规则声明块的右大括号 } 独占一行。
每个规则声明间用空行分隔。
所有最外层引号使用单引号 ' 。
当一个属性有多个属性值时,以逗号 , 分隔属性值,每个逗号后添加一个空格,当单个属性值过长时,每个属性值独占一行。
完整示例如下:
.g-footer, .g-header { position: relative; } .g-content { background: linear-gradient(135deg, deeppink 25%, transparent 25%) -50px 0, linear-gradient(225deg, deeppink 25%, transparent 25%) -50px 0, linear-gradient(315deg, deeppink 25%, transparent 25%), linear-gradient(45deg, deeppink 25%, transparent 25%); } .g-content::before { content: ''; }
当属性值或颜色参数为 0 - 1 之间的数时,省略小数点前的 0 。
color: rgba(255, 255, 255, 0.5)
color: rgba(255, 255, 255, .5);
当长度值为 0 时省略单位。
margin: 0px auto
margin: 0 auto
十六进制的颜色属性值使用小写和尽量简写。
color: #ffcc00
color: #fc0
单个样式规则下的属性在书写时,应按功能进行分组,并以 Positioning Model > Box Model > Typographic > Visual 的顺序书写,提高代码的可读性。
如果包含 content 属性,应放在最前面;
Positioning Model 布局方式、位置,相关属性包括:position / top / right / bottom / left / z-index / display / float / ...
Box Model 盒模型,相关属性包括:width / height / padding / margin / border / overflow / ...
Typographic 文本排版,相关属性包括:font / line-height / text-align / word-wrap / ...
Visual 视觉外观,相关属性包括:color / background / list-style / transform / animation / transition / ...
Positioning 处在第一位,因为他可以使一个元素脱离正常文本流,并且覆盖盒模型相关的样式。盒模型紧跟其后,因为他决定了一个组件的大小和位置。其他属性只在组件内部起作用或者不会对前面两种情况的结果产生影响,所以他们排在后面。
在某些样式中,会出现一些含有空格的关键字或者中文关键字。
font-family
内使用引号当字体名字中间有空格,中文名字体及 Unicode 字符编码表示的中文字体,为了保证兼容性,都建议在字体两端添加单引号或者双引号:
body { font-family: 'Microsoft YaHei', '黑体-简', '\5b8b\4f53'; }
background-image
的 url 内使用引号如果路径里面有空格,旧版 IE 是无法识别的,会导致路径失效,建议不管是否存在空格,都添加上单引号或者双引号:
div { background-image: url('...'); }
!important
除去某些极特殊的情况,尽量不要不要使用 !important
。
!important
的存在会给后期维护以及多人协作带来噩梦般的影响。
当存在样式覆盖层叠时,如果你发现新定义的一个样式无法覆盖一个旧的样式,只有加上
!important
才能生效时,是因为你新定义的选择器的优先级不够旧样式选择器的优先级高。所以,合理的书写新样式选择器,是完全可以规避一些看似需要使用!important
的情况的。
星号与内容之间必须保留一个空格。
/* 表格隔行变色 */
星号要一列对齐,星号与内容之间必须保留一个空格。
/** * Sometimes you need to include optional context for the entire component. Do that up here if it's important enough. */
使用 // 注释,// 后面加上一个空格,注释独立一行。
.g-footer { border: 0; // .... }
文件顶部必须包含文件注释,用 @name 标识文件说明。星号要一列对齐,星号与内容之间必须保留一个空格,标识符冒号与内容之间必须保留一个空格。
/** * @name: 文件名或模块名 * @description: 文件或模块描述 * @author: author-name(mail-name@domain.com) * author-name2(mail-name2@domain.com) * @update: 2015-04-29 00:02 */
@description为文件或模块描述。
@update为可选项,建议每次改动都更新一下。
当该业务项目主要由固定的一个或多个人负责时,需要添加@author标识,一方面是尊重劳动成果,另一方面方便在需要时快速定位责任人。
使用 SASS
、 LESS
等预处理器时,建议嵌套层级不超过 3 层。
组件/公用类使用 %placeholders
定义,使用 @extend
引用。如:
%clearfix { overflow: auto; zoom: 1; } .g-header { @extend %clearfix; }
使用 SASS ,经常会预先定义好一些常用公用组件类,譬如清除浮动,水平垂直居中,文字 ellipsis。又或者多个元素具有同样的样式,我们希望能够少写这部分代码,公共部分抽离出来只写一次,达到复用。
但是复用的方式在 SASS 中有多种,那么是使用单独使用一个类定义,给需要的标签添加,还是使用 @include
或者 @extend
在定义的类中引入一个 @mixin
,或者一个 @function
呢?
基于让 CSS 更简洁以及代码的复用考虑,采用上面的使用 %placeholders
定义,使用 @extend
引用的方案。
%placeholders
,只是一个占位符,只要不通过 @extend
调用,编译后不会产生任何代码量
使用 @extend
引用,则是因为每次调用相同的 %placeholders
时,编译出来相同的 CSS 样式会进行合并(反之,如果使用 @include
调用定义好的 @mixin
,编译出来相同的 CSS 样式不会进行合并)
这里的组件类特指那些不会动态改变的 CSS 样式,注意与那些可以通过传参生成不同数值样式的 @mixin
方法进行区分
使用 SASS ,或者说在 CSS 里也有这种困惑。
假设我们有如下 html 结构:
<div class="g-content"> <ul class="g-content-list"> <li class="item"></li> <li class="item"></li> <li class="item"></li> <li class="item"></li> </ul> </div>
在给最里层的标签命名书写样式的时候,我们有两种选择:
.g-content { .g-content-list { li { ... } } }
或者是
.g-content { .g-content-list { .item { ... } } }
也就是,编译之后生成了下面这两个,到底使用哪个好呢?
.g-content .g-content-list li { }
.g-content .g-content-list .item { }
基于 CSS 选择器的解析规则(从右向左),建议使用上述第二种 .g-content .g-content-list .item { }
,避免使用通用标签名作为选择器的一环可以提高 CSS 匹配性能。
浏览器的排版引擎解析 CSS 是基于从右向左(right-to-left)的规则,这么做是为了使样式规则能够更快地与渲染树上的节点匹配。
本规范也可以在我的 Github 上看到,欢迎留言或者提 PR。
到此本文结束,如果还有什么疑问或者建议,可以多多交流,原创文章,文笔有限,才疏学浅,文中若有不正之处,万望告知。
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!