CSS架构

作者: 前端知识  发布:2019-08-29

CSS架构

2013/04/24 · CSS · CSS

菲律宾语原著:CSS Architecture,编译:CSDN-张红月

菲尔ip 沃尔顿 在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是不足预见的。当那一个小部件出现在页面两边或许主页面时,开采人士期望它们以某种特定的措施呈现出来,且又不失特色。另外,它也是不足重用或不足扩大的。

除此以外,它也相比较难保证。一旦这几个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之间的耦合,但在不打破功用性的前提下很难只怕根本不恐怕变动外观。

有逻辑的命名类

当先58%写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

本文由金沙澳门官网发布于前端知识,转载请注明出处:CSS架构

关键词: 金沙澳门官网