xml地图|网站地图|网站标签 [设为首页] [加入收藏]
实现更多功能,通俗讲解
分类:web前端

CSS 浮动(float,clear) 通俗讲解

2013/06/25 · CSS · 25 评论 · clear, float

来源:杨元的博客

 很早以前就接触过CSS,但对于浮动始终非常迷惑,可能是自身理解能力差,也可能是没能遇到一篇通俗的教程。

前些天小菜终于搞懂了浮动的基本原理,迫不及待的分享给大家

写在前面的话:

由于CSS内容比较多,小菜没有精力从头到尾讲一遍,只能有针对性的讲解。

如果读者理解CSS盒子模型,但对于浮动不理解,那么这篇文章可以帮助你。

小菜水平有限,本文仅仅是入门教程,不当之处请谅解!

本文以div元素布局为例。

教程开始:

首先要知道,div是块级元素,在页面中独占一行,自上而下排列,也就是传说中的。如下图:

图片 1

可以看出,即使div1的宽度很小,页面中一行可以容下div1和div2,div2也不会排在div1后边,因为div元素是独占一行的。

注意,以上这些理论,是指标准流中的div。

小菜认为,无论多么复杂的布局,其基本出发点均是:“如何在一行显示多个div元素”。

显然标准流已经无法满足需求,这就要用到浮动。

浮动可以理解为让某个div元素脱离标准流,漂浮在标准流之上,和标准流不是一个层次。

例如,假设上图中的div2浮动,那么它将脱离标准流,但div1、div3、div4仍然在标准流当中,所以div3会自动向上移动,占据div2的位置,重新组成一个流。如图:

图片 2

从图中可以看出,由于对div2设置浮动,因此它不再属于标准流,div3自动上移顶替div2的位置,div1、div3、div4依次排列,成为一个新的流。又因为浮动是漂浮在标准流之上的,因此div2挡住了一部分div3,div3看起来变“矮”了

这里div2用的是左浮动(float:left;),可以理解为漂浮起来后靠左排列,右浮动(float:right;)当然就是靠右排列。这里的靠左、靠右是说页面的左、右边缘。

如果我们把div2采用右浮动,会是如下效果:

图片 3

此时div2靠页面右边缘排列,不再遮挡div3,读者可以清晰的看到上面所讲的div1、div3、div4组成的流。

目前为止我们只浮动了一个div元素,多个呢?

下面我们把div2和div3都加上左浮动,效果如图:

图片 4

 

同理,由于div2、div3浮动,它们不再属于标准流,因此div4会自动上移,与div1组成一个“新”标准流,而浮动是漂浮在标准流之上,因此div2又挡住了div4。

咳咳,到重点了,当同时对div2、div3设置浮动之后,div3会跟随在div2之后,不知道读者有没有发现,一直到现在,div2在每个例子中都是浮动的,但并没有跟随到div1之后。因此,我们可以得出一个重要结论:

假如某个div元素A是浮动的,如果A元素上一个元素也是浮动的,那么A元素会跟随在上一个元素的后边(如果一行放不下这两个元素,那么A元素会被挤到下一行);如果A元素上一个元素是标准流中的元素,那么A的相对垂直位置不会改变,也就是说A的顶部总是和上一个元素的底部对齐。

div的顺序是HTML代码中div的顺序决定的。

靠近页面边缘的一端是前,远离页面边缘的一端是后。

图片 5

 

为了帮助读者理解,再举几个例子。

假如我们把div2、div3、div4都设置成浮动,效果如下:

图片 6

根据上边的结论,跟着小菜理解一遍:先从div4开始分析,它发现上边的元素div3是浮动的,所以div4会跟随在div3之后;div3发现上边的元素div2也是浮动的,所以div3会跟随在div2之后;而div2发现上边的元素div1是标准流中的元素,因此div2的相对垂直位置不变,顶部仍然和div1元素的底部对齐。由于是左浮动,左边靠近页面边缘,所以左边是前,因此div2在最左边。

假如把div2、div3、div4都设置成浮动,效果如下:

图片 7

 

道理和左浮动基本一样,只不过需要注意一下前后对应关系。由于是右浮动,因此右边靠近页面边缘,所以右边是前,因此div2在最右边。

假如我们把div2、div4左浮动,效果图如下:

图片 8

依然是根据结论,div2、div4浮动,脱离了标准流,因此div3将会自动上移,与div1组成标准流。div2发现上一个元素div1是标准流中的元素,因此div2相对垂直位置不变,与div1底部对齐。div4发现上一个元素div3是标准流中的元素,因此div4的顶部和div3的底部对齐,并且总是成立的,因为从图中可以看出,div3上移后,div4也跟着上移,div4总是保证自己的顶部和上一个元素div3(标准流中的元素)的底部对齐

至此,恭喜读者已经掌握了添加浮动,但还有清除浮动,有上边的基础清除浮动非常容易理解。

经过上边的学习,可以看出:元素浮动之前,也就是在标准流中,是竖向排列的,而浮动之后可以理解为横向排列。

清除浮动可以理解为打破横向排列。

清除浮动的关键字是clear,官方定义如下:

语法:

clear : none | left | right | both

取值:

none  :  默认值。允许两边都可以有浮动对象

left   :  不允许左边有浮动对象

right  :  不允许右边有浮动对象

both  :  不允许有浮动对象

定义非常容易理解,但是读者实际使用时可能会发现不是这么回事。

定义没有错,只不过它描述的太模糊,让我们不知所措。

根据上边的基础,假如页面中只有两个元素div1、div2,它们都是左浮动,场景如下:

图片 9

此时div1、div2都浮动,根据规则,div2会跟随在div1后边,但我们仍然希望div2能排列在div1下边,就像div1没有浮动,div2左浮动那样。

这时候就要用到清除浮动(clear),如果单纯根据官方定义,读者可能会尝试这样写:在div1的CSS样式中添加clear:right;,理解为不允许div1的右边有浮动元素,由于div2是浮动元素,因此会自动下移一行来满足规则。

其实这种理解是不正确的,这样做没有任何效果。看小菜定论:

对于CSS的清除浮动(clear),一定要牢记:这个规则只能影响使用清除的元素本身,不能影响其他元素。

怎么理解呢?就拿上边的例子来说,我们是想让div2移动,但我们却是在div1元素的CSS样式中使用了清除浮动,试图通过清除div1右边的浮动元素(clear:right;)来强迫div2下移,这是不可行的,因为这个清除浮动是在div1中调用的,它只能影响div1,不能影响div2。

根据小菜定论,要想让div2下移,就必须在div2的CSS样式中使用浮动。本例中div2的左边有浮动元素div1,因此只要在div2的CSS样式中使用clear:left;来指定div2元素左边不允许出现浮动元素,这样div2就被迫下移一行。

图片 10

那么假如页面中只有两个元素div1、div2,它们都是右浮动呢?读者此时应该已经能自己推测场景,如下:

图片 11

此时如果要让div2下移到div1下边,要如何做呢?

同样根据小菜定论,我们希望移动的是div2,就必须在div2的CSS样式中调用浮动,因为浮动只能影响调用它的元素。

可以看出div2的右边有一个浮动元素div1,那么我们可以在div2的CSS样式中使用clear:right;来指定div2的右边不允许出现浮动元素,这样div2就被迫下移一行,排到div1下边。

图片 12

 

至此,读者已经掌握了CSS+DIV浮动定位基本原理,足以应付常见的布局。

其实,万变不离其宗,只要读者用心体会,再复杂的布局都可以通过小菜总结的规律搞定。

写在后面的话:

必须严正声明,CSS这块极其混乱,尤其是浏览器的兼容性问题,小菜水平有限,本文很可能有不当之处,望读者见谅。

其实真不想写这么长的文章,可为了读者能够理解,总是不由自主的想多举些例子。

为了减轻读者心理压力,本文没有任何CSS、HTML代码,因为现在很多教程上来就是一大堆CSS代码,看到就烦,别说细读了。

最后预祝读者阅读愉快,开心掌握知识。

1 赞 2 收藏 25 评论

图片 13

CSS架构

2013/04/24 · CSS · CSS

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

Philip Walton 在AppFolio担任前端工程师,他在Santa Barbara on Rails的聚会上提出了CSS架构和一些最佳实践,并且在工作中一直沿用。

擅长CSS的Web开发人员不仅可以从视觉上复制实物原型,还可以用代码进行完美的呈现。无需使用表格、尽可能少的使用图片。如果你是个名副其实的高手,你可以快速把最新和最卓越的技术应用到你的项目中,比如媒体查询、过渡、滤镜、转换等。虽然这些都是一个真正的CSS高手所具备的,但CSS很少被人单独拿出来讨论,或者用它去评估某个人的技能。

有趣的是,我们很少这样去评价其他语言。Rails开发人员并不会因为其代码比较规范,就认为他是一名优秀的开发人员。这仅仅是个基准。当然,他的代码得必须规范。另外,还需集合其他方面考虑,比如代码是否可读?是否容易修改或扩展……

这都是些很自然的问题,CSS和它们并没有什么不同之处。今天的Web应用程序要比以往更加庞大。一个缺乏深思熟虑的CSS架构往往会削弱发展,是时候像评估其他语言那样,来评估一下CSS架构了,这些都不应该放在“事后”考虑或者单单属于设计师们的事情。

图片 14

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之间的耦合,但在不打破功能性的前提下很难或者根本不可能更改外观。

有逻辑的命名类

大多数写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 收藏 评论

图片 15

在 CSS 中使用 LESS 实现更多功能

2013/08/18 · CSS · CSS

原文出处: IBM developerworks   

CSS 彻底改变了 Web 页面的设计,但 CSS 仍然是静态的,而且在其句法发展方面受到限制。这些限制是有目的且合乎情理的,鼓励广泛加以实现。但开发人员和设计人员常常发现 CSS 使用起来很单调乏味。许多 Web 框架包含一些工具,这些工具使得人们更容易使用更灵活的特性创作 CSS,然后将结果编译成静态 CSS,以便部署到站点。最近的一些项目更侧重于创建旨在编译到 CSS 中的语言。Alexis Sellier 的开源项目 LESS 是这类语言中最受欢迎的一种语言。

LESS 在现有 CSS 语法之上添加了一些开发人员熟悉的特性,比如变量、mixins、运算符和函数。可以使浏览器中的 JavaScript 或通过服务器端 JavaScript 工具集的预处理将 LESS 编译到 CSS 中。LESS 在其他各种工具集中也得到了广泛应用,包括 JavaScript 的流行 Bootstrap 项目。在本文中,我要介绍的是 LESS(尤其是 1.4 版本),LESS 是为现代网站编写可读性的、可维护的 CSS 的一种方式。参见 下载部分,获取本文的示例代码。

入门

下载最新版 LESS(撰写本文之时是 1.4;参见 参考资料)。然后准备学习其语言。万维网联盟 (W3C) 在其维基中提供了一些用于学习 CSS 的资料。我基本上遵循该教程的顺序,因此,如有需要的话,您可以一前一后学习基本的 CSS 和 LESS。

清单 1 再现了 W3C 教程的第一个示例:

清单 1. 基本 CSS 示例 (listing1.css)

CSS

p { color: red; font-size: 12px; background-color: green; }

1
2
3
4
5
p {
  color: red;
  font-size: 12px;
  background-color: green;
}

清单 2 中的 HTML 将 清单 1 中的 CSS 投入使用:

清单 2. 引用清单 1 的基本 CSS 示例的 HTML (listing2.html)

CSS

<head> <link rel="stylesheet" type="text/css" href="listing1.css"> </head> <body> <p>This is a paragraph</p> </body>

1
2
3
4
5
6
<head>
    <link rel="stylesheet" type="text/css" href="listing1.css">
</head>
<body>
    <p>This is a paragraph</p>
</body>

图 1 显示了 Mac OS X 上 Safari 浏览器中显示的 listing2.html:

图 1. 使用清单 1 中的 CSS 的浏览器输出

图片 16

删除魔法值

看到 清单 1 的开发人员很可能立刻注意到那些违反开发者本能的内容,即硬编码到 CSS 中的值,这些值有时被揶揄为 “魔法值 (magic value)”。LESS 中最重要的特性之一是变量。清单 3 是使用变量的一个 LESS 基本示例版本:

清单 3. 使用 LESS 中的变量的基本 CSS 示例 (listing3.css)

CSS

@main-text-color: red; @main-text-size: 12px; @main-text-bg: green; p { color: @main-text-color; font-size: @main-text-size; background-color: @main-text-bg; }

1
2
3
4
5
6
7
8
9
@main-text-color: red;
@main-text-size: 12px;
@main-text-bg: green;
 
p {
  color: @main-text-color;
  font-size: @main-text-size;
  background-color: @main-text-bg;
}

清单 3 不是语法正确的 CSS,因此您不能在 HTML 中将 listing1.css替换为 listing3.less。您还必须更新主机 HTML 来调用 JavaScript 编译器,如清单 4 所示:

清单 4. 引用基本 CSS 示例 LESS 版本的 HTML (listing4.html)

CSS

<head> <link rel="stylesheet/less" type="text/css" href="listing3.less"> </head> <body> <p>This is a paragraph</p> <script src="less.js" type="text/javascript"></script> </body>

1
2
3
4
5
6
7
<head>
    <link rel="stylesheet/less" type="text/css" href="listing3.less">
</head>
<body>
    <p>This is a paragraph</p>
    <script src="less.js" type="text/javascript"></script>
</body>

请注意,在 清单 4 中,我将 script标记放在页面 body的结尾处。传统上,大多数开发人员将 script标记放在 head中。但将它们放在 body中是合法的,这利用了这样一个事实(引用自 HTML 4 规范),即 “script元素按照加载文档的顺序进行求值”。如今许多站点在临近结束时都有一些脚本,因此主要内容的加载不会因为任何脚本处理而延迟。

服务器端编译

到目前为止,我已经向您展示:开发和部署 LESS 便于快速使用浏览器,但却是有代价的。每次页面加载时,编译用的 JavaScript 都运行于用户的浏览器之上,这耗尽了计算资源并减缓了页面加载。如果在浏览器中加载 清单 4 ,并检查 JavaScript 控制台,则会看到一条消息:“less: css generated in 36ms”。36 毫秒的时间并不算长,但它代表着额外的不必要计算和时间。快速页面加载在 Web 上很重要。

在转入生产模式之后,使用一个服务器端 JavaScript 工具将 LESS 编译到 CSS 中。Node.js 是一个流行选项,被记录在 LESS 站点上。我喜欢使用 Mozilla 的独立 JavaScript 项目 Rhino。要使用 Rhino 和 LESS,请下载并安装 Rhino(参见 参考资料)。将 js.jar 放在一个方便进行构建的位置。您需要一个特殊版本的 less.js,该版本可在 GitHub 完整下载的 LESS 中下载中找到(参见 参考资料)。本文中使用的版本是 less.js-master/dist/less-rhino-1.4.0.js。将 less-rhino-1.4.0.js 放在保存 Rhino JAR 的地方。下面准备将 LESS 代码编译到 CSS 中。

要编译 listing3.less,请切换到 listing3.less 所在的目录并执行以下命令:

CSS

java -jar js.jar less-rhino-1.4.0.js listing3.less > listing3.css

1
java -jar js.jar less-rhino-1.4.0.js listing3.less > listing3.css

编译操作会将生成的 CSS 放在 listing3.css 文件中。该文件的内容如下:

CSS

p { color: #ff0000; font-size: 12px; background-color: #008000; }

1
2
3
4
5
p {
  color: #ff0000;
  font-size: 12px;
  background-color: #008000;
}

在 listing3.css 中,LESS 变量被替换,颜色名称被替换为 RGB 形式(比如 red被替换为 #ff0000)。现在您可以按照常用方法将 listing3.css 部署到一台服务器中。

本文由澳门新葡亰手机版发布于web前端,转载请注明出处:实现更多功能,通俗讲解

上一篇:构建单页Web应用,网易邮箱的CSS开发 下一篇:你需要知道的三个,CSS基线之道
猜你喜欢
热门排行
精彩图文