【亚洲必赢官网】面向对象CSS的介绍

CSS架构

2013/04/24 · CSS ·
CSS

英文原文:CSS Architecture,编译:CSDN-张红月

Philip 沃尔顿 在AppFolio担任前端工程师,他在Santa Barbara on
Rails的聚首上指出了CSS架构和一部分极品实践,并且在工作中一贯沿用。

善用CSS的Web开发人员不仅可以从视觉上复制实物原型,还是能用代码进行完善的展现。无需利用表格、尽只怕少的行使图片。假若你是个名副其实的一把手,你可以神速把最新和最杰出的技术使用到你的档次中,比如媒体询问、过渡、滤镜、转换等。尽管这个都是一个的确的CSS高手所兼有的,但CSS很少被人独自拿出来啄磨,只怕用它去评估某个人的技能。

有意思的是,我们很少那样去评价其余语言。Rails开发人士并不会因为其代码相比较专业,就觉得她是一名出色的开发人员。那不过是个条件。当然,他的代码得必须正式。别的,还需集合其他地方考虑,比如代码是不是可读?是还是不是简单修改或扩展……

这都以些很当然的标题,CSS和它们并从未什么样差别之处。前几天的Web应用程序要比过去进一步宏大。一个不够深思远虑的CSS架构往往会减少发展,是时候像评估其余语言那样,来评估一下CSS架构了,那一个都不应当放在“事后”考虑恐怕仅仅属于设计师们的事务。

亚洲必赢官网 1

1.了不起的CSS架构目标

在CSS社区,很难提议某个最佳实践已经改为豪门的周边共识。纯粹地从Hacker
News的评论上判断和开发者们对CSS
Lint发表后的反应来看,大多数人对核心的CSS东西是持反对意见的。所以,并不是为祥和的极品实践奠定一套中央的实证,而相应确定真正的对象。

好的CSS架构目的并差别于开发一个好的应用程序,它必须是可预测、可采用、可爱惜和可伸缩的。

可预测

可预测意味着可以像预想的那么正式本身的一言一动。当你添加或然涂改某个规则时,它并不会潜移默化到没有点名的片段。对于一个小网站的话,一些微乎其微的改观并不算什么。而对此有着不少个页面的大网站来说,可预测却是必须的。

可重用

CSS规则应拥有抽象和平解决耦性,那样您就可以在存活的根基上神速打造新的机件,无需再一次修改编码形式。

可维护

当把新组件放置到网站上,并且实施添加、修改或许另行设计操作时,无需重构现有CSS,并且新加上的X并不会打破原来页面的Y组件。

可扩展

当网站发展到早晚规模后,都须求进行珍爱和扩张。可扩充的CSS意味着网站的CSS架构可以由个体可能协会轻易地管理,无需费用太多的就学开支。

 

2.广大的不当实践

在完毕杰出的CSS架构目的此前,我们来看有些广泛的错误做法,那对大家完成目标是有补益的。

上面的那些事例固然都可以很好的履行,但却会给你带来很多不快,即便大家的意向和意愿都是光明的,不过这几个支出情势会让您发烧。

差了一点在每一种网站上,都会有一个特定的虚构成分看起来与别的页面是一心平等的,可是只有一个页面除外。当面对如此一种景况时,大概每一个新手CSS开发人士(甚至是经验丰盛的)都会以同一的主意来修改。你应有为该页面找出些新鲜之处(大概自个儿创办),然后再写一个新规则去操作。

据悉父组件来修改组件

CSS

.widget { background: yellow; border: 1px solid black; color: black;
width: 50%; } #sidebar .widget { width: 200px; } body.homepage .widget
{ background: white; }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
.widget {  
  background: yellow;  
  border: 1px solid black;  
  color: black;  
  width: 50%;  
}  
 
#sidebar .widget {  
  width: 200px;  
}  
 
body.homepage .widget {  
  background: white;  
}

初看,那相对是段无害的代码,但让咱们来看看它是否达标了大家所设置的目标。

首先,例子中的widget是不可预感的。当那些小部件出现在页面两侧恐怕主页面时,开发人员期望它们以某种特定的法子显示出来,且又不失特色。此外,它也是不行重用或不足扩充的。

【亚洲必赢官网】面向对象CSS的介绍。其它,它也比较难保险。一旦那些widget必要又一次设计,那么您不得不修改其他多少个CSS样式。想象一下,假使这段代码是拔取任何语言编写的,它基本就是一个类定义,然后在代码的另一部分应用该类定义并做出增添。那直接违背了软件开发的盛开/闭合(open/close)原则。

软件实体(类,模块,函数等)应对扩展开放,对修改闭合。

超负荷复杂的采用器

偶尔,会稍为作品介绍CSS接纳器对全体网站的显示起着那多少个关键的效益,并且阐明无需使用其余类选用器或然ID采用器。

但伴随着越深刻的开销,我越会远离那种复杂的选用器。一个抉择器越复杂,与HTML就越耦合。依靠HTML标签和组合器能够维持HTML代码干干净净,但却让CSS尤其毛重和芜杂。

XHTML

#main-nav ul li ul li div { } #content article h1:first-child { }
#sidebar > div > h3 + p { }

1
2
3
#main-nav ul li ul li div { }  
#content article h1:first-child { }  
#sidebar > div > h3 + p { }

对上边代码进行简要的知情。第二个大概是对下拉菜单举办样式化;第三个想表达小说的主标题应该与其余页面的H1成分分化;最终一个代表在第一段的侧面栏区域增进一些格外的空中。

设若这些HTML是永恒不变的,那就无可说之处,但那根本毫无现实。过于复杂的接纳器会令人印象长远,它可以让HTML摆脱掉表面上的复杂性,但对于达成出彩的CSS架构目标却并非用处。

上面提到的事例都以不富有可预测性、可选拔、可增添和可爱慕那四大特色的。例如第一个拔取器(下来菜单)例子,假设一个外观相当相似的下拉列表须求用在不一样的页面上,并且#main-nav并不属于内部因素,那么你是还是不是须求重新规划?假使开发者想要修改首个例证里div里面有些符号,那么一切规则都会被打破。

过于通用的类名

当创制可拔取的规划组件时,在组件的类接纳器中覆盖附件的子元素是很普遍的场景。例如:

XHTML

<div class=”widget”> <h3 class=”title”>…</h3>
<div class=”contents”> Lorem ipsum dolor sit amet, consectetur
adipiscing elit. In condimentum justo et est dapibus sit amet euismod
ligula ornare. Vivamus elementum accumsan dignissim. <button
class=”action”>Click Me!</button> </div> </div>

1
2
3
4
5
6
7
8
9
<div class="widget">  
  <h3 class="title">…</h3>  
  <div class="contents">  
    Lorem ipsum dolor sit amet, consectetur adipiscing elit.  
    In condimentum justo et est dapibus sit amet euismod ligula ornare.  
    Vivamus elementum accumsan dignissim.  
    <button class="action">Click Me!</button>  
  </div>  
</div>

CSS

.widget {} .widget .title {} .widget .contents {} .widget .action {}

1
2
3
4
.widget {}  
.widget .title {}  
.widget .contents {}  
.widget .action {}

像.title、.contents、.action这几个子元素类选拔器可以被平安地拓展体制命名,无需担心这个样式会蔓延到拥有相同类名的别样因素中。那是言之凿凿的。但它并不曾挡住相同样式类名称会蔓延到那么些组件上。

在一部分大型项目上,像.title这样的称呼很有恐怕会被用在其它一个页面大概本人。固然这样的情形时有暴发,那么所有标题部分鲜明会和预期的不雷同。

过分通用的类选取器名称会招致层见迭出不得预测的CSS样式发生。

一个平整做太多事

偶然,你要在网站的左上角区域做一个20pixels的可视化组件。

CSS

.widget { position: absolute; top: 20px; left: 20px; background-color:
red; font-size: 1.5em; text-transform: uppercase; }

1
2
3
4
5
6
7
8
.widget {  
  position: absolute;  
  top: 20px;  
  left: 20px;  
  background-color: red;  
  font-size: 1.5em;  
  text-transform: uppercase;  
}

上边,你须求在网站的任何区域拔取该零件,那么地点的那一个代码鲜明是不对的,不可重用的。

题材的重大是你让.widget那一个接纳器做的事务太多,不仅对该器件的职位举办了确定,还对它的外观和感觉方面展开了体制。外观和感到可以通用,而地方是不得以的。有时候,把它们构成起来使用反而会大降价扣。

即使这几个看起来并无害处,对一部分缺少经验的CSS程序员来说,复制和粘贴已经改为一种习惯。若是一个新团体须求一个特定组件,比如.infobox,他们会尝试接纳这一个类接纳器。但借使该音信框没有听从期望的那么,在每种必要的地方正确展现出来。那时,你觉得他俩会怎么办?以自身的经历来看,他们会打破可接纳这一平整,相反,他们会简单地把那一个代码复制粘贴到各样须要的地点。做些不要求的再一次工作。

3.原因

上边列举的那些健康错误实践都有一个相似性,CSS样式承担过多。

对这么的传教您会感觉意外,毕竟,它是一个样式表,难道不应当担负半数以上(假诺不是全部)的样式吗?那不正是大家想要的啊?

真的。不过普通来讲,事情并从未那么简单。内容与表现(presentation)相分离是件好事,但CSS从HTML中单独出来并不意味内容也要求从突显中分离。换句话说,假使CSS请求长远剖析HTML架构,那么从HTML中分拆所有的体现代码并不一定会完结所有的对象。

除此以外,HTML很少会只包含内容,也代表完全框架。平时,架构是会含有container成分,允许CSS隔离一些永恒成分。即使没有表象类(presentational
classes),也能混合HTML清晰地把内容彰显出来。

自家深信,鉴于近来的HTML和CSS状态,把HTML和CSS明智地组成起来,当做表现层是可怜需求的。而经过沙盘和部分模板(partials)也得以把内容层开展分离。

 

4.搞定方案。

倘使把HTML和CSS结合起来,作为一个Web应用程序的显示层,那么它们需求运用一些措施更好地力促非凡CSS架构的多变。

最好的艺术是CSS中尽大概少的带有HTML架构。CSS则是应有定义成分的视觉效果,无论该视觉成分在哪儿。假诺有部分特定的零部件须要在区其余场所显示不相同的效益,那么应该授予不一样的称谓。例如,CSS通过.button类选用器定义了一个按钮组件。假使HTML想要一个一定的要素看起来像按钮,那么就可以使用.button。假诺那里有特殊须要,那里的按钮与其他的悬殊(有恐怕更大和宽些),那么CSS要求定义一个新的类,HTML可以采纳新的类来予以该因素新的视觉效果。

CSS赋予成分的外在特征,HTML在页面上开展调用。更少的CSS能被更加多的HTML架构调用是最好的。

标准地在HTML中阐明成分不仅可以清晰表明设计意图,其他开发者也得以清晰地查看标记并且知道成分将突显的规范。即使没有那种实践,它很难区分一个要素的外观设置是有意或下意识的,那样很简单导致集体混乱。

在标记中填入多量的类(classes)是种常见缺陷,那样做往往需求开支额外的生机。一个CSS样式可以给一个一定组件引用上千次。那么,为了在标记里面举办显示注解,就真的值得去重新编写那样的类吗?

虽说那种担心是有效的,但它或然会时有暴发误导。言下之意就是无论你在CSS中运用一个父拔取器依旧亲手编写上千个Class,那里都会有点额外的抉择。在Rails可能其余框架里查看同级别抽象很大程度上得以在HTML中保险很好的视觉外观,并且无需在类中几次又五各处编写相同的类。

 

5.顶级实践。

针对地点的各个错误,我举办了很好地计算,并且依据我经验提议了部分提出,希望它们能帮衬你更好地贯彻突出的CSS架构目的。

专注

管教采用器对有些要素不开展无关样式的最好办法是不给它们机会。例如像#main-nav
ul li ul li
div那样的采用器大概很简单地选择于不想要的成分上。另一方面,像.subnav那样的接纳器就不会给它们别样机会。把类拔取器间接行使于你想要的要素上是最好的主意,并且能够保持元素的可预测性。

CSS

/* Grenade */ #main-nav ul li ul { } /* Sniper Rifle */ .subnav { }

1
2
3
4
5
/* Grenade */
#main-nav ul li ul { }  
 
/* Sniper Rifle */
.subnav { }

模块化

一个团社团结构可以的组件层能够辅助缓解HTML架构与CSS那种松散的耦合性。其余,CSS组件自个儿应当是模块化的。组件应该清楚什么举办体制和更好地劳作,不过关于布局、定位以及它们与周围成分的涉嫌不该做太多的要是。

相似而言,CSS要定义的应当是组件的外观,而不是布局仍然地点。同样在动用background、color和font那么些属性时也要坚守原则使用。

布局和职分应该由一个单独的布局类依旧独立的容器成分构成(请记住,有效地把内容与呈现举办分离其实就是把内容与容器举行分离)。

给类举行命名空间

咱俩早就检查出为啥父选取器无法在封闭和避免交叉样式污染方面发挥100%的成效。而一个更好的缓解方案就是在类上应用命名空间。借使一个因素是可视化组件的一员,那么该因素的逐个子成分都应有利用基于命名空间的组件。

CSS

/* High risk of style cross-contamination */ .widget { } .widget
.title { } /* Low risk of style cross-contamination */ .widget { }
.widget-title { }

1
2
3
4
5
6
7
/* High risk of style cross-contamination */
.widget { }  
.widget .title { }  
 
/* Low risk of style cross-contamination */
.widget { }  
.widget-title { }

给类举行命名空间可以维持组件独立性和模块化。它可以把现有类争论降至最小并且收缩子成分的片段特殊须要。

创办修饰符类来扩展组件

当一个现有组件须求在一个一定的语境中有所差异时,可以创立一个修饰符类(modifier
class)来扩大它。

CSS

/* Bad */ .widget { } #sidebar .widget { } /* Good */ .widget { }
.widget-sidebar { }

1
2
3
4
5
6
7
/* Bad */
.widget { }  
#sidebar .widget { }  
 
/* Good */
.widget { }  
.widget-sidebar { }

正如我辈来看的,基于父成分的老毛病对组件进行修改,须求反复:一个修饰符类可以在别的地点选取。基于地方的掩盖只好被用在一个一定的地点,修饰符类也足以根据需求被一再使用。鲜明,修饰符类是相符HTML开发者须求的。

把CSS协会成逻辑结构

Jonathan
Snook在其充足精粹的《SMACSS》书中涉嫌,CSS可以被分成多个不等的类:基础(base)、布局(layout)、模块(modules)和状态(state)。基础包含了复位原则和要素缺省值;布局是对站点范围内的要素进行定位以及像网格系统那样作为一种通用布局帮手;模块即是可拔取的视觉成分;状态即指样式,可以透过JavaScript举办开启或关闭。

组件是一个单身的视觉成分。模板在一面则是构建块。模板很少独自站在团结的角度去讲述视觉和感到,相反,它们是纯粹的、可选取的形式,可以置身一块儿形成组件。

为了提供更详尽的例子,一个零部件大概就是一个形式对话框。该方式恐怕在头顶包括渐变的网站签名、恐怕在四周会有黑影、在右上角会有关闭按钮、地方固定在笔直与水平线中间。这两个情势只怕被网站再次多次选用,所以在每一回使用的时候,你都很少会想到重新编码与设计。这个有着的模版即形成了一个模块组件。

因体制微风骨使用类

有过大型网站建设的人想必有个那样的经历,一个拥有类的HTML成分可能完全不亮堂其用途。你想删除它,可是又畏首畏尾,因为它的功效你大概还未察觉到。一旦那样的业务两遍又三次暴发的时候,随着时间的延迟,项目少将会有进一步多如此的类,只因为团队成员都不敢删除。

在Web前端开发中,类承担了太多的权利,由此才会爆发这么的标题。样式化HTML元素、扮演着JavaScript
hook角色、作用检测、自动化测试等。当那样多应用程序在应用类时,让您从HTML中删去它们将会变的要命不便。

但是,使用部分老谋深算的预约(惯例)即可完全防止那种难点。当在HTML中观望一个类时,你应该马上驾驭它的目标。我指出在面前使用前缀,例如用于JavaScript的在面前加.js,表示Modernizr
classes可以在前边加.supports,没有加前缀的即用于表示样式。

如此来发现未使用的类和从HTML中移除它们将会变得极度简单。你甚至足以自行完结这几个进度,在JavaScript中通过交叉引用HTML中的document.styleSheets对象。如果在document.styleSheets中并未意识此类,即可安全移除。

相似的话,最佳做法是把内容与示范相分离,别的把效果分别开来也一致至关主要。使用样式类像JavaScript
hook在某种程度上得以强化CSS与JavaScript之间的耦合,但在不打破作用性的前提下很难只怕根本不容许改动外观。

有逻辑的命名类

大多数写CSS的人爱不释手使用连字符来分隔命名词,但连字符并不足以区分差异种类之间的类。

Nicolas
Gallagher如今针对境遇的标题写了一个化解方案,并且取得了伟大的打响(略有改动),为了印证命名约定,可以设想以下格式:

CSS

/* A component */ .button-group { } /* A component modifier
(modifying .button) */ .button-primary { } /* A component sub-object
(lives within .button) */ .button-icon { } /* Is this a component
class or a layout class? */ .header { }

1
2
3
4
5
6
7
8
9
10
11
/* A component */
.button-group { }  
 
/* A component modifier (modifying .button) */
.button-primary { }  
 
/* A component sub-object (lives within .button) */
.button-icon { }  
 
/* Is this a component class or a layout class? */
.header { }

从上述类中得以窥见其很难正确区分类型规则。那不只会思疑,而且连自动测试CSS和HTML也变的很难。一个结构化的命名约定应该是初看就可以领略其类名与其它类之间的涉嫌,并且知道它出现在HTML中的地方——义务名尤其简约和简单测试。

CSS

/* Templates Rules (using Sass placeholders) */ %template-name
%template-name–modifier-name %template-name__sub-object
%template-name__sub-object–modifier-name /* Component Rules */
.component-name .component-name–modifier-name
.component-name__sub-object
.component-name__sub-object–modifier-name /* Layout Rules */
.l-layout-method .grid /* State Rules */ .is-state-type /* Non-styled
JavaScript Hooks */ .js-action-name

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
/* Templates Rules (using Sass placeholders) */
%template-name  
 
%template-name–modifier-name  
 
%template-name__sub-object  
 
%template-name__sub-object–modifier-name  
 
 
/* Component Rules */
.component-name  
.component-name–modifier-name  
.component-name__sub-object  
.component-name__sub-object–modifier-name  
 
/* Layout Rules */
.l-layout-method  
.grid  
 
/* State Rules */
.is-state-type  
 
/* Non-styled JavaScript Hooks */
.js-action-name

重做第三个例子:

CSS

/* A component */ .button-group { } /* A component modifier
(modifying .button) */ .button–primary { } /* A component sub-object
(lives within .button) */ .button__icon { } /* A layout class */
.l-header { }

1
2
3
4
5
6
7
8
9
10
11
/* A component */
.button-group { }  
 
/* A component modifier (modifying .button) */
.button–primary { }  
 
/* A component sub-object (lives within .button) */
.button__icon { }  
 
/* A layout class */
.l-header { }

 

6.工具

维护一个急速且社团卓绝的CSS架构是分外困难的,尤其是在巨型公司中。上面向大家推荐六款很好的工具来帮您管理网站CSS架构。

CSS Preprocessor

CSS预处理器选择PHP5编写,有预处理器的宽广功用,可以帮您快捷编写CSS。其余有些号称“功用”的预处理器实际上并不会对CSS架构爆发非凡成效。下边我提供一个列表,在应用时必定要防止:

  • 切勿纯粹为了协会代码来嵌套规则。只有当输出你真的想要的CSS时才方可。
  • 在无需传递参数的时候切勿使用mixin,不带参数的mixin更合乎当作模板,易扩大。
  • 切勿在选用器上采纳@extend,它不是个十足的类。从安插性角度来看是毫无意义的,它会暴涨编译过的CSS。
  • 在运用组件修饰符规则时,切勿使用@extend UI组件,那样会失掉基础链。

@extend和%placeholder是预处理器里面特别好的三个功效。它们得以帮你轻松管理CSS抽象并且无需添加bloat和多量的基类到CSS和HTML里,否则将会很难管理。

当您首先使用@extend时,常会与修饰符类一起使用,例如:

CSS

.button { /* button styles */ } /* Bad */ .button–primary { @extend
.button; /* modification styles */ }

1
2
3
4
5
6
7
8
9
.button {  
  /* button styles */
}  
 
/* Bad */
.button–primary {  
  @extend .button;  
  /* modification styles */
}

如此做会让你在HTML中错过继承链。很难使用JavaScript拔取具有的按钮实例。

用作一般规则,很少去增加UI组件可能在领悟类型后做些什么。那是分别模板和组件的一种艺术,模板无需参预到应用程序的逻辑,并且可以运用预处理器举行安全伸张。

上边是一个引用下边的形式例子:

CSS

.modal { @extend %dialog; @extend %drop-shadow; @extend
%statically-centered; /* other modal styles */ } .modal__close {
@extend %dialog__close; /* other close button styles */ }
.modal__header { @extend %background-gradient; /* other modal header
styles */ }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
.modal {  
  @extend %dialog;  
  @extend %drop-shadow;  
  @extend %statically-centered;  
  /* other modal styles */
}  
 
.modal__close {  
  @extend %dialog__close;  
  /* other close button styles */
}  
 
.modal__header {  
  @extend %background-gradient;  
  /* other modal header styles */
}

CSS Lint

CSS Lint是由Nicole
Sullivan和Nicholas
Zakas编写的一款代码品质检测工具,协理CSS开发人员写出更好的代码。他们的网站上是那样介绍CSS
Lint的:

CSS
Lint是一个用来帮你找出CSS代码中难点的工具,它可做为主的语法检查以及采纳一套预设的条条框框来检查代码中的难点,规则是足以扩展的。

使用CSS Lint建议:

  • 1.永不在增选器中出现ID。
  • 2.在多一些规则中,不要使用非语义(non-semantic)类型选取器,例如DIV、SPAN等。
  • 3.在一个摘取器中使用的连接符(combinator)不要超越2个。
  • 4.任何类名都休想以“js-”开始。
  • 5.要是在非“I-”前缀规则里时常采纳布局和稳定应予以警示
  • 6.如若一个类定义后被再一次定义成子类,也应给予警示。

 

总结

CSS不仅仅是视觉设计,也毫无因为你编写CSS就不管抛出编程的一级实践。像OOP、DRY、打开/闭合、与内容分别等那些规则应有采用到CSS里面。无论你怎么社团代码,都要有限援救艺术真的扶持到您,并且使你的开支尤其简单和可有限支撑的。

赞 3 收藏
评论

亚洲必赢官网 2

正文是对  文的翻译

本资源由 伯乐在线 –
凝枫 整理

诙谐的是,大家一般不那样评判其余语言。一个Rails开发者不会因为她写的代码规范就认为她是一个好的开发者。因为那是最宗旨的。当然它必须是满意规范,除此以外还要考虑任什么地方方:代码是还是不是有可读性?他是还是不是简单修改恐怕拓展?他是还是不是跟程序的任何部分解耦合?他是否可以扩充?

 

您听过“内容为王”那句话吗?身为一个web开发者,干着平常跟内容和创意打交道的行事,你应有深有体会。那句话总是被提及,但却是真理——访客就是这样被抓住来的。

当评估代码其余部分时那些标题是理所当然的,所以css也不应有例外。近期的web应用程序比过去大过多,一个考虑不周的css架构足以阻碍web程序的上进。是时候像评价应用程序其余部分雷同的主意评价css。他不是一个过后的发生的想法或不仅仅是设计师的难点。

对此许多web开发者,认为擅长css就是能把一个视觉设计图用代码完美的复现出来。你不使用table,而且很自信,自身能够行使尽只怕少的图样。借使您真正很棒,就会采纳新型最了不起的技艺例如Media
Queries,Ttransform和Transition。一个好的css开发人士确实是会这个,可是很少在评估一个人的水日常会将css作为完全独立的另一方面被提及。

只是,站在web开发者的见解,有些人却反驳说“速度才是王道”。久而久之,我也站在了这一派。近期,很多名牌的前端工程师通过有些不错网站的性能测试,对于怎么着革新用户体验这一标题提出了他们的提议。

突出的CSS全局架构

在css社区,已毕最佳实践的一个通用共识是十分难的。从纯粹Hacker
News讨论和开发者反映到css
lint判定CSS代码是还是不是规范。很醒目,许几个人都不明了,甚至css作者都觉得本人的代码是行得通仍然不可行

之所以不是制订自身要好设定的超级实践理由,我以为大家应有首先定义我们的目标。如果我们能达标一致的靶子,大家就能分辨不佳的css代码,不是因为他打破了大家对此咋做的css代码的设想,而是因为他确实阻碍了css的开销进程。

我认为好的css架构目的不应有分别所有好的软件开发目标。我想要我的css是可预言的、可接纳的、可爱抚的和可伸张的

诙谐的是,大家普通不这样裁判其他语言。一个Rails开发者不会因为他写的代码规范就认为她是一个好的开发者。因为那是最主题的。当然它必须是满意规范,除此以外还要考虑任什么地方方:代码是还是不是有可读性?他是还是不是简单修改恐怕拓展?他是或不是跟程序的其它一些解耦合?他是否可以扩充?

偏偏的是,太多的开发者(好心地)把重点放在JavaScript及别的地方的性质上,CSS就像是不怎么不受爱慕。

CSS的可预感

可预知性的css意味着你的规则行为正如你所想,当您添加或更新一条规则,他不应有影响你网站上不想要受影响的有些。对于一个微型网站很少的修改,并不是很重大。不过对于一个富有几十或几百个页面的大型网站,可预言性的css就是一种必需。

当评估代码其他一些时这几个标题是理所当然的,所以css也不应有例外。方今的web应用程序比往常大过多,一个考虑不周的css架构足以阻碍web程序的上进。是时候像评价应用程序其余一些同样的方法评价css。他不是一个以往的暴发的想法或不仅仅是设计师的标题。

从而在本篇中,我将缓解CSS这一被忽视的题材,引入面向对象的CSS这一概念,以及它什么接济大家加强网页的习性和可维护性。

CSS的可复用性

Css规范应当是十足抽象的和耦合的,那样你可以根据现有代码部分高速创设出新的组件,而不须要再次编辑你早就处理过的样式和题材。

大好的CSS全局架构

在css社区,达成最佳实践的一个通用共识是足够难的。从纯粹Hacker
News讨论和开发者反映到css
lint判定CSS代码是还是不是规范。很显眼,许多人都不明了,甚至css小编都觉着自个儿的代码是实用依旧不可行

故此不是制定本身本人设定的特等实践理由,我觉得大家相应率先定义我们的对象。若是大家能达到一致的目标,大家就能分辨不好的css代码,不是因为他打破了大家对于什么是好的css代码的考虑,而是因为他着实阻碍了css的付出进程。

自个儿认为好的css架构指标不该分别所有好的软件开发目的。我想要我的css是可预感的、可拔取的、可爱抚的和可增添的

面向对象CSS的规律

跟其他面向对象编程方法类似,面向对象CSS的目标是砥砺代码重用,从而让体制表读取更迅捷、更有功能,易于更新和尊崇。

亚洲必赢官网 3

如面向对象CSS GitHub
维基页面所说,
有三个重点条件。

CSS的可维护性

当你的网站要求丰硕、更新或重新布署有些新的零件和特性,这样做不应该重构现有的css。给页面添加x组件不应有破坏已经存在的组件Y。

CSS的可预感

可预言性的css意味着你的条条框框行事正如你所想,当您添加或更新一条规则,他不应该影响您网站上不想要受影响的片段。对于一个小型网站很少的改动,并不是很主要。可是对于一个具备几十或几百个页面的特大型网站,可预言性的css就是一种必需。

结构与皮肤分离

对此一个有体制的网页来说,大概各类成分都持有不雷同的视觉特征(也称“皮肤”),而这个皮肤在不一致内容环境下却有双重。回顾一下网站品牌识别成分(如颜色、细微的渐变以及可知边框等等)就清楚了。另一方面,还有些平时不可知的风味(如“结构”)也是一直在重复使用。

当这一个不同的脾气被架空成class模块,它们也就有了录取的或然,可以被运用于其余一个要素,效果等同。让大家来对待下改前改后的代码,你就能掌握本人所说的情趣了。

在行使面向对象CSS原则前,你看来的CSS几乎都长这么:

#button { width: 200px; height: 50px; padding: 10px; border: solid 1px
#ccc; background: linear-gradient(#ccc, #222); box-shadow: rgba(0, 0,
0, .5) 2px 2px 5px; } #box { width: 400px; overflow: hidden; border:
solid 1px #ccc; background: linear-gradient(#ccc, #222); box-shadow:
rgba(0, 0, 0, .5) 2px 2px 5px; } #widget { width: 500px; min-height:
200px; overflow: auto; border: solid 1px #ccc; background:
linear-gradient(#ccc, #222); box-shadow: rgba(0, 0, 0, .5) 2px 2px
5px; }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#button {
  width: 200px;
  height: 50px;
  padding: 10px;
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}
 
#box {
  width: 400px;
  overflow: hidden;
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}
 
#widget {
  width: 500px;
  min-height: 200px;
  overflow: auto;
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

下边那3个因素是一点一滴两样的,都以运用的不可重用的ID选拔器,但它们的样式有成百上千是一致的。样式共有的图景日常出现在品牌设计或统一性设计中。
稍许整理一下,大家得以提炼出共有的样式,修改后CSS就会成为那样:

.button { width: 200px; height: 50px; } .box { width: 400px; overflow:
hidden; } .widget { width: 500px; min-height: 200px; overflow: auto; }
.skin { border: solid 1px #ccc; background: linear-gradient(#ccc,
#222); box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px; }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
.button {
  width: 200px;
  height: 50px;
}
 
.box {
  width: 400px;
  overflow: hidden;
}
 
.widget {
  width: 500px;
  min-height: 200px;
  overflow: auto;
}
 
.skin {
  border: solid 1px #ccc;
  background: linear-gradient(#ccc, #222);
  box-shadow: rgba(0, 0, 0, .5) 2px 2px 5px;
}

诸如此类,所有的要素都以用class接纳器,共有样式被联合为一个可选取的“skin”中,清除了不须求的双重。我们只须要把“skin”赋给所有需求的成分,则都会显现同样的体裁,最后效果跟前一个案例一样,当然,后一种格局用更少、可选取的代码量缓解了难点。

CSS的可伸张性

乘势你的网站的框框和复杂程度的增强,它往往须要更加多的开发人士来维护。可扩张的css意味着可以轻松的由有一个人或一个巨型的技能集团管理你的网
站。他也代表你的网站的css架构不难领会不须求很陡的求学曲线,仅仅因为你是未来唯一接触css的开发人员,不过并不表示永远是那种情状。

CSS的可复用性

Css规范应当是十足抽象的和耦合的,那样你能够依照现有代码部分高速创设出新的组件,而不须要再次编辑你早就处理过的样式和题材。

容器与内容分别

其次个条件则是将内容跟它们的器皿分离。为了解说那条的最主要,请看之下案例:

#sidebar h3 { font-family: Arial, Helvetica, sans-serif; font-size:
.8em; line-height: 1; color: #777; text-shadow: rgba(0, 0, 0, .3) 3px
3px 6px; }

1
2
3
4
5
6
7
#sidebar h3 {
  font-family: Arial, Helvetica, sans-serif;
  font-size: .8em;
  line-height: 1;
  color: #777;
  text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px;
}

这个样式会被应用于#sidebar的具有子级h3要素,但要是要把它用在页脚的h3上,并赋予分裂的字体尺寸和文书阴影的话,怎么做?
我们会那样做:

#sidebar h3, #footer h3 { font-family: Arial, Helvetica, sans-serif;
font-size: 2em; line-height: 1; color: #777; text-shadow: rgba(0, 0, 0,
.3) 3px 3px 6px; } #footer h3 { font-size: 1.5em; text-shadow: rgba(0,
0, 0, .3) 2px 2px 4px; }

1
2
3
4
5
6
7
8
9
10
11
12
#sidebar h3, #footer h3 {
  font-family: Arial, Helvetica, sans-serif;
  font-size: 2em;
  line-height: 1;
  color: #777;
  text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px;
}
 
#footer h3 {
  font-size: 1.5em;
  text-shadow: rgba(0, 0, 0, .3) 2px 2px 4px;
}

要么,景况有只怕会更糟:

#sidebar h3 { font-family: Arial, Helvetica, sans-serif; font-size:
2em; line-height: 1; color: #777; text-shadow: rgba(0, 0, 0, .3) 3px
3px 6px; } /* 其余样式…. */ #footer h3 { font-family: Arial,
Helvetica, sans-serif; font-size: 1.5em; line-height: 1; color: #777;
text-shadow: rgba(0, 0, 0, .3) 2px 2px 4px; }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#sidebar h3 {
  font-family: Arial, Helvetica, sans-serif;
  font-size: 2em;
  line-height: 1;
  color: #777;
  text-shadow: rgba(0, 0, 0, .3) 3px 3px 6px;
}
 
/* 其他样式…. */
 
#footer h3 {
  font-family: Arial, Helvetica, sans-serif;
  font-size: 1.5em;
  line-height: 1;
  color: #777;
  text-shadow: rgba(0, 0, 0, .3) 2px 2px 4px;
}

我们没要求地复制了体制,并且可能根本没察觉到这点(只怕忽视)。而面向对象CSS,更鼓励人们在编程前先行想好不一样因素间的共同点,把相同特征分离成模块或对象,以便在何地都足以选用。
地点的案例中,样式都以运用持续选用器申明,无法重用,因为它们都被局限在一个一定的容器内(无论是sidebar还是footer)。
当大家遵循面向对象的规律,使用class模块搭建的话,我们可以有限援助样式不会凭借于任何容器成分。那也就表示,无论结构及上下文是哪些的,它可以在该文档中自由重用

广大的坏习惯

在大家探寻通往好的css架构的对象道路以前,我以为审视常见的不得了习惯可以有助我们更好的完结目的。往往只有因此不断的重复出错,大家才能伊始走上科学的征途。

上边的事例都以自己一度写过的持有通用性的代码,固然完毕了效果,不过各种都曾是一个令人喉咙痛的政工。就算我有脍炙人口的意愿,并许诺本次会尤其,可是那些方式总是让我陷入麻烦中。

CSS的可维护性

当您的网站要求添加、更新或重新安顿有的新的组件和脾气,那样做不该重构现有的css。给页面添加x组件不应当破坏已经存在的组件Y。

忠实案例

为了更好地表明面向对象CSS的使用办法,接下去本人将以自身的网站最新修改版为例子来表明。当本人编码完内部header时,我发现到,内部header的宗旨结构体制可以被选定到本页其余因素上。

最开始规划header的时候的代码是那样的:

.header-inside { width: 980px; height: 260px; padding: 20px; margin: 0
auto; position: relative; overflow: hidden; }

1
2
3
4
5
6
7
8
.header-inside {
  width: 980px;
  height: 260px;
  padding: 20px;
  margin: 0 auto;
  position: relative;
  overflow: hidden;
}

此处列出的有的样式是.header-inside要素特有的,但别的部分可以被波及模块中,以便重用。由此,我可以提炼结构型样式,放到重用的class中:

.globalwidth { width: 980px; margin: 0 auto; position: relative;
padding-left: 20px; padding-right: 20px; overflow: hidden; }
.header-inside { padding-top: 20px; padding-bottom: 20px; height: 260px;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
.globalwidth {
  width: 980px;
  margin: 0 auto;
  position: relative;
  padding-left: 20px;
  padding-right: 20px;
  overflow: hidden;
}
 
.header-inside {
  padding-top: 20px;
  padding-bottom: 20px;
  height: 260px;
}

.globalwidth的体裁包蕴以下多少个个性:

  • 固定宽度
  • 异地距自动居中
  • 子成分相对固化
  • 反正内边距为20px
  • 溢出隐藏,清除浮动

现行,大家只需简单地附着该class,无需多写一行代码,就可以在任意你要的要素上使用这个样式了。

在本身的站点中,我把基础内容和中间header要素重用了协会体制。根据本人的设计稿,那几个样式也足以运用到headercontent中水平导航成分中,亦大概任意符合“固定宽度”、“页面居中”的因素上。

加了globalwidth体制后,HTML就改为了那般:

多少人大概会认为,那种“提取样式”的方法会把HTML搞得一无可取,并且跟把标记和出示效果分开的初衷是违背的。
但万一无视那一个对HTML影响的争议,单正视用这3个成分的功能,没人能不能认那样的艺术的确能让开发者更便于追踪、修改共有的体裁

据悉父类修改组件

差点所有的网站都会一个特定的视觉成分看起来跟每一个成分完全平等,而且当碰着这种一次性格形,大概每种新的css开发人员(甚至是有经历的开发人员)依照同等的办法处理它。你找出这几个一定的父成分(或是你创设一个),而且你为他们写一个崭新的平整处理他。

.widget {
  background: yellow;
  border: 1px solid black;
  color: black;
  width: 50%;
}

#sidebar .widget {
  width: 200px;
}

body.homepage .widget {
  background: white;
}

开局这看起来或许是很出色的代码,可是让大家精心看,那一个都以为已毕目的而写。

率先,那个事例中的小结构没有可预言性。成立了几许个如此的布局的开发者希望她是特定的外观,然则当把他用在侧栏或是主页,他将看起来不一致,就算结构是一点一滴等同。

他的复用性扩充性也不是很好。当把她用在主页或是被要求用在任何页面会发生什么?不得不添加新的平整。

终极,他不是很不难有限支撑,因为如果这一个协会重新设计了,那么他必须修改css中的好多少个地点,不符合前面提议的CSS架构的渴求,须求一个接一个的来修改。

想象一下,假设那种代码被用在其他语言。你当然用一个类定义,然后在代码的别样一些引入那几个类定义,为了其他的用处改变她,那平素违反了软件开发进度中开辟/关闭的规则。

Software entities (classes, modules, functions, etc.) should be open
for extension, but closed for modification.

在本文的末端,大家将看看怎么样不借助父拔取器修改组件。

CSS的可增加性

乘机你的网站的层面和复杂程度的增高,它往往要求越多的开发人士来保护。可增加的css意味着可以轻松的由有一个人或一个巨型的技巧团队管理你的网站。他也象征你的网站的css架构不难控制不须要很陡的就学曲线,仅仅因为您是现行唯一接触css的开发人士,不过并不代表永远是那种情况。

传媒对象

Nicole
Sullivan是面向对象CSS的开路者之一,她编纂了一个叫传媒对象的可选拔模块,她说,那可以协理省下数百行的代码。

亚洲必赢官网 4

传媒对象是能见识到面向对象CSS威力的极佳案例,它同意在它左侧内置一个肆意内容尺寸的媒体对象。即便一些用上的体制(甚至媒体成分本人)或然会怀有变化,但媒体对象即使被予以了着力共有样式,就能避免不需要的重新。

超负荷复杂的选用器

突发性一篇文章使得在网络里显示css选取器的能力,并申明你可以给任何网站定义样式而不须求选用其余类名或是id。

即使技术上是可行的,随着开发css的一遍遍地怀恋,我进一步远离复杂拔取器。选拔器越复杂,他跟html的组成越紧凑。依赖于html标签和涉嫌拔取器尽管使您的html看起来很绝望,然而它使你的css很糟糕。

#main-nav ul li ul li div { }
#content article h1:first-child { }
#sidebar > div > h3 + p { }

享有以上例子就是逻辑。第二个只怕是一个下拉菜单样式,首个是说小说的主要标题跟其他h1成分看起来不一样,最终一个例证好像是给侧栏部分的首先个段落添加一些非常的距离。

假使那些html永远不会变动,那几个理由可能可以看成他的一个亮点,但是如若html永远不会改变是多么不现实的工作。过于复杂的选拔器可以令人映像浓密,他们可以使html摆脱所有表现的钩子,可是她们却很少能扶助大家落成完美的css结构的靶子。

上边的例子并不是兼具的都足以复用。因为选取器指向一个分外越发的标签地点,怎么可以让另一个所有差距结构的组件重用那么些体制呢?以第四个例证(下
拉菜单)作为例子,假若在任何页面必要加上一个看上去好像的下去菜单,然而她里头没有#main-nav的因素,你要做哪些?你将只好再次成立一整套样
式。

假设html结构须要转移那些选取器也是不可预测的。想象一下一个开发人士想要把第两个例子中的div改成html5的section标签,那么整个规则就磨损了。

终极,因为这几个选拔器只有当html保持不变才能办事,所以他们的定义是不足维护的也是不足扩张的。

在大型的应用程序中您不得不做出权衡和息争。复杂采用器的脆弱性是在保护你的html干净命名中起到很微小的意义。

周边的坏习惯

在我们摸索通往好的css架构的靶子道路以前,我认为审视常见的倒霉习惯可以有助大家更好的落成目的。往往只有因此持续的重复出错,我们才能初步走上科学的道路。

上边的例证都以自个儿一度写过的有着通用性的代码,尽管达成了效益,可是各种都曾是一个令人头痛的业务。即使我有上佳的意愿,并答应这一次会极度,可是那些情势总是让自家陷入麻烦中。

面向对象CSS的优势

上文里本人已经陆续提及了面向对象CSS的长处,接下去本人将实行讲:

超负荷通用的类名

当创造可选拔的统筹组件时,一种很宽泛的气象,就是用组件类名的内部包蕴组件子成分的类名表示范围,例如

<div class="widget">
  <h3 class="title">...</h3>
  <div class="contents">
    Lorem ipsum dolor sit amet, consectetur adipiscing elit.
    In condimentum justo et est dapibus sit amet euismod ligula ornare.
    Vivamus elementum accumsan dignissim.
    <button class="action">Click Me!</button>
  </div>
</div>

.widget {}
.widget .title {}
.widget .contents {}
.widget .action {}

那么些想法是.title, .contents, 和
.action类名的子成分定义安全的体裁,不用担心会影响其余那个具有同样类名的成分样式。那是真的,可是那并无法防止其余同类名的体裁会潜移默化那个组件的样式。

在一个大型项目很只怕有个像.title的类名被用到另一个条件中或甚至他我,即使那种意况爆发的话,那么些widget’s
title会突然看起来跟预期的不相同。

超负荷通用的类名会招致卓殊不足预见的css。

据悉父类修改组件

差不多拥有的网站都会一个特定的视觉成分看起来跟每一种成分完全等同,而且当遭受那种四次性意况,大概各种新的css开发人士(甚至是有经历的开发人士)根据同样的主意处理它。你找出这么些一定的父成分(或是你创制一个),而且你为她们写一个崭新的平整处理他。

.widget {
  background: yellow;
  border: 1px solid black;
  color: black;
  width: 50%;
}

#sidebar .widget {
  width: 200px;
}

body.homepage .widget {
  background: white;
}

发端那看起来只怕是很可观的代码,但是让大家仔细看,那些都以为落成目的而写。

第一,那些事例中的小结构没有可预知性。创建了好多少个那样的结构的开发者希望她是特定的外观,但是当把他用在侧栏或是主页,他将看起来差距,即使结构是完全相同。

他的复用性扩充性也不是很好。当把她用在主页或是被须求用在其余页面会暴发什么?不得不添加新的条条框框。

最后,他不是很简单保证,因为一旦那么些社团重新设计了,那么他必须修改css中的好多少个地方,不适合后边提议的CSS架构的渴求,要求一个接一个的来修改。

想像一下,假使那种代码被用在其余语言。你当然用一个类定义,然后在代码的任何一些引入那几个类定义,为了其余的用处改变她,这间接违反了软件开发进度中开拓/关闭的口径。

 

Software entities (classes, modules, functions, etc.) should be open
for extension, but closed for modification.

 

在本文的背后,大家将看看哪些不借助于父接纳器修改组件。

走访更快

属性上的优势应该很显眼了。倘若您的体制越少、并CSS重复使用,你的CSS文件就能变得更小,那样浏览器就能更快地加载所有的资源。

确实,HTML文件会变大、也会浮现比较乱。但有很多事例都显示出,HTML质量的那点损失,对于样式表品质的的庞大提高以来,不足一提。

还一个亟须记住的点,就是面向对象CSS就好似额外的质量礼物。也等于说,你每便重用CSS,都以在开创无需CSS代码的新样式成分。对于大型、高流量的连串来说,那几个“礼物”都会是属性进步的关键因素。

定制过多的规则

突发性,你做了一个视觉组件必要她距离你的网站某个部分左侧上面分别有20px的舞狮:

.widget {
  position: absolute;
  top: 20px;
  left: 20px;
  background-color: red;
  font-size: 1.5em;
  text-transform: uppercase;
}

一段时间后您需求在差别的地点使用那些完全一致的零部件,但是以上的css代码不起功能,因为在不相同的环境中不可以复用。

标题是,你让这一个选取器做了太多的业务。你在同一个规则中既定义的外观,又定义了布局和从来。外观是足以复用的,但是布局和定点是无法复用的。因为你把她们都混在联名利用,所以一切规则就都无法复用了。

但是那几个初始看起来恐怕无害,然则他再三造成内行的css开发人员复制和粘帖。要是一个新公司成员想要做一个看起来好像的机件,如一
个.infobox。他们大概因而尝试开始用卓殊类名。不过因为一个新的infobox以一种不想要的办法固定,而不起效能。那么她们可能会做如何?以自个儿的经历,多数新的开发人士不会破坏复用部分的条条框框。相反他们只是不难复制需要的代码行,然后把他粘帖到一个新的选用器里,那就招致了不须要的又一次代码。

超负荷复杂的选用器

突发性一篇文章使得在网络里显示css选拔器的能力,并宣称你能够给整个网站定义样式而不要求选择任何类名或是id。

即便技术上是立见效用的,随着开发css的一语道破,我越来越远离复杂选用器。采用器越复杂,他跟html的咬合越严密。倚重于html标签和涉及选取器固然使你的html看起来很干净,不过它使您的css很不好。

#main-nav ul li ul li div { }
#content article h1:first-child { }
#sidebar > div > h3 + p { }

所有以上例子就是逻辑。第三个大概是一个下拉菜单样式,首个是说小说的首要题目跟任何h1元素看起来不相同,最终一个例证好像是给侧栏部分的第四个段落添加一些额外的距离。

比方这么些html永远不会变动,那么些理由或然可以看成他的一个亮点,可是假若html永远不会改变是多么不现实的工作。过于复杂的拔取器可以令人回想长远,他们可以使html摆脱所有表现的钩,可是她们却很少能协理大家贯彻优质的css结构的靶子。

上边的例证并不是所有的都可以复用。因为选择器指向一个卓殊尤其的价签地方,怎么可以让另一个享有不一致结构的机件重用那多少个体制呢?以首个例证(下拉菜单)作为例子,即使在此外页面必要丰裕一个看上去好像的下去菜单,可是她其中没有#main-nav的成分,你要做什么?你将不得不再次创立一整套样式。

倘使html结构要求转移那些采用器也是不可预测的。想象一下一个开发人士想要把第八个例子中的div改成html5的section标签,那么任何规则就破坏了。

末尾,因为那个选取器唯有当html保持不变才能干活,所以她们的概念是不足维护的也是不可伸张的。

在大型的应用程序中你只好做出权衡和和平解决。复杂选拔器的脆弱性是在保险你的html干净命名中起到很微小的成效。

体制表可维护

有了面向对象CSS,你无需面对频频“繁殖”着的不以为奇的样式表,取而代之的是一文山会海不难保险的模块,而在里边,自带天然的层叠效率充当主要作用。

当您为一个已部分站点添加新情节时,不须要再在样式表底部添加任何新样式而不考虑该样式是或不是已存在。你可以引用已有体制,并在已有平整集的基础上增添样式即可。

有了优先的探讨,只用一点点代码开发总体页面是截然有只怕的。任何已部分CSS模块可被用作所有新页面的根底成分,新的代码就能被压到最少。有些情形下,你居然能够只用一行CSS来开发一整个样式满满的页面。

体制表可维护的优势也进步了它的稳健性。因为,样式都是模块,那么当一个新的开发者也要用样式表时,页面看上去也会是联合的。

解析原因

上述所有不佳的施行有一个好像的地点,他们给css添加太多的负担。

那不啻是一个奇怪的题目,终归一个样式表,他难道不应有负责大部分(若是或不是任何体裁)的体裁吗?那个不是我们想要的啊?

其一简单难题的答问是yes,不过,像往常一模一样,事情并不一连那么不难,将内容与表现分离是件好事,可是不可以因为唯有你的css代码跟你的html
代码分离,就意味着你的始末与你的表现分离了。换句话说,从您的html中分离出来的保有表现代码,并不恐怕满意这些目的,若是为了工作须求您的css跟
html有个致密的牵连。

此外,html很少仅仅是内容,他多是用来代表结构的。而且一般那种结构是由没有意义的容器成分构成,不相同于容许css隔离某组特定成分。甚至未曾表现的类名,那仍然把表现混到html中,可是那是还是不是就是有须求将表现跟内容混合呢?

本身相信,介于html和css的脚下场景,有须求也是明智的把html和css混合一起作为一个彰显层。内容层如故可以通过沙盘和局地模版抽象出来。

超负荷通用的类名

当创造可采用的筹划组件时,一种很普遍的景况,就是用组件类名的其中包蕴组件子成分的类名表示范围,例如

<div class="widget">
  <h3 class="title">...</h3>
  <div class="contents">
    Lorem ipsum dolor sit amet, consectetur adipiscing elit.
    In condimentum justo et est dapibus sit amet euismod ligula ornare.
    Vivamus elementum accumsan dignissim.
    <button class="action">Click Me!</button>
  </div>
</div>

.widget {}
.widget .title {}
.widget .contents {}
.widget .action {}

其一想法是.title, .contents, 和
.action类名的子成分定义安全的体裁,不用担心会潜移默化其他那个具有同样类名的要素样式。那是真的,然而那并不可以防备其余同类名的体裁会影响这些组件的样式。

在一个大型项目很可能有个像.title的类名被用到另一个条件中或甚至他自我,即使那种气象暴发的话,那几个widget’s
title会突然看起来跟预期的不均等。

过度通用的类名会造成相当不足预知的css。

还有些值得您尊敬

面向对象CSS已经吸引了业界的熊熊议论,我试着清除部分人共有的错误观念。

缓解方案

设若你的html和css准备一起作为一个web应用程序的变现层,那么她们必要一种方法来促进优质css架构的有着标准的朝令暮改。

本人发觉最好的点子,是css包罗尽恐怕少的html结构。Css应该定义如何设置一个视觉成分的外观(为的是跟html有最小化的耦合度)那个因素
应该看上去如她定义的同等,而不管他出现在html中的什么地方。假设一个特定的机件必要在不一致的场地下看上去差距,那她应该叫做不相同的东西,那就是
html的职分了。

用作一个例证,css大概通过.button类名定义一个按钮组件。倘诺某个html成分想要看起来像个按钮,他应该使用分外类名。要是在某种处境,那么些按钮须要看起来不相同(只怕大点或全屏),然后css必要定义看上去好像用一个新的类名,html包罗这些新类名使用新外观。

Css定义你的零件长什么样,html掌管在页面上用哪些因素展现。知道越少关于html结构的css越好。

在html中有目共睹宣称你想要的是何等有很大的意思,他可能任何开发人员在观望标签就精通的领会那一个因素是长什么样。那样的意向是很明朗的。没有那种实践是不容许分辨一个要素的外观是或不是有误,那样就造成了社团之间的乌烟瘴气。

普普通通反对在html标签里写四个类名,认为这样做是剩下的。一个css规则恐怕效果于一个组件中的1千个实例。那么单纯是为着在标签里展现声明,他确实值得把这几个类名写1千次啊?

固然这些难点肯定是行得通的,但也恐怕误导人。那意味着要么你在css中用父类选择器,要么你手动在html中写1000次类名,但是很显然还有任何
的化解途径。Rails或其余框架的呈现层抽象,在维持html中显示效果,同时又幸免将同一个类名重复写了四次又五次的施行中,有了充足的阅历。

定制过多的条条框框

偶尔,你做了一个视觉组件须要她相差你的网站某个部分左侧上面分别有20px的撼动:

.widget {
  position: absolute;
  top: 20px;
  left: 20px;
  background-color: red;
  font-size: 1.5em;
  text-transform: uppercase;
}

一段时间后您须要在差异的地点采纳这么些完全平等的机件,可是以上的css代码不起效能,因为在差距的条件中不可以复用。

难点是,你让那一个选拔器做了太多的事务。你在同一个平整中既定义的外观,又定义了布局和固化。外观是足以复用的,不过布局和定点是不可以复用的。因为您把她们都混在一块儿利用,所以一切规则就都无法复用了。

只是这几个初步看起来只怕无害,不过她再三造成内行的css开发人员复制和粘帖。倘使一个新团队成员想要做一个看起来好像的零部件,如一个.infobox。他们可能通过尝试发轫用极度类名。可是因为一个新的infobox以一种不想要的措施固定,而不起成效。那么他们恐怕会做什么样?以我的阅历,多数新的开发人士不会损坏复用部分的规则。相反他们只是简短复制须求的代码行,然后把她粘帖到一个新的挑三拣四器里,那就导致了不要求的再度代码。

您照样能够用ID

如若你控制只利用面向对象CSS的不二法门来开发,那么您的体制很大程度上以class为根基,你也不会利用ID选取器来给成分定义样式。

约等于因为那样,很多个人错误地认为,面向对象CSS把ID放任了。那样就是说不对的。

具体来说,防止选取ID的意味是,不在采用器上接纳ID,而逃避样式在HTML中把ID作为JavaScript钩子和零散标识符却是完全正确的。

当然,你或然曾经用ID定义了页面的一个非同平时的要素,改用class莫不会相当增添几字节大小。但哪怕是这么,大家依然认为,依靠class来搞定今后说不定出现的特异性难题,对你的页面来说更可信赖。

极品实战

在一次又五遍犯上边的不当,并提交了必然代价之后,我计算出了之类的有些提出。即便不是很周详的,然则自身的经历注脚持之以恒那么些条件是能支援你更好的落成好的css架构的靶子

解析原因

上述所有不好的实施有一个看似的地点,他们给css添加太多的承负。

那不啻是一个奇怪的难点,毕竟一个样式表,他难道不该承担一大半(倘诺不是整个体制)的体制吗?那么些不是大家想要的吧?

本条差不多难点的答复是yes,可是,像过去相同,事情并不总是那么粗略,将内容与表现分离是件善事,但是无法因为唯有你的css代码跟你的html代码分离,就表示你的始末与您的变现分离了。换句话说,从你的html中分离出来的具备表现代码,并不可以满意那一个目的,假如为了工作需求你的css跟html有个细心的联系。

除此以外,html很少仅仅是内容,他多是用来表示结构的。而且一般那种社团是由没有意思的容器成分构成,不同于容许css隔离某组特定成分。甚至不曾突显的类名,那依旧把表现混到html中,然而那是还是不是就是有须要将呈现跟内容混合呢?

本身相信,介于html和css的日前情景,有需求也是明智的把html和css混合一起作为一个显示层。内容层依旧可以通过沙盘和局地模版抽象出来。

处理小型项目

对于小型的站点和app项目,你或许会觉得用面向对象CSS会有点浪费。所以,不要什么日期都把那篇小说作为辩解理由——如故得看项目来的。

纵然,我照旧觉得那是个好的视角,至少,你可以通常思考它。一旦您通晓了门道,我敢保证,你会意识开发大型项目变得灵活自如。

有意的

保险您的采取器不给不想要的因素添加样式的最好法子是不给她们机会。类似于#main-nav
ul li ul li
div那样的拔取器,或者当您的价签过段时间修改的时候很简单最终采纳到不须求的元素上。另一方面,像.Subnav这样的选取器就绝对无法想不到的利用
到一个不要求的成分上。把体制直接加在你想要有体制的因素上的最好的不二法门,就是维持您的css是可预测的:

/* Grenade */
#main-nav ul li ul { }

/* Sniper Rifle */
.subnav { }

提交上边三个例子,第四个像一个手榴弹,第三个像一个狙击步枪。手榴弹或然明日干活的很好,不过你无法清楚一个无辜平民是还是不是移动到爆炸的界定里。

涸泽而渔方案

比方你的html和css准备联合营为一个web应用程序的显现层,那么他们必要一种艺术来推进特出css架构的持有条件的演进。

我意识最好的办法,是css包括尽或然少的html结构。Css应该定义怎么样设置一个视觉成分的外观(为的是跟html有最小化的耦合度)那么些成分应该看上去如她定义的等同,而不管她出现在html中的什么地点。如若一个特定的机件须求在不一样的意况下看上去不一致,那他应有叫做分化的事物,那就是html的天职了。

作为一个例子,css或许通过.button类名定义一个按钮组件。若是某个html成分想要看起来像个按钮,他应该采纳尤其类名。就算在某种景况,那些按钮要求看起来不一样(只怕大点或全屏),然后css供给定义看上去好像用一个新的类名,html包括这几个新类名使用新外观。

Css定义你的组件长什么样,html掌管在页面上用什么样因素突显。知道越少关于html结构的css越好。

在html中分明宣称你想要的是何许有很大的意思,他只怕任何开发人士在见到标签就知晓的知晓那么些因素是长什么。那样的意图是很醒目标。没有那种实践是不容许分辨一个成分的外观是或不是有误,那样就导致了团伙之间的繁杂。

平时反对在html标签里写七个类名,认为那样做是剩下的。一个css规则恐怕功效于一个零部件中的1千个实例。那么单纯是为了在标签里呈现申明,他当真值得把这一个类名写1千次啊?

固然如此这几个难题显而易见是立见成效的,但也恐怕误导人。这意味要么你在css中用父类选取器,要么你手动在html中写1000次类名,然而很分明还有任何的解决途径。Rails或其他框架的变现层抽象,在维持html中显得效果,同时又防止将同一个类名重复写了三遍又四回的实施中,有了增加的经验。

实战引导

入门面向对象CSS或然会相比费时,我仍在努力学习中,所以不见得能回应所有的难题。

但只要你想进入面向对象的考虑格局,依旧有一对忠告想享受给你:

  • 毫不用派生接纳器(如不要用.sidebar h3
  • 决不用ID来控制样式
  • 不要把成分和class相关联(如不要用div.header或 h1.title
  • 唯有有分外境况,不要用!important
  • 用CSS
    Lint来检查你的代码(搞掌握你出现的题材,以及缓解形式)
  • 用CSS网格系统

些微时候,肯定会打破一些条条框框,但总的说来,这个都以支付的好习惯,能让您的样式表更小、更易维护。

分摊你的忧伤

自我早已涉及过一个团伙优良的组件层,能帮助降低在css中的对于html结构的耦合度。其它,你的css组件自己应当是模块化的。组件应该了然怎么定义他协调的体裁并把工作搞好,然则不应该让她们担当他们的布局或是定位,也不应有让他们过多若是怎么着与周围成分设置间隔。

万般,组件应该定义他们的外观怎样,而不定义他们的布局或稳定怎么样。所以当您在一条规则里面还要来看background,color,font,还有position,width,height,margin时,你将要小心咯。

布局和永恒应该依然由一个分其余布局类大概一个别离的容器元素处理(记住,为了火速地分别内容和显现,平常必不可少的将内容和她的器皿分离)。

顶级实战

在五回又五次犯上边的失实,并交由了必然代价之后,我统计出了如下的一对提出。固然不是很周详的,不过本身的经验表明百折不挠这几个条件是能帮助您更好的兑现好的css架构的对象

关注Nicole Sullivan进展

比方您想询问越来越多关于面向对象CSS的始末,那你最应该关注的就是Nicole
Sullivan。

除了时不时更新博客,尼科尔e也成立了广大幻灯片,以供浮现:

  • 面向对象CSS(幻灯片)
  • 高品质网站:尼科尔e
    Sullivan(视频)
  • 大家被卓越案例带入迷途(幻灯片)
  • 臃肿的CSS(幻灯片)

空间类名称

我们曾经检查了干吗父类拔取器无法100%很快的遏止样式的陆续污染。一个更好的不二法门是给类名自个儿应用命名空间。要是你r的因素是可视组件的一员,那么他的每一种子成分类都应当用组件的基类名作为他的命名空间

/* High risk of style cross-contamination */
.widget { }
.widget .title { }

/* Low risk of style cross-contamination */
.widget { }
.widget-title { }

你的类名有命名空间,可以保持您的零部件独立和模块化。它减弱了现有类之间的争论,降低了特殊性对子成分样式的须求。

有意的

担保您的拔取器不给不想要的因素添加样式的最好措施是不给她们机会。类似于#main-nav
ul li ul li
div那样的选用器,可能当你的价签过段时间修改的时候很容易最终采用到不须求的成分上。另一方面,像.Subnav那样的选用器就相对不可以想不到的选取到一个不要求的成分上。把体制直接加在你想要有体制的因素上的最好的点子,就是维持你的css是可预测的:

/* Grenade */
#main-nav ul li ul { }

/* Sniper Rifle */
.subnav { }

付出上面七个例子,首个像一个手榴弹,第三个像一个狙击步枪。手榴弹恐怕前日干活的很好,可是你无法了解一个无辜百姓是还是不是移动到爆炸的限定里。

结论

重重人还不能经受面向对象CSS的见地,觉得它看起来跟许多大家已推行过的精髓案例作对。但,一旦它的悠久效应被接受,我敢保险,会有一大批的开发者转会的。

简而言之,面向对象CSS在开发中应有能有个正确的前景,那也督促所有开发者要起来考虑(至少在一些地点)跟其项目其别人士进步合营,让网页变得更快、更有功能、更易维护。

官方网站:An Introduction To Object Oriented CSS
(OOCSS)

扩充组件与修改类

当一个存活组件须求在早晚的环境里看起来有些差异,创立一个修改类伸张他:

/* Bad */
.widget { }
#sidebar .widget { }

/* Good */
.widget { }
.widget-sidebar { }

大家曾经看到基于其中之一的父元素修改组件的弱点,然则要求再行一点:修改类可以采用到任哪个地点方。基于本地的可以覆盖只用于特殊地点的体裁。修改类
也得以如你所需复用多次。最后,修改类可以在html里面准确的发挥开发人士的意图。另一方面,基于本地对于一个开发人士只经过html是完全不可知的,
那样大大提升了被忽略的可能率。

分摊你的忧愁

自我一度涉及过一个公司卓越的组件层,能协理下落在css中的对于html结构的耦合度。别的,你的css组件本身应当是模块化的。组件应该知道怎么定义他协调的样式并把工作搞好,但是不应有让他俩负责他们的布局或是定位,也不应当让她们过多如果怎么着与周围成分设置间隔。

一般而言,组件应该定义他们的外观如何,而不定义他们的布局或定点怎么着。所以当您在一条规则里面还要来看background,color,font,还有position,width,height,margin时,你将要小心咯。

布局和固化应该照旧由一个分手的布局类或许一个别离的容器成分处理(记住,为了火速地分别内容和显现,常常必不可少的将内容和她的器皿分离)。

把你的CSS协会成逻辑结构

Jonathan
Snook在她写的一本很棒的书SMACSS中,
提出可以把你的css分为4个不一致的花色来集团,他们是基础样式,布局样式,模块样式以及气象样式。基础样式是由重置成分规则和要素暗中同意样式组成。布局样
式是定位站内成分以及通用布局似乎网格系统。模块样式是足以复用的视觉成分,状态样式就是因此javascript涉及到打开或关闭。

在SMACSS种类中,模块(就像本身说的机件)在拥有的css规则中占据绝半数以上,所以我平日觉得有须要把他们越发解释为架空的模板。

组件是足以单独的视觉成分。模版从一边来说是由块组成的。模版本人不可以独立运用还要很少描述外观和感到。相反,他们得以是十足的,可另行的情势,放在一起形成一个零件。

提供一个实际的例子,一个组件大概是一个模态对话框。这几个对话框或者尾部是站内通用的渐变背景象。并且周围有影子,右上角或然有一个关门按钮,他估摸是程度垂直居中一定的。那多个方式中的每一种在全站中大概一回次的应用,所以每一遍你都不用再一次编排他们的格局。因为他俩全是模版,可以一并组成一个模态
对话框组件。

平常自个儿在html中不拔取模板类,除非我有个很好的理由。相反,我在组件定义中选取一个涵盖模版样式的预处理器。上面我将详细讲解那几个以及自个儿这么做的合理。

空间类名称

咱俩早就检查了怎么父类拔取器不可以100%急忙的遏止样式的穿插污染。一个更好的法门是给类名本人应用命名空间。即使你r的成分是可视组件的一员,那么她的每一种子成分类都应该用组件的基类名作为他的命名空间

/* High risk of style cross-contamination */
.widget { }
.widget .title { }

/* Low risk of style cross-contamination */
.widget { }
.widget-title { }

您的类名有命名空间,可以保持你的组件独立和模块化。它收缩了现有类之间的龃龉,下落了特殊性对子成分样式的渴求。

只用类名作为样式而且只做样式

其他出席过大型项目标人都会遇上一个难题,就是一个html成分有个完全不亮堂为什么用的类名。你想要删除他,不过你犹豫了,因为她只怕有局地您不精通的用途。这样的情事四遍次的爆发,久而久之,你的html充满了种种不知任何用场类名,只因为社团成员害怕删除它们。

标题是类名在前端开发中一般赋予了太多的权责。他们用来定义html成分样式,作为javascript的钩,添加到html中用作功效检测和自动化测试等等。

当一个类名在应用程序中的太多地点使用,那是一个题材。那么把他从html中除去就成了一个不行可怕的政工。

不过,随着建立一个预订,那几个难题是可以完全防止的。当你在一个html中看出一个类名,应该立刻领会她是用来什么的。我的指出是给持有不用于定义
样式的类名加一个前缀。我使用.js作为javascript的钩,用.supports作为Modernizr
类名。所有仅仅是概念样式的类名没有前缀。

那使得发现没用的类名并剔除它们似乎在样式表目录搜索一样不难。你居然足以用javascript将以此进程自动化,通过检查在html中的类名是不是在document.styleSheets对象里面来判定。假如不在document.styleSheets里面的类名,就能够安全的去除了。

一般的话,分离你的情节与您的突显是一个特级实践,同样主要的还有将您的展现与效果分别。使用定义样式的类名作为javascript钩子,会把您
的css与javascript牢牢绑在一块,在某种程度上,在不损坏效果的前提下,更新一些成分的外观是很难的大概不能的。

推而广之组件与修改类

当一个存活组件必要在自然的环境里看起来有些差距,创设一个修改类增加他:

/* Bad */
.widget { }
#sidebar .widget { }

/* Good */
.widget { }
.widget-sidebar { }

大家已经观望基于其中之一的父成分修改组件的败笔,然而急需反复一点:修改类可以利用到其余地方。基于本地的可以覆盖只用于特殊地点的样式。修改类也得以如您所需复用数十次。最终,修改类可以在html里面准确的发挥开发人员的意图。另一方面,基于本地对于一个开发人员只经过html是完全不可知的,那样大大升高了被忽视的几率。

取名有逻辑结构的类名

以往广大人写css用连字符作为词的分隔符。不过仅仅连字符是不足以区分分化品类的类名的。

Nicolas
Gallagher目前写的有关那么些难题的缓解方案。我也拔取了(只需求轻微的修改)并取得了很大的中标。为了求证要求有如下命名的约定。

/* A component */
.button-group { }

/* A component modifier (modifying .button) */
.button-primary { }

/* A component sub-object (lives within .button) */
.button-icon { }

/* Is this a component class or a layout class? */
.header { }

从地点的类名,不能了然他们要使用什么项目的平整。那不单扩展支出进度中干扰,也加大用自动化格局测试css和html的难度。一个构造化命名约
定可以让你看来一个类名,就靠得住的知晓跟他有关的其他类名,以及她应该出现在html中的哪些地点。命名和测试变得简单可行,那在此前是不容许的。

/* Templates Rules (using Sass placeholders) */
%template-name
%template-name--modifier-name
%template-name__sub-object
%template-name__sub-object--modifier-name

/* Component Rules */
.component-name
.component-name--modifier-name
.component-name__sub-object
.component-name__sub-object--modifier-name

/* Layout Rules */
.l-layout-method
.grid

/* State Rules */
.is-state-type

/* Non-styled JavaScript Hooks */
.js-action-name

重做首个例证

/* A component */
.button-group { }

/* A component modifier (modifying .button) */
.button--primary { }

/* A component sub-object (lives within .button) */
.button__icon { }

/* A layout class */
.l-header { }

把您的CSS协会成逻辑结构

Jonathan
Snook在他写的一本很棒的书SMACSS中,指出可以把你的css分为4个不相同的系列来公司,他们是基础样式,布局样式,模块样式以及气象样式。基础样式是由重置成分规则和因素暗中认可样式组成。布局样式是定位站内成分以及通用布局似乎网格系统。模块样式是可以复用的视觉成分,状态样式就是经过javascript涉及到打开或关闭。

在SMACSS连串中,模块(就好像自个儿说的组件)在享有的css规则中占有绝一大半,所以本人每每觉得有要求把她们越是表达为架空的模版。

零件是能够单独的视觉成分。模版从一方面来说是由块组成的。模版本身无法独立使用还要很少描述外观和感觉。相反,他们可以是纯净的,可重复的方式,放在一块儿形成一个零件。

提供一个具体的例子,一个组件或者是一个模态对话框。那些对话框只怕底部是站内通用的渐变背景象。并且周围有影子,右上角大概有一个停歇按钮,他估价是水平垂直居中固定的。那多少个格局中的每一种在全站中大概一回次的选拔,所以每趟你都无须再次编排他们的格局。因为她们全是模版,可以共同构成一个模态对话框组件。

万般本身在html中不使用模板类,除非本人有个很好的说辞。相反,我在组件定义中行使一个含有模版样式的预处理器。下边我将详细讲解那几个以及自己这么做的客体。

工具

维护一个管用的同时有序的css架构是很困难的,尤其是在一个大型项目中。那里那里一些糟糕的规则可以像滚雪球一样成为一个麻烦控制的紊乱局面。一
旦你的应用程序中的css进入一个独特领域和有!important金牌的混战中,他大致不容许再次起首去复苏。关键是从一方始就防止这一个题材。

有幸的是,那里有一部分工具得以不难的控制你的网站的css架构。

只用类名作为样式而且只做样式

其余加入过大型项目标人都会遭受一个难点,就是一个html成分有个完全不知情干什么用的类名。你想要删除他,不过你犹豫了,因为他大概有部分您不亮堂的用处。那样的景观两次次的发生,久而久之,你的html充满了种种不知任何用场类名,只因为公司成员害怕删除它们。

难题是类名在前端开发中不足为奇赋予了太多的义务。他们用来定义html成分样式,作为javascript的钩,添加到html中用作作用检测和自动化测试等等。

当一个类名在应用程序中的太多地点使用,那是一个标题。那么把他从html中除去就成了一个充足可怕的业务。

可是,随着建立一个约定,这些题材是足以完全幸免的。当您在一个html中见到一个类名,应该及时驾驭他是用来什么的。我的提出是给所有不用于定义样式的类名加一个前缀。我使用.js作为javascript的钩,用.supports作为Modernizr
类名。所有仅仅是概念样式的类名没有前缀。

那使得发现没用的类名并删除它们就好像在样式表目录搜索一样不难。你居然可以用javascript将那一个进程自动化,通过检查在html中的类名是否在document.styleSheets对象里面来判断。倘若不在document.styleSheets里面的类名,就足以高枕无忧的去除了。

一般的话,分离你的内容与您的表现是一个特级实践,同样首要的还有将您的变现与效果分别。使用定义样式的类名作为javascript钩子,会把你的css与javascript牢牢绑在协同,在某种程度上,在不损坏效应的前提下,更新一些因素的外观是很难的只怕不容许的。

预处理程序

近期谈到css工具就不可防止的要提及预处理程序。所以本文也不例外。可是在本人称扬他们的用途此前,我应当说有的她的注意事项。

预处理程序能够帮你更快但不是更好的书写css。最终演化成纯粹的css和同一个平整的施用。如若一个预处理程序可以让您写css更快,那么也可以让你更快的写出不佳的css。所以在让预处理程序化解你的难点从前,应该了解一下好的css架构就展现特别重大。

无数所谓的预处理程序的特色实际上对于css架构是很糟糕的。以下是部分自我不惜一切代价防止的表征(固然这么些大规模思想应用于具有的预处理程序语言,这几个规则特别是在sass中行使)。

  1. 代码社团上没有嵌套规则。当输出的css是您想要的
  2. 亚洲必赢官网 ,如若你不传参数的话从不使用混入类。没有参数的混入类可以更好的作为模版使用,那样的模板可以增添
  3. 没有在采取器上行使@extend,他不是一个独立的类。从设计角度他没有意思,而且会加大css编译后的体积
  4. 尚未使用@extend为ui组件在组件修改器,因为您丢失了继承链(那点)

预处理程序中最好的局地是像@extend
%placeholder的函数。那两边容许你轻轻松松管理抽象出来的css,而并未扩大你的css,或是在html中添加一大串很难管理的底蕴类名.

因为有时候你想在您的html中选取那么些类名@extend应该小心使用。例如,当您首先次询问@extend,你或许会在您的有所的修改类里面尝试的运用它,如同那样:

.button {
  /* button styles */
}

/* Bad */
.button--primary {
  @extend .button;
  /* modification styles */
}

如此做的题材是在html中你丢失了继承链。以往用javascript很难选中所有的按钮实例。

作为一般的平整,我从未增添ui组件,或是以往自个儿恐怕想要了然的类型。那是从另一个下边援助分歧模版与组件的不二法门。模版是有的在你的应用程序逻辑中不需求考虑的对象,所以可以安全的用预处理程序伸张。

上边是她怎么使用方面模态例子引用

.modal {
  @extend %dialog;
  @extend %drop-shadow;
  @extend %statically-centered;
  /* other modal styles */
}

.modal__close {
  @extend %dialog__close;
  /* other close button styles */
}

.modal__header {
  @extend %background-gradient;
  /* other modal header styles */
}

命名有逻辑结构的类名

现行广大人写css用连字符作为词的分隔符。可是偏偏连字符是不足以区分差别类其他类名的。

Nicolas
Gallagher近年写的有关那一个标题标化解方案。我也运用了(只要求轻微的改动)并得到了很大的中标。为了注解必要有如下命名的预约。

/* A component */
.button-group { }

/* A component modifier (modifying .button) */
.button-primary { }

/* A component sub-object (lives within .button) */
.button-icon { }

/* Is this a component class or a layout class? */
.header { }

从上边的类名,不容许精通她们要利用什么项目标平整。这不仅增添支出进度中苦恼,也加大用自动化情势测试css和html的难度。一个结构化命名约定可以让您看看一个类名,就靠得住的精通跟她关于的其余类名,以及他应有出现在html中的哪些地点。命名和测试变得不难可行,这在以前是无法的。

/* Templates Rules (using Sass placeholders) */
%template-name
%template-name--modifier-name
%template-name__sub-object
%template-name__sub-object--modifier-name

/* Component Rules */
.component-name
.component-name--modifier-name
.component-name__sub-object
.component-name__sub-object--modifier-name

/* Layout Rules */
.l-layout-method
.grid

/* State Rules */
.is-state-type

/* Non-styled JavaScript Hooks */
.js-action-name

重做第二个例子

/* A component */
.button-group { }

/* A component modifier (modifying .button) */
.button--primary { }

/* A component sub-object (lives within .button) */
.button__icon { }

/* A layout class */
.l-header { }

CSS Lint

Nicole Sullivan 和 Nicholas
Zakas 创建了 CSS Lint
作为一个工具,用来增援开发人士在他们的css中检查不佳的施行。他们的网站上如此描述:

Css
lint提议你的css代码的题材。他有底蕴语法检查,也运用一组代码规则,查找难点格局或低作用迹象。规则都以可以插入的,所以你可以简单的书写本身的恐怕省略你不想要的条条框框

纵然通用规则只怕不适用大多数系列,css
lint最好的性状是它能够定制成你想要的。那意味你可以从他们私行认同的列表里甄选你想要的体制,也足以编制本人的体裁。

对于其他一个重型集团像css
lint那样的工具是必备的,用以确保基本的一致性和符合约定。似乎自家目前暗示的同样,一个预定的主要原因是像css
lint那样的工具所以能够不难的辨识破坏他们的平整。

据悉上边我提议的预定,书写特定的反形式规则变得很简单。那里有一些自个儿利用的提出

  1. 在您的选取器里不容许使用id
  2. 在任何由多少个部分构成的平整里永不选取项目选取器(如div,span)
  3. 在一个挑选器里不要采用多于八个事关选拔器
  4. 不容许任何类名以‘js-’起初
  5. 如若常常在布局和固化中动用没有‘l-’前缀的条条框框出现警示
  6. 一经一个类名定义自个儿,之后作为其余因素的子成分重新定义出现警示

这么些强烈只是指出,不过可以促进你想想如何在您的品类中执行正式。

工具

爱护一个卓有成效的还要稳步的css架构是很劳苦的,尤其是在一个大型项目中。那里那里一些不好的平整可以像滚雪球一样成为一个不便控制的混乱局面。一旦你的应用程序中的css进入一个破例领域和有!important金牌的混战中,他差不多不容许再一次起首去苏醒。关键是从一从头就防止这几个难点。

侥幸的是,那里有一对工具得以简单的操纵你的网站的css架构。

HTML校检

最初我提出可以查找你的html中类名和有着链接的样式表,倘诺在html中冒出的类名,然而在其余一个样式表里面没有定义,就会出警示。我后天在付出一个叫HTML
Inspector的工具(我将很快放源)使得那些历程更便于。

Html Inspector遍历你的html代码(像css
lint)容许你写自身的条条框框,当一些预定规则破坏时候抛出错误和警告。我当下利用以下规则:

  1. 如若同样的id不止三遍面世在一个页面上,就会有警告
  2. 不采取其余在其余样式表或是通过的白名单里不曾关联的类名(像“js-”前缀的类名)
  3. 从没基类名不该运用modifer类
  4. 未曾祖先成分包涵基类子成分类名不该利用
  5. 常见的旧div或是span成分,没有附加类,不应有用于html

预处理程序

将来谈到css工具就不可防止的要提及预处理程序。所以本文也不例外。但是在自个儿称赞他们的用途以前,我应当说有的她的注意事项。

预处理程序可以帮您更快但不是更好的书写css。最后演化成纯粹的css和同一个规则的使用。即使一个预处理程序可以让您写css更快,那么也足以让您更快的写出倒霉的css。所以在让预处理程序化解你的标题以前,应该清楚一下好的css架构就显示尤为紧要。

很多所谓的预处理程序的性格实际上对于css架构是很糟糕的。以下是部分自我不惜一切代价幸免的风味(固然那几个科普思想应用于具有的预处理程序语言,那一个轨道尤其是在sass中接纳)。

  1. 代码协会上从未有过嵌套规则。当输出的css是你想要的
  2. 一旦您不传参数的话从不使用混入类。没有参数的混入类可以更好的当作模版使用,那样的沙盘可以增加
  3. 并未在采用器上选择@extend,他不是一个独立的类。从统筹角度他不曾意思,而且会加大css编译后的体积
  4. 未曾使用@extend为ui组件在组件修改器,因为您丢失了继承链(那或多或少)

预处理程序中最好的一对是像@extend和 %placeholder的函数。那两边容许你轻松管理抽象出来的css,而没有扩张你的css,或是在html中添加一大串很难管理的根基类名.

因为偶然你想在您的html中应用这几个类名@extend应该小心使用。例如,当您首先次询问@extend,你或许会在您的富有的修改类里面尝试的运用它,就像是那样:

.button {
  /* button styles */
}

/* Bad */
.button--primary {
  @extend .button;
  /* modification styles */
}

如此那般做的题材是在html中您丢失了继承链。以后用javascript很难选中所有的按钮实例。

作为一般的规则,我从没增加ui组件,或是今后自己恐怕想要精晓的门类。这是从另一个地方支持差别模版与组件的方法。模版是部分在您的应用程序逻辑中不须求考虑的靶子,所以可以安全的用预处理程序扩张。

上面是他如何选择方面模态例子引用

.modal {
  @extend %dialog;
  @extend %drop-shadow;
  @extend %statically-centered;
  /* other modal styles */
}

.modal__close {
  @extend %dialog__close;
  /* other close button styles */
}

.modal__header {
  @extend %background-gradient;
  /* other modal header styles */
}

总结

Css并不只是视觉设计。不要只是因为您在写css就扔掉编程中的最佳实践。像面向对象,dry概念,开闭原则,关心点分离等等,如故适用于css。

底线是任何可以协会你的代码的事物,确保您判定你的艺术是不是有效救助您付出简单,长时间更易维护。

翻译手语:初次翻译前端技术博文,整个翻译依据原文线路开展,并在翻译进度略加了民用对技术的精通。借使翻译有不规则之处,还烦请同行朋友引导。感激!

如需转发烦请评释出处:

CSS Lint

Nicole Sullivan 和 Nicholas
Zakas 创建了 CSS
Lint 作为一个工具,用来帮忙开发职员在她们的css中检查糟糕的履行。他们的网站上这么描述:

 

Css
lint提议你的css代码的难题。他有底蕴语法检查,也使用一组代码规则,查找难题格局或低效用迹象。规则都是可以插入的,所以你可以不难的书写本身的可能省略你不想要的平整

 

固然通用规则或然不适用一大半项目,css
lint最好的特色是它可以定制成你想要的。那意味你可以从她们暗中同意的列表里选取你想要的体裁,也可以编写本身的样式。

对此其余一个巨型公司像css
lint这样的工具是须求的,用以确保基本的一致性和适合约定。如同自身面前暗示的平等,一个约定的要紧缘由是像css
lint那样的工具所以可以简单的甄别破坏他们的条条框框。

基于上面我提出的约定,书写特定的反情势规则变得很简单。那里有一些自己动用的提出

  1. 在您的选取器里不容许使用id
  2. 在任何由多个部分组成的条条框框里不要使用项目拔取器(如div,span)
  3. 在一个选拔器里不要使用多于多个涉及拔取器
  4. 不容许任何类名以‘js-’发轫
  5. 假定日常在布局和永恒中应用没有‘l-’前缀的平整出现警示
  6. 比方一个类名定义本身,之后作为其余因素的子成分重新定义出现警示

那么些明确只是指出,可是足以推进你思考什么在你的类型中举行规范。

HTML校检

最初我提出方可查找你的html中类名和享有链接的样式表,即使在html中冒出的类名,但是在其他一个样式表里面没有定义,就会出警示。我今日在支付一个叫HTML
Inspector的工具(我将很快放源)使得那个历程更便于。

Html Inspector遍历你的html代码(像css
lint)容许你写自身的平整,当一些预订规则破坏时候抛出错误和警告。我日前利用以下规则:

  1. 若是相同的id不止三遍出现在一个页面上,就会有警示
  2. 不应用任何在其余样式表或是通过的白名单里从未涉及的类名(像“js-”前缀的类名)
  3. 从未基类名不应当使用modifer类
  4. 尚未祖先成分包蕴基类子元素类名不应有采用
  5. 一般说来的旧div或是span成分,没有附加类,不应有用于html

总结

Css并不只是视觉设计。不要一味因为你在写css就扔掉编程中的最佳实践。像面向对象,dry概念,开闭原则,关心点分离等等,如故适用于css。

底线是其余可以协会你的代码的事物,确保您判定你的办法是或不是行得通帮扶您付出不难,长时间更易维护。

翻译手语:首先翻译前端技术博文,整个翻译按照原文线路举行,并在翻译进度略加了私家对技术的精通。如果翻译有难堪之处,还烦请同行朋友指导。多谢!

如需转发烦请注脚出处:

英文原文:http://engineering.appfolio.com/2012/11/16/css-architecture

华语译文:

网站地图xml地图