Add New Notes
158
Zim/Web-Design/CSS_Pseudo-elements.txt
Normal file
@@ -0,0 +1,158 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-15T17:05:31+08:00
|
||||
|
||||
====== CSS Pseudo-elements ======
|
||||
Created Sunday 15 May 2011
|
||||
http://www.w3schools.com/css/css_pseudo_elements.asp
|
||||
|
||||
CSS pseudo-elements are used to **add special effects to some selectors**.
|
||||
|
||||
===== Syntax =====
|
||||
|
||||
The syntax of pseudo-elements:
|
||||
|
||||
**selector:pseudo-element {property:value;}**
|
||||
|
||||
CSS classes can also be used with pseudo-elements:
|
||||
|
||||
**selector.class:pseudo-element {property:value;}**
|
||||
|
||||
===== The :first-line Pseudo-element =====
|
||||
|
||||
The "first-line" pseudo-element is used to **add a special style to the first line of a text**.
|
||||
|
||||
In the following example the browser formats the first line of text in a p element according to the style in the "first-line" pseudo-element (where the browser breaks the line, depends on the size of the browser window):
|
||||
|
||||
==== Example ====
|
||||
**p:first-line**
|
||||
{
|
||||
color:#ff0000;
|
||||
font-variant:small-caps;
|
||||
}
|
||||
|
||||
|
||||
=== Note: ===
|
||||
The "first-line" pseudo-element can only be used with **block-level elements**.
|
||||
|
||||
=== Note: ===
|
||||
The following properties apply to the "first-line" pseudo-element:
|
||||
|
||||
font properties
|
||||
color properties
|
||||
background properties
|
||||
word-spacing
|
||||
letter-spacing
|
||||
text-decoration
|
||||
vertical-align
|
||||
text-transform
|
||||
line-height
|
||||
clear
|
||||
|
||||
===== The :first-letter Pseudo-element =====
|
||||
|
||||
The "first-letter" pseudo-element is used to** add a special style to the first letter of a text**:
|
||||
|
||||
=== Example ===
|
||||
p:first-letter
|
||||
{
|
||||
color:#ff0000;
|
||||
font-size:xx-large;
|
||||
}
|
||||
|
||||
|
||||
**Note: **The "first-letter" pseudo-element can only be used with** block-level elements**.
|
||||
|
||||
**Note: **The following properties apply to the "first-letter" pseudo- element:
|
||||
|
||||
font properties
|
||||
color properties
|
||||
background properties
|
||||
margin properties
|
||||
padding properties
|
||||
border properties
|
||||
text-decoration
|
||||
vertical-align (only if "float" is "none")
|
||||
text-transform
|
||||
line-height
|
||||
float
|
||||
clear
|
||||
|
||||
===== Pseudo-elements and CSS Classes =====
|
||||
|
||||
Pseudo-elements can be combined with CSS classes:
|
||||
|
||||
p.article:first-letter {color:#ff0000;}
|
||||
|
||||
<p class="article">A paragraph in an article</p>
|
||||
|
||||
The example above will display the first letter of all paragraphs with class="article", in red.
|
||||
|
||||
===== Multiple Pseudo-elements =====
|
||||
|
||||
Several pseudo-elements can also be combined.
|
||||
|
||||
In the following example, the first letter of a paragraph will be red, in an xx-large font size. The rest of the first line will be blue, and in small-caps. The rest of the paragraph will be the default font size and color:
|
||||
|
||||
=== Example ===
|
||||
p:first-letter
|
||||
{
|
||||
color:#ff0000;
|
||||
font-size:xx-large;
|
||||
}
|
||||
p:first-line
|
||||
{
|
||||
color:#0000ff;
|
||||
font-variant:small-caps;
|
||||
}
|
||||
|
||||
**PS:对p用多个伪元素**
|
||||
|
||||
===== CSS - The :before Pseudo-element =====
|
||||
|
||||
The ":before" pseudo-element can be used to** insert some content before the content of an element**.
|
||||
|
||||
**PS:**插入的内容将作为原来元素内容的一部分
|
||||
|
||||
The following example inserts an image before each <h1> element:
|
||||
|
||||
==== Example ====
|
||||
h1:before
|
||||
{
|
||||
__content:__url(smiley.gif);
|
||||
}
|
||||
|
||||
===== CSS - The :after Pseudo-element =====
|
||||
|
||||
The ":after" pseudo-element can be used to insert some content after the content of an element.
|
||||
|
||||
**PS:**插入的内容将作为原来元素内容的一部分,如:
|
||||
dir:after {
|
||||
content:"the appended line"
|
||||
}
|
||||
字符串"the appended line"将作为div内部内容的一部分而被div包含,这种特性可以用来enclose a floated element。
|
||||
{{../float/How_to_completely_enclose_a_floated_element_in_CSS2/pesudo-of-after.png?width=600}}
|
||||
如上图所示,“The append text”包含在dvi的空间内。
|
||||
|
||||
The following example inserts an image after each <h1> element:
|
||||
Example
|
||||
h1:after
|
||||
{
|
||||
content:url(smiley.gif);
|
||||
}
|
||||
|
||||
|
||||
|
||||
===== All CSS Pseudo Classes/Elements =====
|
||||
**Selector Example Example description**
|
||||
:link a:link Selects all unvisited links
|
||||
:visited a:visited Selects all visited links
|
||||
:active a:active Selects the active link
|
||||
:hover a:hover Selects links on mouse over
|
||||
:focus input:focus Selects the input element which has focus
|
||||
:first-letter p:first-letter Selects the first letter of every <p> element
|
||||
:first-line p:first-line Selects the first line of every <p> element
|
||||
:first-child p:first-child Selects every <p> elements that is the first child of its parent
|
||||
:before p:before Insert content before every <p> element
|
||||
:after p:after Insert content after every <p> element
|
||||
:lang(language) p:lang(it) Selects every <p> element with a lang attribute value starting with "it"
|
||||
56
Zim/Web-Design/CSS单位.txt
Normal file
@@ -0,0 +1,56 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-13T21:09:35+08:00
|
||||
|
||||
====== CSS单位 ======
|
||||
Created Friday 13 May 2011
|
||||
|
||||
===== 长度单位 =====
|
||||
一个长度的值由可选的正号" + "或负号" - "、接着的一个数字、还有标明单位的两个字母组成。在**一个长度的值之中是没有空格**的,例如,1.3 em就不是一个有效的长度的值,但1.3em就是有效的。一个为零的长度不需要两个字母的单位声明。
|
||||
|
||||
无论是相对值还是绝对值长度,CSS1都支持。**相对值单位确定一个相对于另一长度属性的长度**,因为它能更好地适应不同的媒体,所以是首选的。以下是有效的相对单位:
|
||||
|
||||
em (em,元素的字体的高度)
|
||||
ex (x-height,字母 "x" 的高度)
|
||||
px (像素,相对于屏幕的分辨率)
|
||||
绝对长度单位视输出介质而定,所以逊色于相对单位。以下是有效的绝对单位:
|
||||
in (英寸,1英寸=2.54厘米)
|
||||
cm (厘米,1厘米=10毫米)
|
||||
mm (米)
|
||||
pt (点,1点=1/72英寸)
|
||||
pc (帕,1帕=12点)
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
===== 百分比单位 =====
|
||||
一个百分比值由可选的正号"+"或负号"-"、接着的一个数字,还有百分号"%"。在一个百分比值之中是没有空格的。
|
||||
百分比值是**相对于其它数值**,同样地用于定义每个属性。最经常使用的百分比值是**相对于元素的字体大小**。
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
===== 颜色单位 =====
|
||||
颜色值是一个关键字或一个RGB格式的数字。
|
||||
Windows VGA(视频图像阵列)形成了16各关键字: aqua,black, blue,fuchsia,gray,green, lime,maroon,navy,olive, purple,red,silver,teal,white,and yellow。
|
||||
|
||||
RGB颜色可以有四种形式:
|
||||
#rrggbb (如,#00cc00)
|
||||
#rgb (如,#0c0)
|
||||
rgb(x,x,x) x是一个介乎0到255之间的整数 (如,rgb(0,204,0))
|
||||
rgb(y%,y%,y%) y是一个介乎0.0到100.0之间的整数 (如,rgb(0%,80%,0%))
|
||||
上述的例子指定同一颜色。
|
||||
Douglas R. Jacobson先生还开发了速查手册RGB Color Chart (61 kB)。
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
===== 统一资源管理URLs =====
|
||||
一个URL值的格式为 : __url(foo)__,foo是一个URL(统一资源管理,因特网的地址)。URL可以选择用单引号( ' )或者双引号( " ),并且,在URL之前或之后可以包含空格。
|
||||
在URL中的括弧,逗号,空格,单引号,或双引号必须避开反斜杠。**不完整的URLs被理解为样式表的源代码**,而不是HTML源代码。
|
||||
注意: Netscape Navigator 4.x 会错误地将不完整的URLs理解为相关的HTML源代码。注意到这个错误后,网页制作者应该在可能的地方使用完整的URLs。
|
||||
例如:
|
||||
|
||||
BODY { background: url(stripe.gif) }
|
||||
BODY { background: url(http://www.htmlhelp.com/stripe.gif) }
|
||||
BODY { background: url( stripe.gif ) }
|
||||
BODY { background: url("stripe.gif") }
|
||||
BODY { background: url(\"Ulalume\".png) } /* quotes in URL escaped */
|
||||
|
||||
|
||||
|
||||
73
Zim/Web-Design/CSS单位/2.txt
Normal file
@@ -0,0 +1,73 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-13T21:30:44+08:00
|
||||
|
||||
===== CSS中常用的单位 =====
|
||||
Created Friday 13 May 2011
|
||||
http://blog.csdn.net/mdjlw/archive/2006/01/03/569633.aspx
|
||||
|
||||
===== 一、长度单位 =====
|
||||
|
||||
长度单位是Web页设计中最常用的一个单位。一个排列无序、杂乱无章的页面不可能给人们留下什么好的印象。于是,在设计的时候需要为元素的位置、尺寸精确地定义一些值,以使其达到预期的效果。
|
||||
CSS给予人们精确控制网页的能力,这一点为人们津津乐道。它允许人们定义**外观、尺寸、空间及其他的样式**。但是,CSS所给出的控制同时也是一个危险的东西,这不仅表现在设计者缺乏经验,更在于如何给出一个尺寸和空间值。为什么呢?因为一个设计者虽然能够决定某一个特殊的屏幕分辨率,但是不可能决定别人的大脑和别人的视力或者那些富有个性的自定义设置。
|
||||
CSS的主要功能之一就是CSS定位,这个定位的概念**即包括位置的定位,也包括尺寸的定位**。无论哪一种,都需要使用长度单位,不然,精确定位就无从谈起。
|
||||
在CSS中,长度是一种度量尺寸,用于宽度、高度、字号、字和字母间距、文本的缩排、行高、页边距、贴边、边框线宽以及许许多多的其他属性。
|
||||
|
||||
==== 1.定义长度 ====
|
||||
|
||||
在Dreamweaver 4中要定义长度,首先应该在所选择的选项后面的文本框中写符号部分,这个符号可以是“+”(正号),表示正长度值,也可以是“-”(负号),表示负长度值。如果不写符号,那么默认值是“+”。在符号后紧接着是一个数值,这个数值可以是整数,也可以是小数。然后再在该选项的长度单位下拉列表框中选择一种长度单位。**长度单位一般是一个由两个字母组成的单位缩写**,例如cm,pt,em等。
|
||||
|
||||
==== 2.绝对长度单位 ====
|
||||
|
||||
网页定义上常常使用的绝对长度值由厘米(cm)、毫米(mm)、英寸(in)、点(pt)、派卡(pc)等等。
|
||||
|
||||
单位 英寸(in) 厘米(cm) 毫米(mm) 磅(pt) 派卡(pc)
|
||||
英寸 1.0 2.54 25.4 72 6
|
||||
派卡 0.16667 0.4233 4.233 __12 __ 1.0
|
||||
厘米 0.3937 1 10 28.3464 4.7244
|
||||
毫米 0.03937 0.1 1.0 2.83464 0.47244
|
||||
磅 0.01389 0.0352806 0.352806 1.0 0.83333
|
||||
|
||||
绝对长度值的使用范围比较有限,只有在完全知道外部输出设备的具体情况下,才使用绝对长度值。也就是说,__绝对长度值最好用于打印机输出设备__,而在仅仅作为屏幕显示时,使用绝对长度值意义不大,应该尽量使用相对长度值。
|
||||
|
||||
==== 3.相对长度值 ====
|
||||
|
||||
每一个浏览器都有其自己默认的通用尺寸标准,这个标准可以由系统决定,也可以由用户按照自己的爱好进行设置。因此,这个默认值尺寸往往是用户觉得最适合的尺寸。__于是使用相对长度值,就可以是需要定义尺寸的元素按照默认大小为标准,相应地按比例缩放__。这样就不可能产生难以辨认的情况。其实,__百分比单位__以及关键字都能产生相类似的效果。
|
||||
|
||||
CSS还支持下列三种长度的相对单位:em(当前字体中字母M的宽度)、ex(当前字体中字母X的高度)、px(一个象素的大小)。
|
||||
|
||||
使用em和ex的目的就是为所给的字体设置合适的宽度,**而没有必要知道字体有多大**,在显示时,可通过比较当前字体中的M和X来确定。字体越大,所对应的em和ex也就越大。
|
||||
|
||||
以象素为单位的长度是相对于显示器上的象素(或许为方形)的高度和宽度。**影像图片的宽度和高度经常是以象素给出**的。__象素测量法通常不是个好方法__。首先,象素的大小依分辩率变化较大,大多数用户都会将显示器设置成尽可能高的分辩率,从而导致象素太小,而无法阅读(其实对于一个给定的分辨率,以像素为单位是一个绝对单位长度,例如**把body设为900px时,当缩放窗口时网页内容并不相应缩放**)。
|
||||
|
||||
==== 二、百分比单位 ====
|
||||
|
||||
在Dreamweaver 4中要使用百分比,首先应该在所选择的选项后面的文本框中写符号部分,这个符号可以是“+”(正号),表示正长度值,也可以是“—”(负号),表示负长度值。如果不写符号,那么默认值是“+”。在符号后紧接着是一个数值,符号后面可以输入任意值,但是由于在某些情况下,浏览器不能处理带小数的百分数,因此最好不用带小数的百分比。然后再在该选项的长度单位下拉列表框中选择“%”。
|
||||
百分比总是相对于另一个值来说的。那个值可以是长度单位或是其他的(取决于设置的属性或对象)。每一个可以使用百分比值单位指定的属性同时也自定义了这个百分比值的参照值。**大多数情况下,这个参照值是此元素父对象宽度或自身字体大小(自身没指定时,继承自父对象)**。
|
||||
|
||||
==== 三、颜色单位 ====
|
||||
|
||||
大量地使用图片可能会使网页富有生气。但是,每一个上过网的人都有为等待一个图片而焦急不安的经历。其实,**适当地在不同的部位使用不同的颜色**,也能起到类似图片的效果,把读者的注意力吸引到关键的部分,然而,下载网页的时间却大幅度地减少了。
|
||||
color属性用来定义一个元素的前景颜色,在大多数情况下,这个元素中所包含的使文本对象。使用color属性同时还可以用来决定一个元素边框的颜色。通用的定义颜色的语法是:color:颜色值。
|
||||
定义颜色值最简单也**最直接的方法是使用百分比值**。在这种情况下,红、绿、蓝颜色值的等级用百分比数来确定。格式是:color:rgb(R%,G%,B%)。使用百分比值来指定颜色还有一个好处是它能够声明一组真正的数字,不论它的值是多少。
|
||||
指定颜色的**另一种方法是使用范围在0~255之间的整数来设置**。格式是color:rgb(128,128,128)。
|
||||
定义颜色的**第三种方法是使用十六进制数组定义颜色**。这种定义的方法对于经常进行程序设计的人来说比较熟悉。定义颜色时使用三个前后按顺序排列的十六进制数组表示,例如“#FC0EA8”。这种定义的方式就是形如#RRGGBB的格式。即在红、绿、蓝的位置上添上需要的十六进制值。
|
||||
定义颜色**最后一种方法也最简单的方法是指定颜色的名称**。例如如下所示的代码指定文本的颜色为紫色。
|
||||
在Dreamweaver 4中,可以单击颜色选择器的图标,从打开的颜色选择器中选择一种合适的颜色。
|
||||
|
||||
==== 四、URL单位 ====
|
||||
|
||||
|
||||
URL单位和链接的地址有关。所谓URL就是“Uniform Resource Locator”的简写,链接是网页的灵魂。通过链接的方式可以使各个网页之间联接起来,使网站中众多的页面构成一个有机整体,使访问者能够在各个页面之间跳转。**链接可以是一段文本,一幅图像或其他网页元素**,当在浏览器中用鼠标单击这些对象时,浏览器可以根据其指示载入一个新的页面或者跳转到页面的其他位置。
|
||||
|
||||
在创建链接的过程中,路径是非常重要的。Dreamweaver 4中有两种路径:绝对路径和相对路径,其中相对路径可分为和__根目录相对的路径及和文档相对的路径__。
|
||||
|
||||
__绝对路径时含服务器协议__(在网页上通常是http://%E6%88%96ftp://)的完全路径。绝对路径包含的是精确位置而不用考虑源文档的位置。但是如果目标文档被移动,则链接无效。创建对当前站点以外文件的链接时必须使用绝对路径。
|
||||
|
||||
和根目录相对的路径__总是从当前站点的根目录开始__。站点上的所有可以公开的文件都存放在站点的根目录下。和根目录相对的路径使用斜杠告诉服务器从根目录开始。例如,/ Dreamweaver /index.html将链接到站点根目录Dreamweaver文件夹的index.html文件。如果要在内容经常被移动的环境中链接文件,那么使用和根目录相对的路径往往是最佳的方法。在使用与根目录相对的路径时,包含链接的文档在站点内移动,链接不会中断。但是,和根目录相对的路径和适合于本地查看站点,在这种情况下,可以使用和文档相对的路径。
|
||||
|
||||
注意:__当在浏览器中按照本地方式预览文件时,和根目录相对的路径所链接的内容不会出现__。这是因为浏览器不能像服务器那样识别站点根目录,要预览和根目录相对的路径所链接的内容,必须将文件放置到远程服务器并从那里进行查看。
|
||||
|
||||
和文档相对的路径是指和当前文档所在的文件夹相对的路径。例如文档test.swf在文件夹Flash中,它指定的就是当前文件夹内的文档。…/test.swf指定的则是当前文件夹上级目录中的文档;而/test/test.swf指定是 Flash文件夹下test文件夹中的test.swf文档。和文档相对的路径通常是最简单的路径,可以用来链接总是和当前文档在同一文件夹中的文件。
|
||||
|
||||
注意:在创建和文档相对的路径之前必须保存新文件,因为在没有定义起始点的情况下,和文档相对的路径是无效的。在文档保存之前,Dreamweaver 4会自动使用以File://开始的绝对路径。
|
||||
44
Zim/Web-Design/CSS单位/3.txt
Normal file
@@ -0,0 +1,44 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-13T21:33:56+08:00
|
||||
|
||||
====== 3 ======
|
||||
Created Friday 13 May 2011
|
||||
http://www.phpzixue.cn/detail270.shtml
|
||||
css长度单位(em)与em标签详解
|
||||
日期:2009-02-15 来自:互联网 浏览:1536
|
||||
|
||||
|
||||
在CSS中支持多种长度单位。它们可被分成两大类:绝对长度单位(以不依赖于显示设备的绝对尺寸来定义长度);相对长度(相对其它为浏览器所知的单位来定义长度)。
|
||||
|
||||
绝对长度度量可使用五种单位:英寸(in)、厘米(cm)、毫米(mm)、磅(point,写作pt)、字高(pica,写作pc)。磅和字高通常被用作印刷单位,其中1pica=12pt。CSS把1pica定义为1/72in,也就是说,72pica=1in。这也是高品质打印机常用的 Adobe postscript 语言所采用的定义。
|
||||
|
||||
CSS还支持以象素表示的“绝对”长度——象素(pixels)即为计算机显示屏上的一点。然而,由于象素密度和用户对显示器分辨率选择(同一显示屏幕可支持640*480的分辨率,也可支持1024*768的分辨率)的不同,象素的绝对大小会在不同显示器上有很大差异。这样,以象素表示的长度实际上与显示器有关。以象素作为计算机显示单位的优点在于象素是严格定义的单位。但是,当打印网络文档时,象素单位会带来问题。
|
||||
|
||||
象英寸和厘米这样的绝对长度单位用在打印排版时非常有用,因为它们能提供在固定大小的纸面上布局文档时所需要的绝对定位。也正因为这个原因,绝对长度不宜在电子显示文档中使用,这是因为在6inches*4inches和21inches对角显示屏之中的显示将有所不同,并无法保证在给定的显示屏上浏览器能用固定的窗口区域(用户可选择窗口的大小)来显示文档。考虑到这样的差异,使用能随显示区大小或文本字体大小而自动调整的单位是再恰当不过了。所幸的是,有三种CSS长度单位能实现这一行为。
|
||||
|
||||
相对长度度量可以有三种形式:em单位,ex单位和percentage(百分比)。em和ex单位相对于字体的大小来定义长度。em单位相对于实际字体的磅值来定义长度:这样,如果现在的字体大小为 12pt,那么1.5em=18pt。相反,ex单位则是相对于字体的x高度来定义长度:即相对于当前字体中字母“x”的高度。这样,一个单位的ex大小既取决于字体的大小,也取决于字体族类型,因为在给定的磅值下,实际的x高度将随字体族不同而不同。
|
||||
|
||||
目前来看,em单位比ex单位更为可靠:为了在不同浏览器之间获得最好的兼容性,最好还是使用em单位。但要注意的是,em单位和ex单位都会导致打印问题。
|
||||
|
||||
百分比单位为第三种相对单位。这一单位把长度定义为相关长度的百分比值。按照CSS规范,相关长度既可是父单元字体的大小,也可是父类格式单元的宽度 ——各种情况依问题中特性的不同而不同。有一个极其重要的警告:现有的浏览器并不是相对于单元宽度来计算百分比值,因而也就不能正确地实现百分比长度。相反,所有的浏览器都把和字体无关的百分比长度计算为整个浏览器窗口宽度的百分比值。
|
||||
|
||||
长度值的格式由一个符号('+'或'-',缺省时为 '+')紧跟一个数字再跟一个单位标示符(一个两个字符的缩写)。有两种长度单位形式:相对和绝对单位。样式表用相对单位更容易控制从一个媒介到另一个的缩放比例(如从电脑到激光打印机)。百分比单位和关键值(如 'x-large')也有同样的优点。如下:
|
||||
H1 { margin: 0.5em } 元素字体高度
|
||||
H1 { margin: 1ex } 字母 'x' 的高度
|
||||
|
||||
像素单位是相对于屏幕的图形分辨率。如果输出设备的像素密度与标准的计算机屏幕相差很多,用户将重新调整像素值。推荐的像素值是离读者一手臂长的距离用90dpi的像素密度。子元素继承计算结果值,而不是相对值,如:
|
||||
BODY {
|
||||
font-size: 12pt;
|
||||
text-indent: 3em;
|
||||
}
|
||||
H1 { font-size: 15pt }
|
||||
|
||||
在上例中,'H1' 的 'text-indent' 值是 36pt,而不是 45pt 。
|
||||
|
||||
em 标签 -- 强调标签
|
||||
|
||||
* em标签是成对出现的,以<em>开始,以</em>结束
|
||||
* 属性:
|
||||
* Common -- 一般属性
|
||||
* em是emphasis的缩写
|
||||
64
Zim/Web-Design/CSS单位/4.txt
Normal file
@@ -0,0 +1,64 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-13T21:44:59+08:00
|
||||
|
||||
====== 4 ======
|
||||
Created Friday 13 May 2011
|
||||
http://www.blabla.cn/css_tutorials/060_css_length_unit.html
|
||||
CSS长度单位参考
|
||||
|
||||
在CSS样式表中,我们经常会看到pt, px,em,ex,in等这类长度单位。它们各是什么意思,有什么区别呢?
|
||||
在CSS样式表中,长度单位分两种:
|
||||
相对长度单位,如px, em等
|
||||
绝对长度单位,如pt,mm等
|
||||
也谈px和pt的区别
|
||||
经常看到有人拿px和pt比较,主要是为了争辩在确定字体大小(font-size)或其它CSS属性大小时,用什么样的CSS长度单位更加好。有人说,用pt更好,因为pt是绝对长度单位,不会因为屏幕分辨率大小,或者其它因素而改变。
|
||||
我去做了一个测试,写了这样一个HTML例子。代码如下:
|
||||
<html>
|
||||
<head><title>CSS单位长度区别 - px和pt的区别</title></head>
|
||||
<body >
|
||||
<p style = "font-size:20pt;">Font-size is 20pt</p>
|
||||
<p style = "font-size:20px;">Font-size is 20px</p>
|
||||
</body>
|
||||
</html>
|
||||
点击浏览文件
|
||||
我将我的显示器分别调到1024*768和800*600的分辨率(指screen resolution)。不管是用pt还是用px设置的字体,都随着分辨率变化而变化。(我使用的浏览器是IE6,其它浏览器上尚未测试过。)
|
||||
我又写了另外一个HTML例子,测试一下cm(厘米)。代码如下:
|
||||
<html>
|
||||
<head><title>CSS长度单位的区别 - pt,px和cm的区别</title></head>
|
||||
<body >
|
||||
以下div宽度300pt,高度30pt: <br>
|
||||
<div style = "width:300pt;height:30pt;border:1px solid blue;"></div>
|
||||
以下div宽度300px,高度30px:<br>
|
||||
<div style = "width:300px;height:30px;border:1px solid blue;"></div>
|
||||
以下div宽度10cm,高度3cm: <br>
|
||||
<div style = "width:10cm;height:3cm;border:1px solid blue;"></div>
|
||||
</body>
|
||||
</html>
|
||||
点击浏览文件
|
||||
结果是,cm(厘米)也是随着显示器分辨率变化而变化的。
|
||||
对于计算机的屏幕设备而言,像素(Pixel)或者说px是一个最基本的单位,就是一个点。其它所有的单位,都和像素成一个固定的比例换算关系。所有的长度单位基于屏幕进行显示的时候,都统一先换算成为像素的多少,然后进行显示。所以,就计算机的屏幕而言,相对长度和绝对长度没有本质差别。任何单位其实都是像素,差别只是比例不同。
|
||||
如果把讨论扩展到其它输出设备,比如打印机,基本的长度单位可能不是像素,而是其它的和生活中的度量单位一致的单位了。
|
||||
CSS绝对长度单位是对于输出设备(output device)而言的。拿pt来说,这是一个在文字排版工具(word,adobe等)中非常常用的字体单位,不管你的显示器分辨率是1024*768,还是800*600,同一篇文档打印在纸面上的结果是一样的。
|
||||
写网页用哪个长度单位更好,是px还是pt呢?
|
||||
我个人比较偏向px,因为px能够精确地表示元素在屏幕中的位置和大小,网页主要是为了屏幕显示,而不是为了打印等其它需要的。
|
||||
CSS相对长度单位(relative length unit)
|
||||
CSS相对长度单位中的相对二字,表明了其长度单位会随着它的参考值的变化而变化,不是固定的。
|
||||
以下是CSS相对长度单位列表:
|
||||
CSS相对长度单位 说明
|
||||
em 元素的字体高度The height of the element's font
|
||||
ex 字母x的高度The height of the letter "x"
|
||||
px 像素Pixels
|
||||
% 百分比Percentage
|
||||
CSS绝对长度单位(absolute length unit)
|
||||
绝对长度单位是一个固定的值。比如我们常用的有mm,就是毫米的意思。
|
||||
以下是CSS绝对长度单位列表:
|
||||
CSS绝对长度单位 说明
|
||||
in 英寸Inches (1 英寸 = 2.54 厘米)
|
||||
cm 厘米Centimeters
|
||||
mm 毫米Millimeters
|
||||
pt 点Points (1点 = 1/72英寸)
|
||||
pc 皮卡Picas (1 皮卡 = 12 点)
|
||||
|
||||
作者或编者:布啦布啦 最近更新日期:2007-05-01
|
||||
参考来源:www.BlaBla.cn 布啦布啦网页教程与代码
|
||||
40
Zim/Web-Design/CSS单位/5.txt
Normal file
@@ -0,0 +1,40 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-13T22:04:53+08:00
|
||||
|
||||
====== 5 ======
|
||||
Created Friday 13 May 2011
|
||||
|
||||
在国内网站中,包括三大门户,以及“引领”中国网站设计潮流的蓝色理想,ChinaUI等都是使用了px作为字体单位。只有百度好歹做了个可调的表率。而在大洋彼岸,几乎所有的主流站点都使用em作为字体单位,也就是可调的。没错,px比em更加容易使用,大部分初学者不知道em为何物或者它相当于多少px。国外人士如此重视网站易用性(Accessibility),不仅因为其根生蒂固的人文精神,直接原因可能是因为有一部法律来约束他们—例如美国的Section 508,强制网站达到一定的易用性。
|
||||
|
||||
关键点:
|
||||
|
||||
1. IE无法调整那些使用px作为单位的字体大小;
|
||||
|
||||
2. 国外的大部分网站能够调整的原因在于其使用了em作为字体单位;
|
||||
|
||||
3. Firefox能够调整px和em,但是96%以上的中国网民使用IE浏览器(或内核)。
|
||||
|
||||
px像素(Pixel)。相对长度单位。像素px是相对于显示器屏幕分辨率而言的。
|
||||
|
||||
em是相对长度单位。**相对于父对象文本的字体尺寸**。如父对象文本的字体尺寸未被人为设置(注意有可能继承),则相对于浏览器的默认字体尺寸。
|
||||
|
||||
任意浏览器的__默认字体高都是16px__。所有未经调整的浏览器都符合: 1em=16px。那么12px=0.75em,10px=0.625em。为了简化font-size的换算,需要在css中的body选择器中声明**Font-size=62.5%**,这就使em值变为 16px*62.5%=10px, 这样12px=1.2em, 10px=1em, 也就是说只需要将你的原来的px数值除以10,然后换上em作为单位就行了。
|
||||
|
||||
em有如下特点:
|
||||
|
||||
1. em的值并不是固定的;
|
||||
|
||||
2. __em会继承父级元素的字体大小__。
|
||||
|
||||
所以我们在写CSS的时候,需要注意两点:
|
||||
|
||||
1. body选择器中声明Font-size=62.5%;
|
||||
|
||||
2. 将你的原来的px数值除以10,然后换上em作为单位;
|
||||
|
||||
3. 重新计算那些被放大的字体的em数值。避免字体大小的重复声明。
|
||||
|
||||
也就是避免1.2 * 1.2= 1.44的现象。比如说你在#content中声明了字体大小为1.2em,那么在声明p的字体大小时就只能是1em,而不是1.2em, 因为此em非彼em,它因继承#content的字体高而变为了1em=12px。
|
||||
|
||||
但是12px汉字例外,就是由以上方法得到的12px(1.2em)大小的汉字在IE中并不等于直接用12px定义的字体大小,而是稍大一点。这个问题 Jorux已经解决,只需在body选择器中把62.5%换成63%就能正常显示了。原因可能是IE处理汉字时,对于浮点的取值精确度有限。不知道有没有其他的解释。
|
||||
210
Zim/Web-Design/CSS样式简写方法总结.txt
Normal file
@@ -0,0 +1,210 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-15T20:37:37+08:00
|
||||
|
||||
====== CSS样式简写方法总结 ======
|
||||
Created Sunday 15 May 2011
|
||||
|
||||
http://www.tonjay.com/website/cssjianxie.html
|
||||
|
||||
在网上看到了一篇对CSS简写的总结文章,感觉总结的知识点比较全面。相信这些对于刚刚学习CSS的朋友确实是一篇不错的教程!因为我见过好多刚学CSS的周围朋友碰到简写的CSS就晕了,不知道是什么意思了,呵呵。而我的一些对CSS比较熟悉的朋友同事,也有些不太喜欢缩写。其实缩写的好处是大大的多的。一是CSS文件更小;二是也比较易懂(当你看到四个padding-left、right、top、bottom你就知道了)!废话少说,上“菜”喽!
|
||||
|
||||
__高效的css写法中的一条就是使用简写__。通过简写可以让你的CSS文件更小,更易读。而了解CSS属性简写也是前端开发工程师的基本功之一。今天我们系统地总结一下CSS属性的缩写。
|
||||
|
||||
===== 色彩缩写 =====
|
||||
|
||||
色彩的缩写最简单,在色彩值用16进制的时候,如果每种颜色的值相同,就可以写成一个:
|
||||
|
||||
color:#113366
|
||||
|
||||
可以简写为
|
||||
|
||||
color:#136
|
||||
|
||||
所有用到16进制色彩值的地方都可以使用简写,比如background-color、border-color、text-shadow、box-shadow等。
|
||||
|
||||
|
||||
|
||||
===== 盒子大小 =====
|
||||
|
||||
这里主要用于两个属性:margin和padding,我们以margin为例,padding与之相同。盒子有上下左右四个方向,每个方向都有个外边距:
|
||||
|
||||
margin-top:1px;
|
||||
margin-right:1px;
|
||||
margin-botton:1px;
|
||||
margin-left:1px;
|
||||
|
||||
这四个值可以缩写到一起:
|
||||
|
||||
margin:1px 1px 1px 1px;
|
||||
|
||||
缩写的顺序是上->右->下->左。顺时针的方向。相对的边的值相同,则可以省掉:
|
||||
|
||||
margin:1px;//四个方向的边距相同,等同于margin:1px 1px 1px 1px;
|
||||
|
||||
margin:1px 2px;//上下边距都为1px,左右边距均为2px,等同于margin:1px 2px 1px 2px
|
||||
|
||||
margin:1px 2px 3px;//右边距和左边距相同,等同于margin:1px 2px 3px 2px;
|
||||
|
||||
margin:1px 2px 1px 3px;//注意,这里虽然上下边距都为1px,但是这里不能缩写。
|
||||
|
||||
|
||||
|
||||
===== 边框(border) =====
|
||||
|
||||
border是个比较灵活的属性,它有border-width、border-style、border-color三个子属性。
|
||||
|
||||
border-width:数字+单位;
|
||||
border-style: none || hidden || dashed || dotted || double || groove || inset || outset || ridge || solid ;
|
||||
border-color: 颜色 ;
|
||||
|
||||
它可以按照width、style和color的顺序简写:
|
||||
|
||||
border:5px solid #369;
|
||||
|
||||
有的时候,border可以写的更简单些,有些值可以省掉,但是请注意哪些是必须的,你也可以测试一下:
|
||||
|
||||
border:groove red; //大家猜猜这个边框的宽度是多少?
|
||||
border:solid; //这会是什么样子?
|
||||
border:5px; //这样可以吗?
|
||||
border:5px red; //这样可以吗??
|
||||
border:red; //这样可以吗???
|
||||
|
||||
通过上面的代码可以了解到,border默认的宽度是3px,默认的色彩是black——黑色。默认的颜色是该规则中的color属性的值,而color默认是黑色的(多谢 @birdstudio 的提醒 )。border的缩写中border-style是必须的。
|
||||
|
||||
同时,还可以对每条边采用缩写:
|
||||
|
||||
border-top:4px solid #333;
|
||||
border-right:3px solid #666;
|
||||
border-bottom:3px solid #666;
|
||||
border-left:4px solid #333;
|
||||
|
||||
还可以对每个属性采用缩写:
|
||||
|
||||
border-width:1px 2px 3px; //最多可用四个值,缩写规则类似盒子大小的缩写,下同
|
||||
border-style:solid dashed dotted groove;
|
||||
border-color:red blue white black;
|
||||
|
||||
|
||||
|
||||
===== outline =====
|
||||
|
||||
outline类似border,不同的是border会影响盒模型,而outline不会。
|
||||
|
||||
outline-width:数字+单位;
|
||||
outline-style: none || dashed || dotted || double || groove || inset || outset || ridge || solid ;
|
||||
outline-color: 颜色 ;
|
||||
|
||||
可以缩写为:
|
||||
|
||||
outline:1px solid red;
|
||||
|
||||
同样,outline的简写中,outline-style也是必须的,另外两个值则可选,默认值和border相同。
|
||||
|
||||
|
||||
|
||||
===== 背景(background) =====
|
||||
|
||||
background是最常用的简写之一,它包含以下属性:
|
||||
|
||||
background-color: color || #hex || RGB(% || 0-255) || RGBa;
|
||||
background-image:url();
|
||||
background-repeat: repeat || repeat-x || repeat-y || no-repeat;
|
||||
background-position: X Y || (top||bottom||center) (left||right||center);
|
||||
background-attachment: scroll || fixed;
|
||||
|
||||
background的简写可以大大的提高css的效率:
|
||||
|
||||
background:#fff url(img.png) no-repeat 0 0;
|
||||
|
||||
background的简写也有些默认值:
|
||||
|
||||
background:transparent none repeat scroll top left ;
|
||||
|
||||
background属性的值不会继承,你可以只声明其中的一个,其它的值会被应用默认的。
|
||||
|
||||
|
||||
|
||||
===== font =====
|
||||
|
||||
font简写也是使用最多的一个,它也是书写高效的CSS的方法之一。
|
||||
|
||||
font包含以下属性:
|
||||
|
||||
font-style: normal || italic || oblique;
|
||||
font-variant:normal || small-caps;
|
||||
font-weight: normal || bold || bolder || || lighter || (100-900);
|
||||
font-size: (number+unit) || (xx-small – xx-large);
|
||||
line-height: normal || (number+unit);
|
||||
font-family:name,”more names”;
|
||||
|
||||
font的各个属性也都有默认值,记住这些默认值相对来说比较重要:
|
||||
|
||||
font-style: normal;
|
||||
font-variant:normal;
|
||||
font-weight: normal;
|
||||
font-size: inherit;
|
||||
line-height: normal;
|
||||
font-family:inherit;
|
||||
|
||||
事实上,font的简写是这些简写中最需要小心的一个,稍有疏忽就会造成一些意想不到的后果,所以,__很多人并不赞成使用font缩写__。
|
||||
|
||||
不过这里正好有个小手册,相信会让你更好的理解font的简写:
|
||||
{{./030336t77.jpg}}
|
||||
|
||||
|
||||
|
||||
===== 列表样式 =====
|
||||
|
||||
可能大家用的最多的一条关于列表的属性就是:
|
||||
|
||||
list-style:none
|
||||
|
||||
它会清除所有默认的列表样式,比如数字或者圆点。
|
||||
|
||||
list-style也有三个属性:
|
||||
|
||||
list-style-type:none || disc || circle || square || decimal || lower-alpha || upper-alpha || lower-roman || upper-roman
|
||||
list-style-position: inside || outside || inherit
|
||||
list-style-image: (url) || none || inherit
|
||||
|
||||
list-style的默认属性如下:
|
||||
|
||||
list-style:disc outside none
|
||||
|
||||
需要注意的是,如果list-tyle中定义了图片,那么图片的优先级要比list-style-type高,比如:
|
||||
|
||||
list-style:circle inside url(../img.gif)
|
||||
|
||||
这个例子中,如果img.gif存在,则不会显示前面设置的circle符号。
|
||||
|
||||
PS:其实list-style-type有很多种很有用的样式,感兴趣的同学可以参考一下:https://developer.mozilla.org/en/CSS/list-style-type
|
||||
|
||||
|
||||
|
||||
===== border-radius(圆角半径) =====
|
||||
|
||||
**border-radius是css3中新加入的属性**,用来实现圆角边框。这个属性目前不好的一点儿是,各个浏览器对它的支持不同,IE尚不支持,Gecko(firefox)和webkit(safari/chrome)等需分别__使用私有前缀-moz-和-webkit-__。更让人纠结的是,如果单个角的border-radius属性的写法在这两个浏览器的差异更大,你要书写大量的私有属性:
|
||||
|
||||
-moz-border-radius-bottomleft:6px;
|
||||
-moz-border-radius-topleft:6px;
|
||||
-moz-border-radius-topright:6px;
|
||||
-webkit-border-bottom-left-radius:6px;
|
||||
-webkit-border-top-left-radius:6px;
|
||||
-webkit-border-top-right-radius:6px;
|
||||
border-bottom-left-radius:6px;
|
||||
border-top-left-radius:6px;
|
||||
border-top-right-radius:6px;
|
||||
|
||||
呃,是不是你已经看的眼花了?这只是要实现左上角不是圆角,其它三个角都是圆角的情况。所以对于border-radius,神飞强烈建议使用缩写:
|
||||
|
||||
-moz-border-radius:0 6px 6px;
|
||||
-webkit-border-radius:0 6px 6px;
|
||||
border-radius:0 6px 6px;
|
||||
|
||||
这样就简单了很多。PS:不幸的是,最新的Safari(4.0.5)还不支持这种缩写… (thanks @fireyy)
|
||||
|
||||
就总结这么多,还有其它的可以缩写的属性吗?欢迎大家提出一起讨论。
|
||||
|
||||
源地址:http://www.qianduan.net/css-font-shorthand-attribute-handbook.html
|
||||
|
||||
BIN
Zim/Web-Design/CSS样式简写方法总结/030336t77.jpg
Normal file
|
After Width: | Height: | Size: 26 KiB |
77
Zim/Web-Design/CSS框属性Display详解.txt
Normal file
@@ -0,0 +1,77 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-15T22:05:38+08:00
|
||||
|
||||
====== CSS框属性Display详解 ======
|
||||
Created Sunday 15 May 2011
|
||||
http://www.tonjay.com/website/display.html
|
||||
在正常的网页设计中,我门经常会遇到display,那么它到底有什么作用呢,这里给大家分享它的详细css教程:display 属性规定元素应该生成的框的类型。
|
||||
|
||||
说明:
|
||||
|
||||
这个属性用于定义建立布局时元素生成的显示框类型。对于 HTML 等文档类型,如果使用 display 不谨慎会很危险,因为可能违反 HTML 中已经定义的显示层次结构。对于 XML,由于 XML 没有内置的这种层次结构,所有 display 是绝对必要的。注释:CSS2 中有值 compact 和 marker,不过由于缺乏广泛的支持,已经从 CSS2.1 中去除了。
|
||||
|
||||
默认值: inline
|
||||
|
||||
继承性: no
|
||||
|
||||
版本: CSS1
|
||||
|
||||
JavaScript 语法: object.style.display=”inline”
|
||||
|
||||
实例:
|
||||
|
||||
使段落生出行内框:
|
||||
|
||||
p.inline{display:inline;}
|
||||
|
||||
浏览器支持:
|
||||
|
||||
所有主流浏览器都支持 display 属性。
|
||||
|
||||
注释:任何版本的 Internet Explorer (包括 IE8)都不支持 “inherit”、”inline-table”、”run-in”、”table”、”table-caption”、”table-cell”、”table-column”、”table-column-group”、”table-row”、以及 “table-row-group” 属性值。
|
||||
|
||||
Display值描述:
|
||||
|
||||
none 此元素不会被显示。
|
||||
|
||||
block 此元素将显示为块级元素,此元素前后会带有换行符。(Tonjay.com注:即如果没有浮动的话,应该此值的元素会占用一个行)
|
||||
|
||||
inline 默认。此元素会被显示为内联元素,元素前后没有换行符。(Tonjay.com注:Ie 6 下左浮动双倍边距的Bug即用此属性解决)
|
||||
|
||||
inline-block 行内块元素。(CSS2.1 新增的值)(Tonjay.com注:即将控制应用此值的元素形成一个块级元素并在一个行内!)
|
||||
|
||||
list-item 此元素会作为列表显示。
|
||||
|
||||
run-in 此元素会根据上下文作为块级元素或内联元素显示。
|
||||
|
||||
compact CSS 中有值 compact,不过由于缺乏广泛支持,已经从 CSS2.1 中删除。
|
||||
|
||||
marker CSS 中有值 marker,不过由于缺乏广泛支持,已经从 CSS2.1 中删除。
|
||||
|
||||
table 此元素会作为块级表格来显示(类似),表格前后带有换行符。
|
||||
|
||||
inline-table 此元素会作为内联表格来显示(类似),表格前后没有换行符。
|
||||
|
||||
table-row-group 此元素会作为一个或多个行的分组来显示(类似)。
|
||||
|
||||
table-header-group 此元素会作为一个或多个行的分组来显示(类似)。
|
||||
|
||||
table-footer-group 此元素会作为一个或多个行的分组来显示(类似)。
|
||||
|
||||
table-row 此元素会作为一个表格行显示(类似)。
|
||||
|
||||
table-column-group 此元素会作为一个或多个列的分组来显示(类似)。
|
||||
|
||||
table-column 此元素会作为一个单元格列显示(类似)
|
||||
|
||||
table-cell 此元素会作为一个表格单元格显示(类似 和 )
|
||||
|
||||
table-caption 此元素会作为一个表格标题显示(类似)
|
||||
|
||||
inherit 规定应该从父元素继承 display 属性的值。
|
||||
|
||||
示例:
|
||||
|
||||
img { disply: block; float: right; }
|
||||
|
||||
7
Zim/Web-Design/HTML5.txt
Normal file
@@ -0,0 +1,7 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-01T18:17:52+08:00
|
||||
|
||||
====== HTML5 ======
|
||||
Created Sunday 01 May 2011
|
||||
|
||||
85
Zim/Web-Design/HTML5/Default_style_sheet_for_HTML_4.txt
Normal file
@@ -0,0 +1,85 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-01T21:03:18+08:00
|
||||
|
||||
====== Default style sheet for HTML 4 ======
|
||||
Created Sunday 01 May 2011
|
||||
|
||||
html, address,
|
||||
blockquote,
|
||||
body, dd, div,
|
||||
dl, dt, fieldset, form,
|
||||
frame, frameset,
|
||||
h1, h2, h3, h4,
|
||||
h5, h6, noframes,
|
||||
ol, p, ul, center,
|
||||
dir, hr, menu, pre { display: block; unicode-bidi: embed }
|
||||
li { display: list-item }
|
||||
head { display: none }
|
||||
table { display: table }
|
||||
tr { display: table-row }
|
||||
thead { display: table-header-group }
|
||||
tbody { display: table-row-group }
|
||||
tfoot { display: table-footer-group }
|
||||
col { display: table-column }
|
||||
colgroup { display: table-column-group }
|
||||
td, th { display: table-cell }
|
||||
caption { display: table-caption }
|
||||
th { font-weight: bolder; text-align: center }
|
||||
caption { text-align: center }
|
||||
body { margin: 8px }
|
||||
h1 { font-size: 2em; margin: .67em 0 }
|
||||
h2 { font-size: 1.5em; margin: .75em 0 }
|
||||
h3 { font-size: 1.17em; margin: .83em 0 }
|
||||
h4, p,
|
||||
blockquote, ul,
|
||||
fieldset, form,
|
||||
ol, dl, dir,
|
||||
menu { margin: 1.12em 0 }
|
||||
h5 { font-size: .83em; margin: 1.5em 0 }
|
||||
h6 { font-size: .75em; margin: 1.67em 0 }
|
||||
h1, h2, h3, h4,
|
||||
h5, h6, b,
|
||||
strong { font-weight: bolder }
|
||||
blockquote { margin-left: 40px; margin-right: 40px }
|
||||
i, cite, em,
|
||||
var, address { font-style: italic }
|
||||
pre, tt, code,
|
||||
kbd, samp { font-family: monospace }
|
||||
pre { white-space: pre }
|
||||
button, textarea,
|
||||
input, select { display: inline-block }
|
||||
big { font-size: 1.17em }
|
||||
small, sub, sup { font-size: .83em }
|
||||
sub { vertical-align: sub }
|
||||
sup { vertical-align: super }
|
||||
table { border-spacing: 2px; }
|
||||
thead, tbody,
|
||||
tfoot { vertical-align: middle }
|
||||
td, th, tr { vertical-align: inherit }
|
||||
s, strike, del { text-decoration: line-through }
|
||||
hr { border: 1px inset }
|
||||
ol, ul, dir,
|
||||
menu, dd { margin-left: 40px }
|
||||
ol { list-style-type: decimal }
|
||||
ol ul, ul ol,
|
||||
ul ul, ol ol { margin-top: 0; margin-bottom: 0 }
|
||||
u, ins { text-decoration: underline }
|
||||
br:before { content: "\A"; white-space: pre-line }
|
||||
center { text-align: center }
|
||||
:link, :visited { text-decoration: underline }
|
||||
:focus { outline: thin dotted invert }
|
||||
|
||||
/* Begin bidirectionality settings (do not change) */
|
||||
BDO[DIR="ltr"] { direction: ltr; unicode-bidi: bidi-override }
|
||||
BDO[DIR="rtl"] { direction: rtl; unicode-bidi: bidi-override }
|
||||
|
||||
*[DIR="ltr"] { direction: ltr; unicode-bidi: embed }
|
||||
*[DIR="rtl"] { direction: rtl; unicode-bidi: embed }
|
||||
|
||||
@media print {
|
||||
h1 { page-break-before: always }
|
||||
h1, h2, h3,
|
||||
h4, h5, h6 { page-break-after: avoid }
|
||||
ul, ol, dl { page-break-before: avoid }
|
||||
}
|
||||
489
Zim/Web-Design/HTML5/HTML_5设计原理.txt
Normal file
@@ -0,0 +1,489 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-01T18:18:19+08:00
|
||||
|
||||
====== HTML 5设计原理 ======
|
||||
Created Sunday 01 May 2011
|
||||
http://developer.51cto.com/art/201103/247880.htm
|
||||
|
||||
Jeremy Keith在 Fronteers 2010 上的主题演讲
|
||||
|
||||
下载PPT(PDF) http://adactio.com/extras/slides/designofhtml5.pdf
|
||||
|
||||
观看视频 http://fronteers.nl/congres/2010/sessions/the-design-of-html5-jeremy-keith
|
||||
|
||||
|
||||
今天我想跟大家谈一谈HTML 5的设计。主要分两个方面:一方面,当然了,就是HTML 5。我可以站在这儿只讲HTML 5,但我并不打算这样做,因为如果你想了解HTML 5的话,你可以Google,可以看书,甚至可以看规范。
|
||||
|
||||
实际上,确实有人会谈到规范的内容。史蒂夫·福克纳(Steve Faulkner)会讲HTML 5与可访问性。而保罗·艾里什(Paul Irish)则会讲HTML 5提供的各种API。因此,我今天站在这里,不会光讲一讲HTML 5就算完事了。
|
||||
|
||||
说老实话,在正式开始之前,我想先交待清楚我所说的HTML 5到底是什么意思。这话听起来有点搞笑:这会子你一直在说HTML 5,难道我们还不知道什么是HTML 5吗?大家知道,有**一个规范,它的名字叫HTML 5**。我所说的HTML 5,指的就是这个规范。但问题是,有些人所说的HTML 5,指的不仅仅是这个规范,还有别的意思。比如说,用HTML 5来代指CSS3就是一种常见的叫法。我可不是这样的。我所说的HTML 5,不包含CSS3,就是HTML 5。
|
||||
|
||||
类似的术语问题以前也有过。Ajax本来是一种含义明确的技术,但过了不久,它的含义就变成了“**用JavaScript来做一切好玩的东西”。这就是Ajax**,对不对?今天,HTML 5也面临同样的问题,它本来指的是一个特定的规范,但如今含义却成了“在Web上做一切好玩的事。”我说的不是这种HTML 5,不是这种涵盖了最近刚刚出现的各种新东东的HTML 5。我说的仅仅是规范本身:HTML 5。
|
||||
|
||||
刚才已经说了,我今天想要讲的内容不多,也没有打算介绍HTML 5都包含什么。今天我要讲的是它的另一方面,即**HTML 5的设计**。换句话说,我要讲的不是规范里都包含什么,而是**规范里为什么会包含它们**,以及在设计这个规范的时候,设计者们是怎么看待这些东西的。
|
||||
|
||||
===== 设计原理 =====
|
||||
|
||||
**设计原理本质上是一种信念、一种想法、一个概念,是你行动的支柱。不管你是制定规范,还是制造一种有形的物品,或者编写软件,甚至发明编程语言。**你都能找到背后的一个或者多个设计原理,多人协作的任何成果都是例证。不仅仅Web开发领域是这样。纵观人类历史,像国家和社会这样大规模的构建活动背后,同样也有设计原理。
|
||||
|
||||
就拿美国为例吧,美国的设计原理都写在了《独立宣言》中了。
|
||||
|
||||
我们认为这些真理是不言而喻的,人人生而平等,造物主赋予了每个人不可剥夺的权利,包括生存、自由和追求幸福。
|
||||
|
||||
这里有一句口号:生存、自由和追求幸福。这是被写进宪法中的核心理念,它关系到我们所有人的一切,也就是我们构建自己社会的原则。
|
||||
|
||||
还有一个例子,就是卡尔·马克思(Karl Marx),他的著作在20世纪曾被奉为建设社会主义的圭臬。其基本思想大致可以归结为下面这条设计原理:
|
||||
|
||||
各尽所能,各取所需。
|
||||
|
||||
这其实就是一种经济体系背后的设计原理。
|
||||
|
||||
还有一个例子,比前面两个的历史更久远一些,不过大同小异:
|
||||
|
||||
人人为我,我为人人。
|
||||
|
||||
这个极为简单的设计原理,是两千年前的拿撒勒犹太人耶稣基督提出来的。而这条原则成为了后来许多宗教的核心教义。**原理与实践有时候并不是同步的**。
|
||||
|
||||
下面是小说中的一个例子。英国小说家乔治·奥威尔(George Orwell)笔下的《动物庄园》,就是在一条设计原理的基础上构建起来的虚拟社会。这条设计原理是:
|
||||
|
||||
四条腿的都是好人,两条腿的都是坏蛋!
|
||||
|
||||
《动物庄园》中有意思的是,随着社会的变迁——变得越来越坏,这条设计原理也跟着发生了改变,变成了“四条腿的都是好人,两条腿的就更好了。”最关键的是,即使是在虚构的作品里,设计原理都是存在的。
|
||||
|
||||
还有一套虚构的作品是以三条设计原理为基础构建起来的,那就是美国著名小说家艾萨克·阿西莫夫(Issac Asimov)的机器人经典系列。**阿西莫夫发明了机器人学这个术语**,并提出了机器人学三大法则,然后在这三个简单的设计原理基础上创作了一系列经典作品——大约有50本书。无论作品的情节如何变化,实际上都是从不同的角度来阐释这三大设计原理。我想,在座各位对机器人三大法则都不应该陌生。
|
||||
|
||||
机器人不得伤害人类,或袖手旁观人类受伤害。
|
||||
|
||||
机器人必须服从人类命令,除非命令违反第一法则。
|
||||
|
||||
机器人必须自卫,只要不违背第一和第二法则。
|
||||
|
||||
这些恐怕是第一次出现在小说中的针对软件的设计原理了。虽然基于这三个设计原理的软件运行在虚构的机器人的“正电子脑”中,但我想这应该是软件设计原理的事实开端。从此以后,我们才看到大量优秀软件背后的设计原理。
|
||||
|
||||
**蒂姆·伯纳斯-李(Tim Berners-Lee),Web的发明者**,在W3C的网站上发表过一份文档,其中有一个URL给出了他自己的一套设计原理。这些设计原理并不那么容易理解,不仅多,而且随着时时间推移,他还会不断补充、修改和删除。不过我还是觉得把自己认同的设计原理写出来放在某个地方真是个不错的主意。
|
||||
|
||||
实际上,**CSS的发明人之一伯特·波斯(Bert Bos)**,也在W3C的网站上放着一份文档,其中讲的都是基本的设计原理,比如怎样设计并构建一种格式,无论是CSS还是其他格式。推荐大家看一看。
|
||||
|
||||
只要你在W3C的站点中随便找一找,就可以发现非常多的这种设计原理,包括蒂姆·伯纳斯-李个人的。当然,你还会看到他从软件工程学校里借用的一些口号:分权(decentalisation)、容忍(tolerance)、简易(simplicity)、模块化(modularity)。这些都是在他发明新格式的时候,头脑中无时无刻不在想的那些关键词。
|
||||
|
||||
在座各位对蒂姆·伯纳斯-李的贡献都是非常熟悉的,因为大家每天都在用。他发明了Web,与罗伯特·卡里奥(Robert Cailliau)共同发明了Web,而且在发明Web的同时,也发明了我们每天都在Web上使用的语言。当然,这门语言就是HTML:超文本标记语言。
|
||||
|
||||
===== HTML =====
|
||||
|
||||
**HTML最早是从2.0版开始的。从来就没有1.0版**。如果有人告诉你说,他最早是从HTML 1.0开始使用HTML的,那他绝对是在忽悠你。从前确实有一个名叫HTML Tags的文档,其中的部分标签一直用到现在,但那个文档并非官方的规范。
|
||||
|
||||
使用标签、尖括号、p或h1,等等,并不是蒂姆·伯纳斯-李首创的想法。当时的__SGML__里就有了这些概念,而且当时的CERN(Conseil Europeen pour la Recherche Nucleaire,欧洲核子研究委员会)也在使用SGML的一个特定的版本。也就是说,即便在那个时代,他也没有白手起家;这一点在HTML后来的发展过程中也体现了出来:**继往开来、承前启后,而不是另立门户、从头开始**。
|
||||
|
||||
换句话说,这篇名为**HTML Tags的文档可以算作HTML的第一个版本,但它却不是一个正式的版本**。第一个正式版本,HTML 2.0,也不是出自W3C之手。**HTML 2.0是由IETF,因特网工程任务组(Internet Engineering Task Force)制定的**。在W3C成立之前,IETF已经发布了不少标准。但从第三个版本开始往后,**W3C,万维网联盟(World Wide Web Consortium)**开始接手,并负责后续版本的制定工作。
|
||||
|
||||
20世纪九十年代HTML有过几次快速的发展。众所周知,在那个时代要想构建网站,可是一项十分复杂的工程。**浏览器大战**曾令人头疼不已。市场竞争的结果就是各家浏览器里都塞满了各种专有的特性,都试图在专有特性上胜人一筹。当时的混乱程度不堪回首,HTML到底还重不重要,或者它作为Web格式的前景如何,谁都说不清楚。
|
||||
|
||||
从1997年到1999年,HTML的版本从3.2到4.0到4.01,经历了非常快的发展。问题是到了4.01的时候,W3C的认识发生了倒退,他们说“好了,这个版本就这样了,HTML也就这样了;**HTML 4.01是HTML的最后一个版本了**,我们用不着HTML工作组了。”
|
||||
|
||||
W3C并没有停止开发这门语言,只不过他们对HTML不再感兴趣了。**在HTML 4.01之后,他们提出了XHTML 1.0**。虽然听起来完全不同,但**XHTML 1.0与HTML 4.01其实是一样的**。我的意思是说,从字面上看这两个规范的内容是一样的,词汇表是一样的,所有的元素是一样,所有的属性也都是一样的。唯一一点不同之处,就是**XHTML 1.0要求使用XML语法**。也就是说,所有属性都必须使用小写字母,所有元素也必须使用小写字母,所有属性值都必须加引号,你还得记着使用结束标签,记着对img和br要使用自结束标签。
|
||||
|
||||
从规范本身的内容来看,实际上是相同的,没有什么不同。**不同之处就是编码风格**,因为对浏览器来说,读取符合HTML 4.01、HTML 3.2,或者XHTML 1.0规范的网页都没有问题,对浏览器来说这些网页都是一样的,都会生成相同的DOM树。只不过人们会比较喜欢XHTML 1.0,因为不少人认同它比较严格的编码风格。
|
||||
|
||||
到了2000年,Web标准项目(Web Standards Project)的活动开展得如火如荼,开发人员对浏览器里包含的那些乱七八糟的专有特性已经忍无可忍了。大家都很生气,就骂那些浏览器厂商“遵守个规范就他妈的真有那么难吗?”当时CSS有了长足的发展,而且与XHTML 1.0结合得也很紧密,**CSS加XHTML 1.0基本上就可以算是“最佳实践”了**。虽然在我看来HTML 4.01与XHTML 1.0没有本质上的不同,但大家都接受了。专业的开发人员能做到元素全部小写,属性全部小写,属性值也全部加引号:由于专业人员起到了模范带头作用,越来越多的人也都开始支持这种语法。
|
||||
|
||||
我就是一个例子!过去的10年,我一直都使用XHTML 1.0文档类型,原因是这样一来**验证器就能给我帮上很大的忙**,对不对?只要我写的是XHTML 1.0,然后用验证器测试,它就能告诉我是不是忘了给属性值加引号,是不是没有结束某个标签,等等等等。而如果我写的是HTML 4.01,同样的问题就变成了有效的了,验证器就不一定会提醒我了。
|
||||
|
||||
这就是我一直使用XHTML 1.0的原因。我估计很多人都……使用XHTML 1.0的朋友,请把手举起来。好的。HTML 4.01呢?人少多了。一直没有举手的呢,大声点,你们用什么?HTML 5,也很好!更早的呢,还有人使用更早的文档类型吗?没有了?
|
||||
|
||||
10年来我一直使用XHTML 1.0,就是因为验证器能够真正帮到我。有人用XHTML 1.1吗?你知道有人用吗?请举手,别放下。有人把网页标记为XML文档吗?有吗?那你们使用的就不是XHTML 1.1。
|
||||
|
||||
这就是个大问题。XHTML 1.0之后是XHTML 1.1,只是小数点后面的数字加了一个1,而且从词汇表的角度看,规范本身没有什么新东西,元素也都相同,属性也都相同。但**对XHTML 1.1来说,唯一的变化是你必须把自己的文档标记为XML文档**。在使用XHTML 1.0的时候,还可以把文档标记为HTML,而我们也正是这样做的,否则把文档标记为XML没准真会把人逼疯的。
|
||||
|
||||
为什么这么说呢?首先,把文档标记为XML后,Internet Explorer不能处理。当然,IE9是可以处理了。恐怕有人会讲“真是太可爱了”,他们到现在居然都没有忘了这件事。这艘船终于靠岸了!不过那时候,作为全球领先的浏览器,IE无法处理接收到的XML文档类型的文档,而规范又要求你以XML文档类型来发送文档,这不把人逼疯才怪呢。
|
||||
|
||||
所以说**XHTML 1.1有点脱离现实**,而你__不想把文档以XML格式发送给那些能够理解XML的浏览器,则是因为XML的错误处理模型__。XML的语法,无论是属性小写,元素小写,还是始终要给属性值加引号,这些都没有问题,都很好,事实上我也喜欢这样做,但XML的错误处理模型却是这样的:__解析器如果遇到错误,停止解析__。规范里就是这么写的。如果你把XHTML 1.1标记为XML文档类型,假设你用Firefox打开这个文档,而文档中有一个和号(&)没有正确编码,就算整个页面中就这一处错误,你看到的也将是黄屏,浏览器死掉了。Firefox会说:“没戏了,页面中有一个错误,你看不到这个网页了。”根据XML规范,这样处理是正确的,对Firefox而言,遇到错误就停止解析,并且不呈现其他任何内容是严格按照XML规范做的。因为它不是HTML,HTML根本就没有错误处理模型,但根据XML规范,这样做没错。
|
||||
|
||||
这就是为什么你不会把文档标记为XML的另一个原因。接下来,新的版本是XHTML 2,大家注意后面没有日期,因为这个规范并没有完成。
|
||||
|
||||
现在就说说XHTML 2,我很愿意把问题说清楚,XHTML 2实际上真是一个非常非常好的规范,确实非常好……从理论的角度来说。我的意思是说,制定这个规范的人都是非常非常有头脑的。直说吧,领导制定这个规范的家伙是斯蒂芬·彭伯顿(Stephen Pemberton),他应该是本地人,是一个聪明过人的家伙。规范本身也很了不起,如果所有人都同意使用的话,也一定是一个非常好的格式。只不过,**还不够实际**。
|
||||
|
||||
首先,XHTML 2仍然使用XML错误处理模型,你__必须保证以XML文档类型发送文档;这一点不言自明:没人愿意这样做__。其次,__XHTML 2有意不再向后兼容已有的HTML的各个版本__。他们甚至曾经讨论过废除img元素,这对每天都在做Web开发的人来说确实有点疯了的味道。但我们知道,他们之所以这样做,理论上确实有充足的理由——使用object元素可能会更好。
|
||||
|
||||
因此,无论XHTML 2在理论上是多么完美的一种格式,但却从未有机会付诸实践。而之所以难以将其付诸实践,就是因为像你我这样的开发人员永远不会支持它,它不向后兼容。同样,浏览器厂商也不会,浏览器厂商必须要保证向后兼容。
|
||||
|
||||
为什么XHTML 1.1没有像XML那样得到真正广泛地应用,为什么XHTML 2从未落到实处?因为它违反了一条设计原理,这条设计原理就是著名的__伯斯塔尔法则(Postel’s Law)__。大家都知道:
|
||||
|
||||
__发送时要保守;接收时要开放。__
|
||||
|
||||
没错,接收的时候要开放,而这也正是Web得以构建的基础。开发浏览器的人必须敞开胸怀,接收所有发送给浏览器的东西,因为它们过去一直都在接收那些不够标准的东西,对不对?**Web上的很多文档都不规范,但那正是Web发展的动力**。从某种角度讲,Web走的正是一条混沌发展之路,虽然混沌,但却非常美丽诱人。在Web上,格式不规范的文档随处可见,但那又怎样呢?**如果所有人都能够写出精准的XML,所有文档的格式都十分正确,那当然好了。可是,那不现实。现实是伯斯塔尔法则。**
|
||||
|
||||
__作为专业人士,在发送文档的时候,我们会尽量保守一些,尽量采用最佳实践,尽量确保文档格式良好。但从浏览器的角度说,它们必须以开放的姿态去接收任何文档。__
|
||||
|
||||
有人可能会说XML有错误处理模型,XHTML 1.1和XHTML 2都使用该模型,但那个错误处理模型太苛刻了。它绝对不符合接收时开放这个法则,遇到一个错误就停止解析怎么能叫开放呢?我们只能说它与**健壮性法则(也就是伯斯塔尔法则)**是对立的。
|
||||
|
||||
===== HTML 5 =====
|
||||
|
||||
之后,就到了HTML 5,但**HTML 5并不是由W3C直接制定的**。故事的经过是这样的,到20世纪末的时候,还没有HTML工作组,W3C内部的一些人就开始琢磨了,“HTML也许还可以更长寿一点,只要我们对它稍加扩展就行了。只要把我们放在XHTML上的时间和精力拿出一部分来,就可以提升一下HTML中的表单,可以**让HTML更接近编程语言**,就可以让它更上一层楼。”
|
||||
|
||||
于是,在2004年W3C成员内部的一次研讨会上,当时Opera公司的代表伊恩·希克森(Ian Hickson)提出了一个扩展和改进HTML的建议。他建议新任务组可以跟XHTML 2并行,但是**在已有HTML的基础上开展工作,目标是对HTML进行扩展**。W3C投票表决的结果是——“反对”,因为HTML已经死了,XHTML 2才是未来的方向。然后,Opera、Apple等浏览器厂商,以及其他一些成员说:“那好吧,不指望他们了,我们自已一样可以做这件事,我们脱离W3C。”他们成立了__Web Hypertext Applications Technology Working Group(Web超文本应用技术工作组,WHATWG)__——可巧的是,他们自称工作组,而不是特别小组(task force),这就为HTML 5将来的命运埋下了伏笔。
|
||||
|
||||
WHATWG决定完全脱离W3C,在HTML的基础上开展工作,向其中添加一些新东西。**这个工作组的成员里有浏览器厂商,因此他们不仅可以说加就加,而且还能够一一实现**。结果,大家不断提出一些好点子,并且逐一做到了浏览器中。
|
||||
|
||||
WHATWG的工作效率很高,不久就初见成效。在此期间,W3C的XHTML 2没有什么实质性的进展。特别是,如果从实现的角度来说,用原地踏步形容似乎也不为过。
|
||||
|
||||
结果,一件有意思的事情发生了。那是在2006年,蒂姆·伯纳斯-李写了一篇博客,说:“你们知道吗?我们错了。我们错在企图一夜之间就让Web跨入XML时代,我们的想法太不切实际了,是的,也许我们应该重新组建HTML工作组了。”善哉斯言,后来的故事情节果真就是这样发展的。**W3C在2007年组建了HTML 5工作组**。这个工作组面临的第一个问题,毫无疑问就是“我们是从头开始做起呢,还是在2004年成立的那个叫WHATWG的工作组既有成果的基础上开始工作呢?”答案是显而易见的,他们当然希望从已经取得的成果着手,以之为基础展开工作。于是他们又投了一次票,**同意“在WHATWG工作成果的基础上继续开展工作**”。好了,这下他们要跟WHATWG并肩战斗了。
|
||||
|
||||
第二个问题就是如何理顺两个工作组之间的关系。W3C这个工作组的编辑应该由谁担任?是不是还让__WHATWG的编辑,也就是现在Google的伊恩·希克森__来兼任?于是他们又投了一次票,赞成“让伊恩·希克森担任W3C HTML 5规范的编辑,同时兼任WHATWG的编辑,更有助于新工作组开展工作。”
|
||||
|
||||
这就是他们投票的结果,也就是我们今天看到的局面:**一种格式,两个版本。WHATWG的网站上有这个规范,而W3C的站点上同样也有一份**。
|
||||
|
||||
如果你不了解内情,很可能会产生这样的疑问:“哪个版本才是真正的规范?”当然,这两个版本内容是一样的……基本上相同。实际上,**这两个版本将来还会分道扬镳**。现在已经有了分道扬镳的迹象了。我的意思是说,**W3C最终要制定一个具体的规范**,这个规范会成为一个工作草案,定格在某个历史时刻。
|
||||
|
||||
而WHATWG呢,他们还在不断地迭代。即使目前我们说的HTML 5,也不能完全涵盖WHATWG正在从事的工作。最准确的理解是**他们正在开发一项简单的HTML或Web技术**,因为这才是他们工作的核心目标。然而,同时存在两个这样的工作组,这两个工作组同时开发一个基本相同的规范,这无论如何也容易让人产生误解。误解就可能造成麻烦。
|
||||
|
||||
其实这两个工作组背后各自有各自的流程,因为**它们的理念完全不同**。在WHATWG,可以说是一种独裁的工作机制。我刚才说了,伊恩·希克森是编辑。他会听取各方意见,在所有成员各抒己见,充分陈述自己的观点之后,他批准自己认为正确的意见。
|
||||
|
||||
W3C则截然相反,可以说是一种民主的工作机制。所有成员都可以发表意见,而且每个人都有投票表决的权利。这个流程的关键在于投票表决。从表面上看,WHATWG的工作机制让人不好接受。岂止是不好接受,简直是历史的倒退。相信谁都会认为“运作任何项目都不能采取这种方式!”
|
||||
|
||||
W3C的工作机制听起来让人很舒服。至少体现了人人平等嘛。但在实践中,WHATWG的工作机制运行得非常非常好。我认为之所以会这样,主要归功于伊恩·希克森。他的的确确是一个非常称职的编辑。他在听取各方意见时,始终可以做到丝毫不带个人感情色彩。
|
||||
|
||||
从原理上讲,W3C的工作机制很公平,而实际上却非常容易在某些流程或环节上卡壳,造成工作停滞不前,一件事情要达成决议往往需要花费很长时间。那到底哪种工作机制最好呢?我认为,最好的工作机制是将二者结合起来。而事实也是两个规范制定主体在共同制定一份相同的规范,我想,这倒是非常有利于两种工作机制相互取长补短。
|
||||
|
||||
两个工作组之所以能够同心同德,主要原因是HTML 5的设计思想。因为他们从一开始就确定了设计HTML 5所要坚持的原则。结果,我们不仅看到了一份规范,也就是W3C站点上公布的那份文档,即HTML 5语言规范,还在W3C站点上看到了另一份文档,也就是__HTML设计原理__。而这份文档的一位编辑今天也来到了我们大会的现场,她他就是安妮·奇泰丝(Anne Van Kesteren)。如果大家对这份文档有问题,可以请教安妮。
|
||||
|
||||
这份文档非常好,真的非常出色。这份文档,可以说见证了W3C与WHATWG同心协力共谋发展的历程。难道你们不觉得他们像是一对欢喜冤家吗?那他们还怎么同心同德呢?这份文档忠实地记录了他们一道做了什么,他们共同拥护什么。
|
||||
|
||||
接下来,我想要讲的就是这份文档。因为,既然他们能就这份文档达成共识,那么我相信,HTML 5必将是一个伟大的规范,而他们已经认可这就是他们的共同行动纲领。为此,你才会看到诸如**兼容性、实用性、互用性**之类的概念。即便W3C与WHATWG之间再有多大的分歧——确实相当多——至少他们还有这份文档中记录的共识。这一点才是至关重要的。正因为他们有了共识,才有了这份基于共识描述设计原理的文档。
|
||||
|
||||
===== 避免不必要的复杂性 =====
|
||||
|
||||
下面我就给大家介绍一些这份文档中记载的设计原理。__第一个,非常简单:避免不必要的复杂性__。好像很简单吧。我用一个例子来说明。
|
||||
|
||||
假设我使用HTML 4.01规范,我打开文档,输入doctype。这里有人记得HTML 4.01的doctype吗?好,没有,我猜没有。除非……我的意思是说,你是傻冒。现场恐怕真有人背过,这就是HTML 4.01的doctype:
|
||||
|
||||
<!DOCTYPE html PUBLIC "-//W3C/DTD HTML 4.01//EN"
|
||||
"http://www.w3.org/TR/html4/strict.dtd">
|
||||
|
||||
**我不记这个两行代码,不然还要记事本、要Google、要模板有什么用呢?**
|
||||
|
||||
要是我使用XHTML 1.0呢,这个规范我都已经用了10年了。有谁记得住这个doctype吗?没错,它的长度跟HTML 4.01的差不太多:
|
||||
|
||||
<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN"
|
||||
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||||
|
||||
是不是,基本上相同。**它要告诉浏览器的是:这个文档是XHTML 1.0的文档**。那么在HTML 5中,省掉不必要的复杂性,doctype就简化成了:
|
||||
|
||||
<!DOCTYPE html>
|
||||
|
||||
仅此而已。好了,就连我也能过目不忘了。我用不着把这几个字符记在记事本里了。我得说,在我第一次看到这个doctype的时候——我当然以为这是一个HTML文档的doctype——被它吓了一跳:“是不是还少一个数字5啊?”我心里想:“这个doctype想告诉浏览器什么呢?就说这个文档是HTML吗?难道这是有史以来唯一一个HTML版本吗,这件事我得首先搞清楚,HTML今后永远不会再有新版本了吗?”好一副唯我独尊的架式!我错了,因为这个doctype并没有这个意思。__为此,必须先搞清楚为什么文档一开头就要写doctype。它不是写给浏览器看的。Doctype是写给验证器看的。__也就是说,我之所以要在文档一开头写那行XHTML 1.0的doctype,是为了告诉验证器,让验证器按照该doctype来验证我的文档。
|
||||
|
||||
浏览器反倒无所谓了。假设我写的是HTML 3.2文档,文档开头写的是HTML 3.2的doctype。而在文档中某个地方,我使用了HTML 4.01中才出现的一个元素。浏览器会怎么处理这种情况?它会因为这个元素出现在比doctype声明的HTML版本更晚的规范中,就不解释呈现该元素吗?不会,当然不会!__它照样会解释呈现该元素__,__别忘了伯斯塔尔法则,别忘了健壮性。浏览器在接收的时候必须要开放。因此,它不会检查任何格式类型,而验证器会,验证器才关心格式类型。这才是存在doctype的真正原因。__
|
||||
|
||||
而按照HTML 5的__另一个设计原理,它必须向前向后兼容,兼容未来的HTML版本__——不管是HTML6、HTML7,还是其他什么——都要与当前的HTML版本,HTML 5,兼容。因此,**把一个版本号放在doctype里面没有多大的意义**,即使对验器证也一样。
|
||||
|
||||
刚才,我说**doctype不是为浏览器写的**,这样说大多数情况下没有问题。在有一种情况下,你使用的doctype会影响到浏览器,相信在座诸位也都知道。但在这种情况下,Doctype并非真正用得其所,而只是为了达到某种特殊的目的才使用doctype。当初微软在引入CSS的时候,走在了标准的前头,他们率先在浏览器中支持CSS,也推出了自己的盒模型——后来标准发布了,但标准中使用了不一样的盒模型。他们怎么办?他们想支持标准,但也想向后兼容自己过去推出的编码方式。**他们怎么知道网页作者想使用标准,还是想使用他们过去的方式?**
|
||||
|
||||
于是,他们想出了一个非常巧妙的主意。那就是利用doctype,__利用有效的doctype来触发标准模式,而不是兼容模型(quiks mode)__。这个主意非常巧妙。我们今天也都是这样在做,在我们向文档中加入doctype时,就相当于声明了“我想使用标准模式”,但这并不是发明doctype的本意。这只是为了达到特殊的目的在利用doctype。
|
||||
|
||||
下面我出一道有奖抢答题,听好:“一分钟后开始,如果你手快的话,第一个在文档前面写完doctype html,然后我用Internet Explorer打开你的文档,会触发它的标准模式,还是会触发它的兼容模式?”
|
||||
|
||||
答案是,**这是在Internet Explorer中触发标准模式的最少字符数目**。我认为这也说明了__HTML 5规范的本质:它不追求理论上的完美__。HTML 5所体现的不是“噢,给作者一个简短好记的doctype不好吗?”,没错,简短好记是很好,但如果这个好记的doctype无法适应现有的浏览器,还不如把它忘了更好。因此,这个平衡把握得非常好,不仅理论上看是个好主意——简短好记的doctype,而且实践中同样也是个好主意——仍然可以触发标准模式。应该说,Doctype是一个非常典型的例子。
|
||||
|
||||
还有一个例子,同样可以说明规范是如何省略不必要的复杂性,避免不必要的复杂性的。如果前面的文档使用的是HTML 4.01,假设我要指定文档的字符编码。理想的方式,是**通过服务器在头部信息中发送字符编码,不过也可以在文档这个级别上指定**:
|
||||
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||||
|
||||
同样,我也不会把这行代码背下来。__我还想省下自己的脑细胞去记点别的更有价值的东西呢__。不过,如果我想指定文档使用UTF-8编码,只能添加这行代码。这是在HTML 4.01中需要这样做。要是你在XHTML 1.0指定同样的编码,就得多敲一下键盘,因为你还得声明meta元素位于一个开始的XML标签中。
|
||||
|
||||
<?xml version="1.0" encoding="UTF-8" ?>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
|
||||
在HTML 5中,你要敲的字符只有:
|
||||
|
||||
<meta charset="utf-8">
|
||||
|
||||
简短好记。我能背下来。
|
||||
|
||||
同样,这样写也是有效的。它不仅适用于最新版本的浏览器,只要是今天还有人在用的浏览器都同样有效。为什么?因为在我们把这些meta元素输入浏览器时,浏览器会这样解释它:“元数据(meta)点点点点点,字符集(charset)utf-8。”这就是浏览器在解释那行字符串时真正看到的内容。__它必须看到这些内容,根据就是伯斯塔尔法则,对不对?__
|
||||
|
||||
我多次提到健壮性原理,但总有人不理解。我们换一种说法,浏览器会想“好,我觉得作者是想要指定一个字符集……看,没错,utf-8。”这些都是规范里明文规定的。如今,不仅**那个斜杠可以省了**,而且总共只要写meta charset=”utf-8″就行了。
|
||||
|
||||
关于省略不必要的复杂性,或者说避免不必要的复杂性的例子还有不少。但__关键是既能避免不必要的复杂性,还不会妨碍在现有浏览器中使用__。比如说,在HTML 5中,如果我使用link元素链接到一个样式表,我说了rel=”stylesheet”,然后再说type=”text/css”,那就是重复自己了。对浏览器而言,我就是在重复自己。浏览器用不着同时看到这两个属性。**浏览器只要看到rel=”stylesheet”就够了,因为它可以猜出来你要链接的是一个CSS样式表**。所以就不用再指定type属性了。你不是已经说了这是一个样式表了嘛;不用再说第二次了。当然,愿意的话,你可以再说;如果你想包含type属性,请便。
|
||||
|
||||
同样地,如果你使用了script元素,你说type=”text/javascript”,浏览器差不多就知道是怎么回事了。对Web开发而言,你还使用其他的脚本语言吗?如果你真想用其他脚本语言,没人会阻拦你。但我要奉劝你一句,任何浏览器都不会支持你。
|
||||
|
||||
愿意的话,你可以添加一个type属性。不过,也可以什么都不写,浏览器自然会假设你在使用JavaScript。__避免-不必要的-复杂性__。
|
||||
|
||||
|
||||
===== 支持已有的内容 =====
|
||||
|
||||
支持已有的内容。这一点非常重要,因为很多人都认为HTML 5很新,很闪亮;它应该代表着未来发展的方向,应该把Web推向一个新的发展阶段。这就是HTML 5,对吗?显然,我们都会考虑让Web的未来发展得更好,**但他们则必须考虑过去**。别忘了W3C这个工作组中有很多人代表的是浏览器厂商,他们肯定是要考虑支持已有内容的。__只要你想构建一款浏览器,就必须记住这个原则:必须支持已有的内容。__
|
||||
|
||||
下面我们就来看一个HTML 5支持已有内容的例子。
|
||||
|
||||
这个例子展示了编写同样内容的四种不同方式。上面是一个img元素,下面是带一个属性的段落元素。四种写法唯一的不同点就是语法。把其中任何一段代码交给浏览器,浏览器都会生成相同的DOM树,没有任何问题。**从浏览器的角度看,这四种写法没有区别**。因而在HTML 5中,你可以随意使用下列任何语法。
|
||||
|
||||
<img src="foo" alt="bar" />
|
||||
<p class="foo">Hello world</p>
|
||||
|
||||
<img src="foo" alt="bar">
|
||||
<p class="foo">Hello world
|
||||
|
||||
<IMG SRC="foo" ALT="bar">
|
||||
<P CLASS="foo">Hello world</P>
|
||||
|
||||
<img src=foo alt=bar>
|
||||
<p class=foo>Hello world</p>
|
||||
|
||||
好了,看到这几段代码,恐怕有人会说“不对不对不对。其中只有一个是对的,另外三个——说不好。”不对,应该给属性值加引号!拜托,我们可是一直都给属性值加引号的!元素名大写对吗?这种做法10年不是就被抛弃了吗?
|
||||
|
||||
看到HTML 5同时允许这些写法,我心里忍不住一阵阵想吐。我写了10年的XHTML 1.0,已经非常适应严格的语法了。但你必须明白,站在浏览器的角度上,这些写法实际上都是一样的。确实没有什么问题。
|
||||
|
||||
还有谁也感到不舒服了吗?有谁看到这些之后想“噢,这不是乱写嘛,这样做不对”?只有我这样想吗?还有别人吗?
|
||||
|
||||
__但是,HTML 5必须支持已经存在的内容,而已有的内容就是这个样子的。不是吗?根据伯斯塔尔法则,浏览器没有别的选择。__
|
||||
|
||||
有人可能会说“这样不行。我觉得语言本身应该提供一种开关,让作者能够表明自己想做什么。”比如说,想使用某种特定的语法,像XHTML,而不是使用其他语法。我理解这些人的想法。但我不赞成在语言里设置开关。因为我们讨论的只是编码风格或者写作风格,跟哪种语法正确无关。对于像我们这样的专业人士,__我认为可以使用lint工具__(一种软件质量保证工具,或者说是一种更加严格的编译器。它不仅可以象普通编译器那样检查出一般的语法错误,还可以检查出那些虽然完全合乎语法要求,但很可能是潜在的、不易发现的错误),对其他技术我们不是也在使用lint工具嘛。
|
||||
|
||||
比如说对JavaScript使用lint工具。JavaScript同样也是比较混乱、不严谨的例子,但它非常强大,原因恰恰是它混乱、不严谨,而且有很多不同的编码方式。在JavaScript,你可以在每条语句末尾加上分号,但不是必需的,因为JavaScript会自动插入分号……是不是听起来有点不好接受?
|
||||
|
||||
正因为如此,才有了像__JSlint__这样的工具,在道格拉斯·克劳克福德(Douglas Crockford)的网站jslint.org上面。有个网页上写着“JSlint可能会伤害你的感情。”但这确实是个非常棒的工具,它可以把JavaScript代码变得完美无瑕。如果你通过JSlint运行JavaScript,它会告诉你“好,你的JavaScript代码有效,但写法不妥。你这种编码风格啊,我不喜欢。不赞成你这样写。这样写不好。”特别是对团队,对于要使用统一的编码风格的团队,JSlint是非常方便的工具。
|
||||
|
||||
我个人认为,不仅对团队来说,__就算是你自己写代码,也要坚持一种语法风格__。从浏览器解析的角度讲,不存在哪种语法比另一种更好的问题,但我认为,作为专业人士,我们必须能够自信地讲“这就是我的编码风格。”然而,我不认为语言里应该内置这种开关。你**可以使用lint工具来统一编码风格**。现在就来说说lint工具。大家可以登录htmllint.com,在其中运行你的HTML 5文档,它会帮你检查属性值是否加了引号,元素是否小写,你还可以通过勾选复选框来设置其他检查项。
|
||||
|
||||
但这不意味着拒绝粗心大意的标记,做不做清理完全取决于你自己。我说过,因为浏览器必须支持已有的内容,HTML 5自然也不能例外。归根结底还是伯斯塔尔法则。我们始终离不开伯斯塔尔法则。
|
||||
|
||||
===== 解决现实的问题 =====
|
||||
|
||||
HTML 5的__另一个设计原理是解决现实的问题__。显而易见的是,解决各种问题的格式和规范已经比比皆是了,因此在我看来,这个原理其实是要解决理论问题,而非解决现实的问题。**这条设计原理是要从理论上承认人们普遍存在的问题,消除敏感问题**。
|
||||
|
||||
下面我来举个例子。相信这个例子有不少人都遇到过。假设我使用HTML 4或XHTML 1,页面中已经有了一块内容,我想给整块内容加个链接,怎么办?问题是这块内容里包含一个标题,一个段落,也许还有一张图片。如果我想给它们全部都可以点击,必须使用3个链接元素。于是,我得先把光标放在标题(比如说h2元素)中,写一个链接标签,然后再选中所有要包含到链接里面来的文本。接着,再把光标放在段落里,写一个链接标签,然后把段落中的文本放在链接里……
|
||||
|
||||
<h2><a href="/path/to/resource">Headline text</a></h2>
|
||||
<p><a href="/path/to/resource">Paragraph text.</a></p>
|
||||
|
||||
在HTML 5中,我只要简单地把所有内容都包装在一个链接元素中就行了。
|
||||
|
||||
<a href="/path/to/resource">
|
||||
<h2>Headline text</h2>
|
||||
<p>Paragraph text.</p>
|
||||
</a>
|
||||
|
||||
没错,**链接包含的都是块级元素**,但现在我可以用一个元素包含它们。这样太好了。因为我碰到过类似的情形,必须给几个块级元素加上相同的链接,所有能这样写就太好了。为此,我就非常欢迎HTML 5这个新标准。
|
||||
|
||||
它解决了一个现实的问题。我敢说在座不少朋友都曾遇到过这个问题。
|
||||
|
||||
那这到底解决的是什么问题呢?浏览器不必因此重新写代码来支持这种写法。这种写法其实早就已经存在于浏览器中了,因为早就有人这样写了,当然以前这样写是不合乎规范的。所以,说HTML 5解决现实的问题,其本质还是“你都这样写了很多年了吧?现在我们把标准改了,允许你这样写了。”
|
||||
|
||||
===== 求真务实 =====
|
||||
|
||||
在所有设计原理中,这一条恐怕是最响亮的了——求真务实。不知道大家有没有在公司里开会时听到过这种口号:“开拓进取,求真务实。”实际上,除了作为企业的口号,它还是一条非常重要的设计原理,因为__求真务实对于HTML的含义是:在解决那些令人头痛的问题之前,先看看人们为应对这些问题都想出了哪些办法。集中精力去理解这些“民间的”解决方案才是当务之急。__
|
||||
|
||||
HTML 5中新的语义元素就是遵循求真务实原理的反映。新增的元素不算多,谈不上无限的扩展性,但却不失为一件好事。尽管数量屈指可数,但意义却非同一般。这些新元素涉及头部(header)、脚部(footer)、分区(section)、文章(article)……,相信大家都不会觉得陌生。我的意思是说,即便你不使用HTML 5,也应该熟悉这些称呼,这些都是你曾经使用过的__类名__,比如class=”header”/“head”/“heading”,或class=”footer”/“foot”。当然,也可能是__ID__,id=”header”,id=”footer”。这些不都是我们已经司空见惯了的嘛。
|
||||
|
||||
好,举个例子吧,假设你今天写了下面这个文档。
|
||||
|
||||
<body>
|
||||
<div id="header">...</div>
|
||||
<div id="navigation">...</div>
|
||||
<div id="main">...</div>
|
||||
<div id="sidebar">...</div>
|
||||
<div id="footer">...</div>
|
||||
</body>
|
||||
|
||||
这里有一个div使用了id=”header”,另一个div使用了id=”navigation”,……。怎么样,都轻车熟路了吧?在HTML 5中,这些元素都可以换掉。说起新增的语义元素,它们价值的一方面可以这样来体现:“嘿,看啊,这样多好,用HTML 5新增的元素可以把这些div都替换掉。”
|
||||
|
||||
<body>
|
||||
<header>...</header>
|
||||
<nav>...</nav>
|
||||
<div id="main">...</div>
|
||||
**<aside>...</aside> **
|
||||
<footer>...</footer>
|
||||
</body>
|
||||
|
||||
当然了,你可以这样做。在__文档级别__上使用这些元素没有问题。但是,假如新增这些元素的目的仅仅是为了取代原来的div,那就真有点多此一举了。
|
||||
|
||||
虽然在这个文档中,我们用这些新元素来替换的是ID,但在我个人看来,__将它们作为类的替代品更有价值__。为什么这么说呢?因为这些元素在一个页面中不止可以使用一次,而是可以使用多次。没错,你可以为文档添加一个头部(header),再添加一个脚部(footer);但文档中的每个分区(section)照样也都可以有一个头部和一个脚部。而每个分区里还可以嵌套另一个分区,被嵌套的分区仍然可以有自己的头部和脚部,是这样吧?
|
||||
|
||||
__这四个新元素:section、article、aside和nav,之所以说它们强大,原因在于它们代表了一种新的内容模型,一种HTML中前所未有的内容模型——给内容分区。__迄今为止,我们__一直都在用div来组织页面中的内容__,但与其他类似的元素一样,__div本身并没有语义__。但section、article、aside和nav实际上是在明确地告诉你——这一块就像文档中的另一个文档一样。位于这些元素中的任何内容,都可以拥有自己的概要、标题,自己的脚部。
|
||||
|
||||
**其中最为通用的section,可以说是与内容最相关的一个。而article则是一种特殊的section。Aside呢,是一种特殊的section。最后,Nav也是一种特殊的section。**
|
||||
|
||||
好,即便是现在,你照样可以**使用div和类来描述页面中不同的部分**,就像下面这样:
|
||||
|
||||
<div class="item">
|
||||
<h2>...</h2>
|
||||
<div class="meta">...</div>
|
||||
<div class="content">
|
||||
...
|
||||
</div>
|
||||
<div class="links">...</div>
|
||||
</div>
|
||||
|
||||
其中包含可能是有关内容作者的元数据,而下面会给出一些链接,差不多就这样。在HTML 5中,我完全可以说这块内容就是一个文档,通过对内容分区,使用section或article或aside,我可以说“这一块完全是可以独立存在的。”因此,我当然可以使用header和footer。
|
||||
|
||||
<section class="item">
|
||||
<header><h1>...</h1></header>
|
||||
<footer class="meta">...</footer>
|
||||
<div class="content">
|
||||
...
|
||||
</div>
|
||||
<nav class="links">...</nav>
|
||||
</section>
|
||||
|
||||
请注意,即便是footer,也不一定非要出现在下面,不是吗?__这几个元素,header、footer、aside、nav,最重要的是它们的语义;跟位置没有关系。__一想到footer这个词,我们总会不由自主地想,“噢,应该放在下面。”同样,我们把aside想象成一个侧边栏。可是,如果你看一看规范,就会发现这些元素只跟内容有关。因此,放在footer中的内容也可以是署名,文章作者之类的,它只是你使用的一个元素。这个元素并没有说“必须把我放在文档或者分区的下面。”
|
||||
|
||||
这里,请注意,最重要的还不是我用几个新元素替换了原来的div加类,而是我把原来的H2换成了H1——震撼吧,我看到有人发抖了。我碰到过不少职业的Web开发人员,多年来他们一直认为规范里说一个文档中只能有一个H1。还有一些自诩为万能的SEO秘诀同样说要这样。很多SEO的技巧其实是很教条的。所谓教条,意思就是不相信数据。过去,这种教条表现为“不行,页面中包含两个以上的H1,你就会死掉的。”在HTML 5中,只要你建立一个新的内容块,不管用section、article、aside、nav,还是别的元素,都可以在其中使用H1,**而不必担心这个块里的标题在整个页面中应该排在什么级别;**H2、H3,都没有问题。
|
||||
|
||||
这个变化太厉害了。想一想吧,__这个变化对内容管理是革命性的__。因为现在,你可以把每个内容分区想象一个独立的、能够从页面中拿出来的部分。此时,根据上下文不同,这个独立部分中的H1,在整个页面中没准会扮演H2或H3的角色——取决于它在文档中出现的位置。面对这个突如其来的变化,也许有人的脑子会暂时转不过弯来。不要紧,但我可以告诉你,我认为这才是HTML 5中这些新语义标记的真正价值所在。换句话说,__我们现在有了独立的元素了,这些元素中的标题级别可以重新定义__。
|
||||
|
||||
我的文档中可能会包含一个分区,这个分区中可能会嵌套另一个分区,或者一篇文章,然后文章再嵌套分区,分区再嵌套文章、嵌套分区,文章再嵌套文章。而且每个分区和文章都可以拥有自己的H1到H6。从这个意义上讲,H元素真可谓“子子孙孙,无穷匮也”了。但是,在你在编写内容或者内容管理系统的时候,它们又都是独立的,完全独立的内容块。这才是真正的价值所在。
|
||||
|
||||
实际上,这个点子并不HTML 5工作组拍脑门想出来的,也不是W3C最近才提出来的。下面这几句话摘自蒂姆·伯纳斯-李1991年的一封邮件,邮件是发给丹·康纳利(Dan Connolly)的。他在邮件中解释了对HTML的理解,他说:“你知道……知道我的想法,我认为H1、H2这样单调地排下去不好,我希望它成为一种可以嵌套的元素,或者说一个通用的H元素,我们可以在其中嵌套不同的层次。”但后来,我们没有看到通用的H元素,而是一直在使用H1和H2——那是因为我们一直在支持已有的内容。20年后的今天,这个理想终于实现了。
|
||||
|
||||
===== 平稳退化 =====
|
||||
|
||||
下一条原理大家应该都很熟悉了,那就是平稳退化。毕竟,我们已经遵守这条规则好多年了。__渐进增强的另一面就是平稳退化__。
|
||||
|
||||
有关HTML 5遵循这条原理的例子,就是使用type属性增强表单。下面列出了可以为type属性指定的新值,有number、search、range,等等。
|
||||
|
||||
input type="number"
|
||||
input type="search"
|
||||
input type="range"
|
||||
input type="email"
|
||||
input type="date"
|
||||
input type="url"
|
||||
|
||||
最关键的问题在于浏览器在看到这些新type值时会如何处理。现有的浏览器,不是将来的浏览器,现有的浏览器是无法理解这些新type值的。但在__它们看到自己不理解的type值时,会将type的值解释为text。__
|
||||
|
||||
无论你写的是input type=”foo”还是input type=”bar”,现有的任何浏览器都会说:“嗯,也许作者的意思是text。”因而,你从现在开始就可以使用这些新值,而且你也可以放心,那些不理解它们的浏览器会把新值看成type=”text”,而这真是一个浏览器实践平稳退化原理的好例子。
|
||||
|
||||
比如说,你现在输入了type=”number”。假设你需要一个输入数值的文本框。那么你可以把这个input的type属性设置为number,然后__理解它的浏览器就会呈现一个可爱的小控件,像带小箭头图标的微调控件之类的。对吧?而在不理解它的浏览器中,你会看到一个文本框__,一个你再熟悉不过的文本框。既然如此,为什么不能说输入type=”number”就会得到一个带小箭头图标的微调控件呢?
|
||||
|
||||
当然,你还可以设置最小和最大值属性,它们同样可以平稳退化。这是问题的关键。
|
||||
|
||||
再看input type=”search”。你也可以考虑一下这种输入框,因为这种输入框在Safari中会被呈现为一个系统级的搜索控件,右边还有一个点击即可清除搜索关键词的X。而在其他浏览器中,你得到的则是一个文本框,就像你写的是input type=”text”一样,也就是你已经非常熟悉的文本框。那为什么还不使用input type=”search”呢?它不会有什么副作用,没有,对不对?
|
||||
|
||||
**HTML 5还为输入元素增加了新的属性,比如placeholder(占位符)**。有人不知道这个属性的用处吗,没有吧?没错,就是用于在文本框中预先放一些文本。不对,不是标签(label)——占位符和标签完全不是一回事。占位符就是文本框可以接受的示例内容,一般颜色是灰色的。只要你一点击文本框,它就消失了。如果你把已经输入的内容全部删除,然后单击了文本框外部,它又会出现。
|
||||
|
||||
使用JavaScript编写一些代码当然也可以实现这个功能,但HTML 5只用一个placeholder属性就帮我们解决了问题。
|
||||
|
||||
当然,对于不支持这个属性的浏览器,你还是可以使用JavaScript来实现占位符功能。通过JavaScript来测试浏览器支不支持该属性也非常简单。如果支持,后退一步,把路让开,乐享其成即可。如果不支持,可以再让你的JavaScript来模拟这个功能。
|
||||
|
||||
现在,我不得不提到另一个话题了:HTML 5对Flash。也许你早听说过了,或者在哪里看到了这方面的讨论。说实话,我一点也不明白。我搞不懂人们怎么会仅仅凭自己的推测来展开争论。
|
||||
|
||||
首先,他们所说的HTML 5对Flash,并不是指的HTML 5,也不是指的Flash。而是指HTML 5的一个子集和Flash的一个子集。具体来说,他们指的是视频。因此,不管你在哪里听到**别人说“HTML 5对Flash”,那很可能说的只是HTML 5视频对Flash视频**。
|
||||
|
||||
其次,一说HTML 5对Flash,就好像你必须得作出选择一样:你站在哪一边?实际上不是这样的。HTML 5规范的设计能够让你做到鱼和熊掌兼得。
|
||||
|
||||
好,下面就来看看这个新的video元素;真是非常贴心的一个元素,而且设计又简单,又实用。一个开始的video元素,加一个结束的video元素,中间可以放后备内容。注意,是后备内容,不是保证可访问性的内容,是后备内容。下面就是针对不支持video元素的浏览器写的代码:
|
||||
|
||||
<video src="movie.mp4">
|
||||
<!-- 后备内容 -->
|
||||
</video>
|
||||
|
||||
那么,在后备内容里面放些什么东西呢?好,你可以放Flash影片。这样,**HTML 5的视频与Flash的视频就可以协同起来了**。你不用作出选择。
|
||||
|
||||
当然,你的代码实际
|
||||
|
||||
<video src="movie.mp4">
|
||||
<object data="movie.swf">
|
||||
<!-- 后备内容 -->
|
||||
</object>
|
||||
</video>
|
||||
|
||||
上并没有这么简单。因为这里我使用了H264,部分浏览器支持这种视频格式。但有的浏览器不支持。
|
||||
|
||||
对不起,请不要跟我谈视频格式,我一听就心烦。不是因为技术。技术倒无所谓,关键是会牵扯到一大堆专利还有律师、知识产权等等,这些都是Web的天敌,对我建网站一点好处都没有。
|
||||
|
||||
可你实际上要做的,仅仅就是把后备内容放在那而已,后备内容可以包含多种视频格式。如果愿意怕话,__可以使用source元素而非src属性来指定不同的视频格式__。
|
||||
|
||||
<video>
|
||||
<source src="movie.mp4">
|
||||
<source src="movie.ogv">
|
||||
<object data="movie.swf">
|
||||
<a href="movie.mp4">download</a>
|
||||
</object>
|
||||
</video>
|
||||
|
||||
上面的代码中包含了4个不同的层次。
|
||||
|
||||
1、如果浏览器支持video元素,也支持H264,没什么好说的,用第一个视频。
|
||||
|
||||
2、如果浏览器支持video元素,支持Ogg,那么用第二个视频。
|
||||
|
||||
3、如果浏览器不支持video元素,那么就要试试Flash影片了。
|
||||
|
||||
4、如果浏览器不支持video元素,也不支持Flash,我还给出了下载链接。
|
||||
|
||||
不错,一开始就能考虑这么周到很难得啊。有了这几个层次,已经够完善了。
|
||||
|
||||
总之,我是建议你__各种技术要兼顾,无论是HTML 5,还是Flash,一个也不能少__。如果只使用video元素提供视频,难免搬起石头砸自己的脚,我个人认为。而如果只提供Flash影片,情况也好不到哪去,性质是一样的。所以还是应该两者兼顾。
|
||||
|
||||
为什么要兼顾这两种技术呢?假设你需要面向某些不支持Flash的手持设备——只是举个例子——提供视频,你当然希望手持设备的用户能够看到视频了,不是吗?
|
||||
|
||||
至于为什么要使用不同的格式,为什么Flash视频和音频如此成功,我想可以归结为另一个设计原理,即__梅特卡夫定律(Metcalfe’s Law):__
|
||||
|
||||
__网络价值同网络用户数量的平方成正比。__
|
||||
|
||||
梅特卡夫的这个定律虽然是针对电话网提出来的,但在很多领域里也是适用的。使用网络的用户越多,网络的价值也就越大。人人都上Facebook,还不是因为人人都上Facebook嘛。虽然Facebook真正的价值不在于此,但只有人人都上才会让它的变得如此有价值。
|
||||
|
||||
梅特卡夫定律也适用于传真机。如果只有一个人购买了传真机,当然没有什么用处。但如果其他人也陆续购买了传真机,那么他的投资会就得到回报。
|
||||
|
||||
当然,面对竞争性的视频格式和不同的编码方式,你感觉不到梅特卡夫定律的作用,我也很讨厌以不同的方式来编码视频,但只向浏览器发送用一种方式编码的视频是行不通的。而这也正是Flash在视频/音频领域如此成功的原因。你只要把Flash影片发送给浏览器就好了,然后安装了插件的浏览器都能正常播放。本质上讲,Flash利用了梅特卡夫定律。
|
||||
|
||||
===== 最终用户优先 =====
|
||||
|
||||
今天我要讲的最后一个设计原理,也是我个人最推崇的一个,但没有要展示的代码示例。这个原理更有哲学的味道,即最终用户优先。
|
||||
|
||||
这个设计原理**本质上是一种解决冲突的机制**。换句话说,当你面临一个要解决的问题时,如果W3C给出了一种解决方案,而WHATWG给出了另一种解决方案,一个人这么想,另一个人那么想……这时候,有人站出来说:“对这个问题我们这样来解决。”
|
||||
|
||||
__一旦遇到冲突,最终用户优先,其次是作者,其次是实现者,其次标准制定者,最后才是理论上的完满。__
|
||||
|
||||
理论上的完满,大致是指尽可能创建出最完美的格式。标准制定者,指的是工作组、W3C,等等。实现者,指的是浏览器厂商。作者,就是我们这些开发人员,对吧?看看我们在这个链条里面的位置多靠上啊!我们的地位仅次于最终用户——事情本来就该这个样子。用户是第一位的。而我们的声音在标准制定过程中也同样非常非常重要。
|
||||
|
||||
Hixie(即Ian Hickson, Acid2、Acid3的作者及维护者,HTML 5、CSS 2.1规范的制定者)经常说,在有人建议了某个特性,而HTML 5工作组为此争论不下时,如果有浏览器厂商说“我们不会支持这个特性,不会在我们的浏览器中实现这个特性”,那么这个特性就不会写进规范。因为即使是把特性写进规范,如果没有厂商实现,规范不过是一纸空文,对不对?实现者可以拒绝实现规范。
|
||||
|
||||
而根据最终用户优先的原理,我们在链条中的位置高于实现者,假如我们发现了规范中的某些地方有问题,我们想“这样规定我们不能同意,我们不支持实现这个特性”,那么就等于把相应的特性给否定了,规范里就得删除,因为我们的声音具有更高的权重。我觉得这样挺好!本质上是我们拥有了更大的发言权,对吧?我认为开发人员就应该拥有更多的发言权。
|
||||
|
||||
我觉得这应该是最重要的一条设计原理了,因为它承认了你的权利,无论是设计一种格式,还是设计软件,这条原理保证了你的发言权。而这条原理也正道出了事物运行的本质。难道还不够明显吗?用户的权利大于作者,作者的权利大于实现者,实现者的权利大于标准制定者。然而,反观其他规范,比如**XHTML2,你就会发现完全相反的做法。把追求理论的完满放在第一位**,而把用户——需要忍受严格错误处理带来的各种麻烦的用户——放在了链条的最底端。我并没有说这种做法就是错误的,但我认为这是一种完全不同的思维方式。
|
||||
|
||||
因此,我认为无论你做什么,不管是构建像HTML 5这样的格式,还是构建一个网站,亦或一个内容管理系统,明确你的设计原理都至关重要。
|
||||
|
||||
__软件,就像所有技术一样,具有天然的政治性。代码必然会反映作者的选择、偏见和期望。__
|
||||
|
||||
下面我们讲一个例子。Drupal社区曾联系马克·博尔顿(Mark Boulton)和丽莎·雷贺特(Leisa Reichilt)设计Drupal的界面。他们计划遵循一些设计原理。为此,他们并没有纸上谈兵,而是经过了一段时间的思考和酝酿,提出指导将来工作的4个设计原理:
|
||||
|
||||
__简化最常见的任务,让不常见的任务不至于太麻烦。__
|
||||
|
||||
__只为80%设计。__
|
||||
|
||||
__给内容创建者最大的权利。__
|
||||
|
||||
__默认设置智能化。__
|
||||
|
||||
实际上,我在跟马克谈到这个问题时,马克说主要还是那两个,即“只为80%设计。给内容创建者最大的权利。”这就很不错了,至少它表明了立场,“我们认为内容创建者比这个项目中的任何人都重要。”在制定设计原理时,很多人花了很多时间都抓不住重点,因为他们想取悦所有人。**关键在于我们不是要取悦所有人,而是要明确哪些人最重要**。他们认为内容创建者是最重要的。
|
||||
|
||||
另一条设计原理,__只为80%设计,其实是一条常见的设计原理,也是一种通用模式,即帕累托原理(Pareto principle)__。
|
||||
|
||||
帕累托是意大利经济学家,他提出这个比例,__80/20,说的是世界上20%的人口拥有80%的财富__。这个比例又暗合了自然界各个领域的幂律分布现象。总之,无论你是编写软件,还是制造什么东西,都是一样的,__即20%的努力可以触及80%的用例。最后20%的用例则需要付出80%甚至更多的努力__。因此,有时候据此确定只为80%设计是很合理的,因为我们知道为此只要付出20%的努力即可。
|
||||
|
||||
再比如,微格式同样也利用了帕累托原理,只处理常见用例,而没有考虑少数情形。他们知道自己不会让所有人都满意;而他们的目标也不是让所有人都满意。他们遵循的设计原理很多,也都非常有价值,但最吸引人的莫过于下面这条了:
|
||||
|
||||
__首先为人类设计,其次为机器设计。__
|
||||
|
||||
同样,你我都会觉得这是一条再明显不过的道理,但现实中仍然有不少例子违反了这条原理:容易让机器理解(解析)比容易让用户理解更重要。
|
||||
|
||||
所以,我认为平常多看一看别人推崇的设计原理,有助于做好自己手头的工作。你可以把自己认为有道理的设计原理贴在墙上。当然,你可以维护一个URL,把自己认为有价值的设计原理分享出来,就像Mozilla基金会那样,对不对,以下是Mozilla的设计原理:
|
||||
|
||||
__Internet作为一种公共资源,其运作效率取决于互通性(协议、数据格式、内容)、变革及全球范围内的协作。__
|
||||
|
||||
__基于透明社区的流程有助于增进协作、义务和信任。__
|
||||
|
||||
我觉得像这样的设计原理都非常好。而有了设计原理,我认为才更有希望设计出真正有价值的产品。设计原理是Web发展背后的驱动力,也是通过HTML 5反映出来的某种思维方式。我想,下面这条原理你绝对不会陌生:
|
||||
|
||||
__大多数人的意见和运行的代码。__[1]
|
||||
|
||||
对不对?这句话经常在我脑际回响,它囊括了Web的真谛,触及了HTML 5的灵魂。
|
||||
|
||||
也许我该把这条原理打印出来贴到办公室的墙上,让它时刻提醒我,这就是Web的设计原理:大多数人的意见和运行的代码。
|
||||
|
||||
我想,今天的演讲就到这里了。如果大家有什么想法可以在twitter上通过@adactio找到我。有时候我也会在自己的博客,adactio.com上写写有关这个主题的文章。最后,可能还要顺便给我自己做个广告,我刚出了一本书,希望大家关注。
|
||||
|
||||
|
||||
41
Zim/Web-Design/HTML5/HTML字符实体.txt
Normal file
@@ -0,0 +1,41 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-01T20:26:21+08:00
|
||||
|
||||
====== HTML字符实体 ======
|
||||
Created Sunday 01 May 2011
|
||||
|
||||
发表于2011 年 02 月 20 日 ⁄ 网站基础 ⁄ 评论数 34 ⁄ 被围观 1,305 次+
|
||||
Linux虚拟主机 php mysql ruby 免备案 免费域名
|
||||
|
||||
由于今天休息,所以就看了一下HTML教程,重新来学习HTML。上次讲到HTML元素与标签,今天要和大家学习的是HTML字符实体。那么什么叫字符实体呢?下面我就向大家详细介绍下。
|
||||
|
||||
字符实体:
|
||||
|
||||
在HTML中,有些字符拥有特殊含义,比如小于号“<”定义为一个HTML标签的开始。假如我们想要浏览器显示这些字符的话,必须在HTML代码中插入字符实体。例如想要在HTML文档中显示一个小于号,我们必须这样写:<或者<。
|
||||
|
||||
字符实体的组成:
|
||||
|
||||
一个字符实体拥有三个部分:一个and符号(&),一个实体名或者一个实体号,最后是一个分号(;)。虽然使用名字相对于使用数字的优点是容易记忆,但缺点是并非所有的浏览器都支持最新的实体名,但是几乎所有的浏览器都能很好地支持实体号。
|
||||
|
||||
注意:实体名是大小写敏感的。
|
||||
|
||||
下面这个例子能够让你针对HTML实体实践一下。
|
||||
|
||||
<html>
|
||||
|
||||
<body>
|
||||
|
||||
<p>This is a character entity: {</p>
|
||||
|
||||
</body>
|
||||
|
||||
</html>
|
||||
|
||||
运行代码,结果如下:
|
||||
|
||||
特别注意:在HTML中,最常见的字符实体就是不可拆分空格。通常,HTML会合并你文档中的空格。假如在你的HTML文本中连续写了10个空格,其中9个会被去掉。想要在HTML中插入空格,可以使用实体:
|
||||
|
||||
下面就列出一些常用的字符实体:其他一些常用的字符实体:
|
||||
{{./html-03.jpg}}
|
||||
{{./html-04.jpg}}
|
||||
BIN
Zim/Web-Design/HTML5/HTML字符实体/html-03.jpg
Normal file
|
After Width: | Height: | Size: 24 KiB |
BIN
Zim/Web-Design/HTML5/HTML字符实体/html-04.jpg
Normal file
|
After Width: | Height: | Size: 31 KiB |
107
Zim/Web-Design/HTML5/NOTES.txt
Normal file
@@ -0,0 +1,107 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-05T14:03:10+08:00
|
||||
|
||||
====== 一位css新手整理的css+div网页布局技巧 ======
|
||||
|
||||
网页制作 2011-04-25 16:36:00 阅读7 评论0 字号:大中小 订阅
|
||||
|
||||
对CSS网页布局的技巧,可谓是名目繁多,今天介绍一位CSS新手整理的CSS网页布局的小技巧,或许对您更有实际的参考价值:
|
||||
|
||||
1、ul标签在Mozilla中默认是有padding值的,而在IE中只有margin有值。
|
||||
|
||||
2、同一个的class选择符可以在一个文档中重复出现,而id选择符却只能出现一次;对一个标签同时使用class和id进行CSS定义,如果定义有重复,id选择符做的定义有效,是因为ID的权值要比CLASS大。
|
||||
|
||||
3、一个兼容性调整(IE和Mozilla)的笨办法:
|
||||
|
||||
初学可能会碰到这样一个情况:同样一个标签的属性在IE设置成A显示是正常的,而在Mozilla里必须要设成B才能正常显示,或者两个倒过来。
|
||||
|
||||
临时解决方法:选择符{属性名:B !important;属性名:A}
|
||||
|
||||
4、如果一组要嵌套的标签之间需要些间距的话,那就留给位于里面的标签的margin属性吧,而不要去定义位于外面的标签的padding
|
||||
|
||||
5、li标签前面的图标推荐使用background-image,而不是list-style-image。
|
||||
|
||||
6、IE分不清继承关系和父子关系的差别,全部都是继承关系。
|
||||
|
||||
7、在给你的标签疯狂加选择符的时候,别忘了在CSS里给选择符加上注释。 等你以后修改你的CSS的时候就知道为什么要这么做了。
|
||||
|
||||
8、如果你给一个标签设置了一个深色调的背景图片和亮色调的文字效果。建议这个时候给你的标签再设置一个深色调的背景颜色。
|
||||
|
||||
9、定义链接的四种状态要注意先后顺序: Link Visited Hover Active
|
||||
|
||||
10、与内容无关的图片请使用background
|
||||
|
||||
11、定义颜色可以缩写#8899FF=#89F
|
||||
|
||||
12、table在某些方面比其它标签表现的要好的多。请在需要列对齐的地方用它。
|
||||
|
||||
13、<script>没有language这个属性,应该写成这样:<script type=”text/javascript”>
|
||||
|
||||
14、标题是标题,标题的文字是标题的文字。有时候标题不一定需要显示文字,所以:<h1>标题内容</h1> 改成 <h1><span>标题内容</span></h1>
|
||||
|
||||
15、完美的单象素外框线表格(在IE5、IE6、IE7及FF1.0.4以上中均可通过测试)
|
||||
|
||||
table{border-collapse:collapse;}
|
||||
td{border:#000 solid 1px;}
|
||||
|
||||
16、margin取负值可以在标签使用绝对定位的时候起到相对定位的作用,在页面居中显示时,使用绝对定位的层不适合使用left:XXpx这个属性。把这个层放到一个要相对定位的标签旁,然后使用margin的负值是个好方法。
|
||||
|
||||
17、绝对定位时使用margin值定位可以达到相对于本身所在位置的定,这与top,left等属性相对与窗口边缘的定位不同。绝对定位的优势在于可以让其它元素忽略它的存在。
|
||||
|
||||
18、如果文字过长,则将过长的部分变成省略号显示:IE5,FF无效,但可以隐藏,IE6有效
|
||||
|
||||
<DIV STYLE=”width:120px;height:50px;border:1px solid blue;overflow:hidden;text-overflow:ellipsis”>
|
||||
<NOBR>就是比如有一行文字,很长,表格内一行显示不下。</NOBR>
|
||||
|
||||
19、在IE中可能由于注释带来的文字重复问题时可以把注释改为:
|
||||
|
||||
<!–[if !IE]>Put your commentary in here…<![endif]–>
|
||||
|
||||
20、如何用CSS调用外部字体
|
||||
|
||||
语法:
|
||||
@font-face{font-family:name;src:url(url);sRules}
|
||||
取值:
|
||||
name:字体名称。任何可能的 font-family 属性的值
|
||||
url(url):使用绝对或相对 url 地址指定OpenType字体文件
|
||||
sRules:样式表定义
|
||||
|
||||
21、如何让一个表单中的文本框中的文字垂直居中?
|
||||
|
||||
如果用行高与高度的组在FF中是没有效果的,办法就是定义上下补白就可以实现想想的效果了。
|
||||
|
||||
22、定义A标签要注意的小问题:
|
||||
|
||||
当我们定义a{color:red;}时,它代表了A的四种状态的样式,如果此时要定义一个鼠标放上的状态只要定义a:hover就可以了,其它三种状态就是A中所定义的样式。
|
||||
|
||||
只定义了一个a:link时,一定要记得把其它三种状态定义出来!
|
||||
|
||||
23、并不是所有样式都要简写:
|
||||
|
||||
当样式表前定义了如p{padding:1px 2px 3px 4px}时,在后续工程中又增加了一个样式上补白5px,下补白6px。我们并不一定要写成p.style1{padding:5px 6px 3px 4px}。可以写成p.style1{padding-top:5px;padding-right:6px;},你可能会感觉这样写还不如原来那样好,但你想没想过,你的那种写法重复定义了样式,另外你可以不必去找原来的下补白与左补白的值是多少!如果以后前一个样式P变了话,你定义的p.style1的样式也要变。
|
||||
|
||||
24、网站越大,CSS样式越多,开始做前,请做好充分的准备和策划,包括命名规则。页面区块划分,内部样式分类等。
|
||||
|
||||
25、几个常用到的CSS样式:
|
||||
|
||||
1)中文字两端对齐:text-align:justify;text-justify:inter-ideograph;
|
||||
|
||||
2)固定宽度汉字截断:overflow:hidden;text-overflow:ellipsis;white-space:nowrap;(不过只能处理文字在一行上的截断,不能处理多行。)(IE5以上)FF不能,它只隐藏。
|
||||
|
||||
3)固定宽度汉字(词)折行:table-layout:fixed; word-break:break-all;(IE5以上)FF不能。
|
||||
|
||||
4)<acronym title=”输入要提示的文字” style=”cursor:help;”>文字</acronym>用鼠标放在前面的文字上看效果。这个效果在国外的很多网站都可以看到,而国内的少又少。
|
||||
|
||||
5)图片设为半透明:。halfalpha { background-color:#000000;filter:Alpha(Opacity=50)}在IE6及IE5测试通过,FF未通过,这是因为这个样式是IE私有的东西;
|
||||
|
||||
6)FLASH透明:选中swf,打开原代码窗口,在</object>前输入<param name=”wmode” value=”transparent”> 以上是针对IE的代码。
|
||||
|
||||
针对FIREFOX 给<embed> 标签也增加类似参数wmode=”transparent”
|
||||
|
||||
7)在做网页时常用到把鼠标放在图片上会出现图片变亮的效果,可以用图片替换的技巧,也可以用如下的滤镜:
|
||||
|
||||
.pictures img {
|
||||
filter: alpha(opacity=45); }
|
||||
.pictures a:hover img {
|
||||
filter: alpha(opacity=90); }
|
||||
73
Zim/Web-Design/float.txt
Normal file
@@ -0,0 +1,73 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-15T11:03:10+08:00
|
||||
|
||||
====== CSS float 属性(CSS 参考手册) ======
|
||||
|
||||
首先我们了解到,CSS网页布局的原理,就是按照HTML代码中**对象声明的顺序**,以**流布局**的方式来显示它,而流布局就不得不说到float浮动技术,在HTML中的所有对象,默认分为两种:块元素(block element)、内联元素(inline element),虽然也存在着可变元素,但只是随上下文关系确定该元素是块元素或者内联元素。
|
||||
|
||||
|
||||
===== 定义和用法 =====
|
||||
|
||||
float 属性定义元素向水平方向左或右浮动。以往这个属性总应用于图像,使文本围绕在图像周围,不过在 CSS 中,任何元素都可以浮动。浮动元素会生成一个块级框,而不论它本身是何种元素,浮动后该元素脱离文档流。
|
||||
|
||||
其实CSS的float属性,作用就是改变块元素(block element)对象的默认显示方式。block对象设置了float属性之后,它将不再独自占据一行,可以浮动到左侧或右侧。
|
||||
|
||||
A floated element will move as far to the left or right as it can. Usually this means all the way to the left or right of the containing element.
|
||||
The elements __after__ the floating element will flow around it.The elements __before__ the floating element will not be affected.
|
||||
If an image is floated to the right, a following text flows around it, to the left.
|
||||
|
||||
===== Floating Elements Next to Each Other =====
|
||||
If you place several floating elements after each other, they will** float next to each other** __if there is room(同一行可以容纳这几个元素)__.
|
||||
Here we have made an image gallery using the float property:
|
||||
|
||||
.thumbnail
|
||||
{
|
||||
float:left;
|
||||
width:110px;
|
||||
height:90px;
|
||||
margin:5px;
|
||||
}
|
||||
|
||||
===== Turning off Float - Using Clear =====
|
||||
|
||||
Elements after the floating element will flow around it.** To avoid this**, use the clear property.
|
||||
The clear property specifies which sides of an element other floating elements are not allowed.
|
||||
Add a text line into the image gallery, using the clear property:
|
||||
|
||||
.text_line
|
||||
{
|
||||
clear:both;
|
||||
}
|
||||
|
||||
|
||||
如果浮动非替换元素,则要指定一个明确的宽度;否则,它们会尽可能地窄。
|
||||
|
||||
注释:假如在一行之上只有极少的空间可供浮动元素,那么这个浮动元素会跳至下一行,这个过程会持续到某一行拥有足够的空间为止。
|
||||
|
||||
|
||||
默认值: none
|
||||
继承性: no
|
||||
版本: CSS1
|
||||
JavaScript 语法: object.style.cssFloat="left"
|
||||
|
||||
===== 实例 =====
|
||||
把图像向右浮动:
|
||||
|
||||
img
|
||||
{
|
||||
float:right;
|
||||
}
|
||||
|
||||
|
||||
浏览器支持
|
||||
|
||||
所有主流浏览器都支持 float 属性。
|
||||
|
||||
注释:任何的版本的 Internet Explorer (包括 IE8)都不支持属性值 "inherit"。
|
||||
可能的值
|
||||
值 描述
|
||||
left 元素向左浮动。
|
||||
right 元素向右浮动。
|
||||
none 默认值。元素不浮动,并会显示在其在文本中出现的位置。
|
||||
inherit 规定应该从父元素继承 float 属性的值。
|
||||
81
Zim/Web-Design/float/CSS中float浮动属性详解.txt
Normal file
@@ -0,0 +1,81 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-15T20:18:55+08:00
|
||||
|
||||
====== CSS中float浮动属性详解 ======
|
||||
Created Sunday 15 May 2011
|
||||
http://www.tonjay.com/website/css-float.html
|
||||
|
||||
搞网页布局的朋友都知道,浮动(float)真是一个好用的css属性。但有些时候一不小心就有可能因为这个小小的属性带来很大的麻烦。今天我们就打入到敌人内部,看看浮动(float)究竟是个什么玩意儿。知已知彼方能百战不殆嘛。
|
||||
|
||||
===== 什么是浮动? =====
|
||||
|
||||
浮动是 css 的定位属性。我们可以看一下印刷设计来了解它的起源和作用。印刷布局中,文本可以按照需要围绕图片。一般把这种方式称为“文本环绕”。这是一个例子:
|
||||
{{./1-print-layout.png}}
|
||||
在排版软件里面,存放文字的盒子可以被设置为允许图文混排,或者无视它。无视图文混排将会允许文字出现在图片的上面,就像它甚至不会在那里一样。这就是图片是否是页面流的一部分的区别。网页设计与此非常类似。
|
||||
|
||||
在网页设计中,应用了CSS的float属性的页面元素就像在印刷布局里面的被文字包围的图片一样。**浮动的元素仍然是网页流的一部分**。这与使用绝对定位的页面元素相比是一个明显的不同。**绝对定位的页面元素被从网页流里面移除了**,就像印刷布局里面的文本框被设置为无视页面环绕一样。绝对定位的元素不会影响其它元素,其它元素也不会影响它,无论它是否和其它元素挨着。
|
||||
|
||||
像这样在一个元素上用CSS设置浮动:
|
||||
|
||||
#sidebar { float: right; }
|
||||
|
||||
fload属性有四个可用的值:Left 和Right 分别浮动元素到各自的方向,None (默认的) 使元素不浮动,Inherit 将会从父级元素获取float值。
|
||||
|
||||
===== 浮动的用处 =====
|
||||
|
||||
除了简单的在图片周围包围文字,浮动可用于创建全部网页布局
|
||||
{{./2-web-layout.png}}
|
||||
浮动对小型的布局同样有用。例如页面中的这个小区域。如果我们在我们的小头像图片上使用浮动,当调整图片大小的时候,盒子里面的文字也将自动调整位置:
|
||||
{{./3-reflow-example-1.png}}
|
||||
|
||||
同样的布局可以通过在**外容器使用相对定位,然后在头像上使用绝对定位来实现**。这种方式中,文本不会受头像图片大小的影响,不会随头像图片的大小而有相应变化。
|
||||
{{./4-reflow-example-2.png}}
|
||||
|
||||
===== 清除浮动 =====
|
||||
|
||||
清除(clear)是浮动(float)的相关属性.一个设置了清除浮动的元素不会如浮动所设置的一样,向上移动到浮动元素的边界,而是会忽视浮动向下移动。如下,一图顶千言。
|
||||
{{./5-unclearedfooter.png}}
|
||||
上例中,侧栏向右浮动,并且短于主内容区域。页脚(footer)于是按浮动所要求的向上跳到了可能的空间。要解决这个问题,可以在页脚(footer)上清除浮动,以使页脚(footer)待在浮动元素的下面。
|
||||
{{./6-clearedfooter.png}}
|
||||
#footer { clear: both; }
|
||||
|
||||
清除(clear)也有4个可能值。最常用的是 both,清楚左右两边的浮动。left 和 right 只能清楚一个方向的浮动。none 是默认值,只在需要移除已指定的清除值时用到。inherit 应该时第五个值,不过很奇怪的是 IE 不支持(这个不奇怪吧,IE 从来都这么特立独行吧 -糖伴西红柿注)。只清除左边或右边的浮动,实际中很少见,不过绝对有他们的用处。
|
||||
|
||||
===== 伟大的塌陷 =====
|
||||
|
||||
使用浮动(float)的一个比较疑惑的事情是__他们怎么影响包含他们的父元素的__。__如果父元素只包含浮动元素,那么它的高度就会塌缩为零__。如果父元素不包含任何的可见背景,这个问题会很难被注意到,但是这是一个很重要的问题。
|
||||
{{./8-collapse.png}}
|
||||
塌陷的直观对立面更不好,看看下面的情况:
|
||||
{{./7-directionalclearing.png}}
|
||||
当上面的块级元素自动扩展以适应浮动元素时,段落间的文本流中会出现非自然的空白换行,而且没有有效的方法来修正这个问题。对于这种情况,设计师的抱怨会更甚于对塌陷的抱怨。
|
||||
|
||||
为了防止怪异的布局和跨浏览器的问题,塌陷问题几乎总是被要处理的。__我们在容器中的浮动元素之后,容器结束之前来清除浮动__。
|
||||
|
||||
===== 清除浮动的技术 =====
|
||||
|
||||
如果你很**明确的知道接下来的元素会是什么**,可以使用 clear:both; 来清除浮动。这个方法很不错,它不需要 hack,不添加额外的元素也使得它有良好的语义性。当然事情并不是都可以这样解决的,工具箱中还是需要另外几个清除浮动的工具。
|
||||
|
||||
__空div方法 __ 从字面来看,是一个空的 div。有时可能会用或者一些其他元素,但是 div 是最常用的,因为它**没有浏览器默认样式;没有特殊功能,而且一般不会被 css 样式化**。这个方法因为只是为了表现,**对页面没有上下文涵义而被纯语义论者嘲笑**。诚然,从严格的角度来说他们是对的,但是这个方法有效而且没有任何伤害。
|
||||
__ overflow方法__ 在父元素上设置 overflow 这个 css 属性。如果父元素的这个属性设置为 auto 或者 hidden,父元素就会扩展以包含浮动。这个方法有着较好的语义性,因为他不需要额外元素。但是,如果需要增加一个新的 div 来使用这个方法,其实就和空 div 方法一样没有语义了。而且要记住,overflow 属性不是为了清除浮动而定义的。要小心不要覆盖住内容或者触发了不需要的滚动条。
|
||||
__简单清除方法 __使用了一个聪明的 css 伪选择符(:after)来清除浮动。比起在父元素上设置 overflow,只需要给它增加一个额外的类似于”clearfix”的类。这个类使用如下 css:
|
||||
.clearfix:after {content: “.”; visibility: hidden; display: block; height: 0; clear: both;}
|
||||
这会在清除浮动的父元素之后应用一点看不见的内容。这不是全部内容,还需要一些额外的代码来适应那些老旧的浏览器。
|
||||
|
||||
不同的情况需要不同的浮动清除方法。以一个具有不同样式块的网格为例:
|
||||
{{./10-grid-blocks.png}}
|
||||
为了从视觉上较好的把相似的块联系起来,需要在必要的地方开启新行,这里是颜色改变的地方。如果每个颜色组都有一个父元素的话,我们可以使用 overflow 或者简单清除方法,或者在每组之间用一个空div方法。
|
||||
{{./11-grid-blocks-cleared.png}}
|
||||
|
||||
===== 浮动的问题 =====
|
||||
|
||||
浮动因脆弱而饱受诟病。大多数的脆弱性来自于 IE6 及其一系列的浮动相关 bug。因为越来越多的设计师不再支持 IE6 了,你也可以不关注它了。不过对于那些要关注的人来说,这里有些大概。
|
||||
|
||||
__推倒__ 是浮动元素内的元素(大多是图片)比浮动元素本身宽造成的现象。大多数的浏览器会在浮动之外渲染图片,但是不会有伸出来的部分影响其他布局。IE 会扩展浮动来包含图片,精彩大幅度地影响布局。一个普遍的例子是突破伸出主内容之外把侧栏推到下面(这是因为两栏都是浮动的)。
|
||||
{{./12-pushdown2.png}}
|
||||
快速修正:确保不是图片造成这种情况,使用 **overflow:hidden** 来切除多余的部分。
|
||||
|
||||
双倍边距bug 处理 IE6 时,另一个需要记住的事情是,如果在和浮动方向相同的方向上设置外边距(margin),会引发双倍边距。快速修正:给浮动设置 display:inline; 而且不用担心,它依然是块级元素
|
||||
3像素间距 是指挨着浮动元素的文本会神奇的被踢出去3像素,好像浮动元素的周围有一个奇怪的力场一样。快速修正:在受影响的文本上设置宽度或高度。
|
||||
IE7 中,底边距 bug是当浮动父元素有浮动子元素时,这些子元素的底边距会被父元素忽略掉。快速修正:用父元素的底内补白(padding)代替。
|
||||
|
||||
BIN
Zim/Web-Design/float/CSS中float浮动属性详解/1-print-layout.png
Normal file
|
After Width: | Height: | Size: 8.6 KiB |
BIN
Zim/Web-Design/float/CSS中float浮动属性详解/10-grid-blocks.png
Normal file
|
After Width: | Height: | Size: 5.8 KiB |
BIN
Zim/Web-Design/float/CSS中float浮动属性详解/11-grid-blocks-cleared.png
Normal file
|
After Width: | Height: | Size: 8.8 KiB |
BIN
Zim/Web-Design/float/CSS中float浮动属性详解/12-pushdown2.png
Normal file
|
After Width: | Height: | Size: 3.7 KiB |
BIN
Zim/Web-Design/float/CSS中float浮动属性详解/2-web-layout.png
Normal file
|
After Width: | Height: | Size: 3.7 KiB |
BIN
Zim/Web-Design/float/CSS中float浮动属性详解/3-reflow-example-1.png
Normal file
|
After Width: | Height: | Size: 6.4 KiB |
BIN
Zim/Web-Design/float/CSS中float浮动属性详解/4-reflow-example-2.png
Normal file
|
After Width: | Height: | Size: 7.3 KiB |
BIN
Zim/Web-Design/float/CSS中float浮动属性详解/5-unclearedfooter.png
Normal file
|
After Width: | Height: | Size: 3.9 KiB |
BIN
Zim/Web-Design/float/CSS中float浮动属性详解/6-clearedfooter.png
Normal file
|
After Width: | Height: | Size: 3.8 KiB |
BIN
Zim/Web-Design/float/CSS中float浮动属性详解/7-directionalclearing.png
Normal file
|
After Width: | Height: | Size: 4.1 KiB |
BIN
Zim/Web-Design/float/CSS中float浮动属性详解/8-collapse.png
Normal file
|
After Width: | Height: | Size: 3.7 KiB |
BIN
Zim/Web-Design/float/CSS中float浮动属性详解/9-web-layout1.png
Normal file
|
After Width: | Height: | Size: 3.7 KiB |
@@ -0,0 +1,101 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-15T16:47:17+08:00
|
||||
|
||||
====== How to completely enclose a floated element in CSS2 ======
|
||||
Created Sunday 15 May 2011
|
||||
http://www.cs.hmc.edu/~mbrubeck/clear-after/
|
||||
Author: Matt Brubeck
|
||||
Date: 2003-06-24
|
||||
|
||||
===== Introduction =====
|
||||
|
||||
Consider the following CSS and HTML:
|
||||
|
||||
.item { border: 1px solid black; padding: 0.5em; }
|
||||
img { float: left; }
|
||||
|
||||
<div class="item">
|
||||
<img src="monkey.png"/>
|
||||
<p>One time I hired a monkey to
|
||||
take notes for me in class.</p>
|
||||
</div>
|
||||
|
||||
Here's how this renders in Mozilla (example 1):
|
||||
{{./screenshot1.png}}
|
||||
Screenshot 1
|
||||
|
||||
**PS:**这是因为img已经脱离了文档流,**div的大小由其padding和内部的段落空间决定**。下图为一个设置了padding:10px的dvi,其中内容为一个段落。
|
||||
注意:段落框大小由其上下margin和内容高度决定。
|
||||
{{./space-of-dvi.png?width=600}}
|
||||
If the image is taller than the text, it overruns the border of the enclosing div (except in IE/Win; see browser compatibility below). In some cases this is the desired behavior, but what if we want the border to fully enclose both the image and the text? This document describes the only way I know to do this using completely general, standards-compliant, clean CSS and HTML.
|
||||
|
||||
===== Spacer div hack =====
|
||||
|
||||
One common solution to this problem is known as the "spacer div" hack. We can __force the outer div to fully contain both elements by adding an element with __**clear: both **__to the end of the div:__
|
||||
|
||||
img { float: left; padding: 0.5em; }
|
||||
.item { border: 1px solid black; }
|
||||
**.spacer { clear: both; }**
|
||||
|
||||
<div class="item">
|
||||
<img src="monkey.png"/>
|
||||
<p>One time I hired a monkey to
|
||||
take notes for me in class.</p>
|
||||
**<div class="spacer"></div>**
|
||||
</div>
|
||||
|
||||
This works, but it requires us to add a new element to our HTML for purely presentational reasons. That means we would have to add markup to every "item" div on our site, __costing us time and bandwidth.__ A CSS-only solution would save effort and bandwith, and avoid polluting our markup with meaningless elements.
|
||||
|
||||
**PS**:div的框参数为0,因此上面加粗的空内容div大小为0;div 没有浏览器默认样式,没有特殊功能,而且一般不会被 css 样式化。
|
||||
|
||||
===== CSS3 clear-after property =====
|
||||
|
||||
The CSS3 working draft defines a new property,__ clear-after__, which has the desired effect without any markup changes. We can return to the original markup, and simply add the following rule to our stylesheet:
|
||||
|
||||
__.item __{ clear-after: both; }
|
||||
|
||||
This rule has the same effect as an element with clear: both at the end of the div, as in the "spacer div" hack above. Unlike the spacer div hack, it achieves this effect without needing the change the markup.
|
||||
|
||||
Unfortunately, the clear-after property is not implemented by any current browsers. CSS3 is still in development, and the clear-after property may change before it is standardized.
|
||||
|
||||
===== Solution: CSS2 generated content =====
|
||||
|
||||
Fortunately, we can create the same effect using only CSS2:
|
||||
|
||||
.item__:after __{ content: ""; display: block; height: 0; clear: both; }
|
||||
|
||||
This uses the same method as the "spacer div" hack:** it adds an element at the end of the container div**, forcing its bottom border to clear the float. By using the __:after pseudo-selector__ we can generate the extra element from our stylesheet, with no changes to our HTML files.
|
||||
|
||||
Here's the new version of our markup:
|
||||
|
||||
.item { border: 1px solid black; padding: 0.5em; }
|
||||
img { float: left; }
|
||||
__.item:after { content: ""; display: block; height: 0; clear: both; }__
|
||||
|
||||
<div class="item">
|
||||
<img src="monkey.png"/>
|
||||
<p>One time I hired a monkey to
|
||||
take notes for me in class.</p>
|
||||
</div>
|
||||
|
||||
and this what it looks like in Mozilla (example 2):
|
||||
{{./screenshot2.png}}
|
||||
Screenshot 2
|
||||
|
||||
**PS:**上面的display:block是必需的,因为行内元素的上下margin是不起作用的。
|
||||
|
||||
==== Browser compatibility ====
|
||||
|
||||
The :after pseudo-selector is supported in Mozilla 1.x, Netscape 6 and 7, and Opera 7.
|
||||
It is not supported in IE 5 or 6, for either Windows or Macintosh (I haven't tested IE/Mac).
|
||||
(Updated 2003-06-24) Adding height: 100%; causes IE6/Win to expand a containing block around its floated children. Example 3 uses this technique to create a page that works in Mozilla, Netscape 6/7, IE6, and Opera 7 (not tested with other browsers). Note that the containing block must be inside another block-level element. If its immediate parent is the body element, then the height: 100% style will make it fill the entire viewport, at least in IE6.
|
||||
About this document
|
||||
|
||||
The "spacer div" hack has been discussed in many places, including this article on A List Apart.
|
||||
|
||||
My CSS2 implementation of clear-after is based on a suggestion by Lydia Lalopolis on the www-style mailing list. My version corrects the problem in Lydia's suggestion pointed out by David Baron.
|
||||
|
||||
An article on Mezzoblue discusses this problem and its solutions. Mr. Brownstone's comment points out that adding height: 100%; leads to correct results in IE6.
|
||||
|
||||
Please send any comments to mbrubeck@hmc.edu.
|
||||
|
After Width: | Height: | Size: 123 KiB |
|
After Width: | Height: | Size: 2.8 KiB |
|
After Width: | Height: | Size: 3.0 KiB |
|
After Width: | Height: | Size: 99 KiB |
157
Zim/Web-Design/float/containing_float.txt
Normal file
@@ -0,0 +1,157 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-15T13:55:43+08:00
|
||||
|
||||
====== containing float ======
|
||||
Created Sunday 15 May 2011
|
||||
http://www.complexspiral.com/publications/containing-floats/#fn1
|
||||
|
||||
As powerful and useful as they are, floats can make for tricky layout tools. Chances are that you may have seen something like the situation shown in Figure 1, which is accomplished with just two div elements, each with a floated image inside it.
|
||||
{{./fig1.gif}}
|
||||
Figure 1. That's not right!
|
||||
|
||||
This is probably not what the author had in mind, but given the styles used, it's the correct layout. Here's how we created it:
|
||||
|
||||
div.item {border: 1px solid; padding: 5px;}
|
||||
div.item img {float: left; margin: 5px;}
|
||||
|
||||
That's all it takes. The result seen in Figure 1 happens because __the div elements don't "stretch" to contain the floated images within them__. To look at the situation from the reverse angle, it happens because the floated images "stick out" of the bottom of the div elements.
|
||||
|
||||
**PS:**这是因为float的元素成为块级元素且脱离了原来的文档流。
|
||||
|
||||
This is not a bug. It's also not a flaw in CSS. It is, in fact, __the behavior that most authors will want most of the time__. It's just not what they would want in the example shown in Figure 1.
|
||||
|
||||
===== Understanding the Problem =====
|
||||
|
||||
So when in the name of all that's good and right would authors want floats to stick out of their containing elements? Simple: in what is historically the most common case for float use. Consider Figure 2, and the basic markup structure that produced it.
|
||||
{{./fig2.gif?width=331}}
|
||||
Figure 2. Floating an image, flowing the text.
|
||||
|
||||
<p>
|
||||
...text...
|
||||
__<img__ src="jul31-03-sm.jpg" height="200" border="0" class="picture">
|
||||
...text...
|
||||
__</p>__
|
||||
<p>
|
||||
...text...
|
||||
</p>
|
||||
|
||||
**PS:**图片脱离了所在段落的文档流且float到__原来所在行__(因为开始img是一个行内元素)的父元素的左侧,图片被float后成为一个块级元素且其__margin-top与所在行平行__。
|
||||
|
||||
1.行内元素inline-element的横向框参数起作用(宽度等于字符内容的总宽度而不像块元素没指定宽度时占满所在行的全部宽度),但纵向框参数如padding, border, margin没有起到应有的像块级元素一样的隔离和突出作用,而是溢出所在的行并有可能覆盖前后行的内容。
|
||||
|
||||
{{./10-inline-elem.png?width=500}}
|
||||
{{./1-inline-block.png?width=500}}
|
||||
{{./11-inline-elem.png?width=500}}
|
||||
|
||||
2.float行内元素后该元素float到父元素的左侧成为一个块元素,**该块元素的margin-top与所在行平行**。
|
||||
{{./3-floated-element.png?width=500}}
|
||||
当一行容纳不下float对象时他将下移多行直到可以容纳下为止如:
|
||||
{{./8-before-float-inline-elem.png?width=500}}
|
||||
PS:本来将float的元素从第二行开始但由于容纳不下,故下移一行从第三行开始
|
||||
{{./9-after-float-inline-elem.png?width=500}}
|
||||
{{./12-float.png?width=500}}
|
||||
3.被float的元素将脱离原来的文本流。该元素前面的块级元素不受影响,但该元素后面的块级元素或所在行的其他字符将受影响。如下图所示,包含float段落的上一段落没受影响,但所在的段落文字将环绕float元素。
|
||||
|
||||
{{./5-float-element-.png?width=500}}
|
||||
注意:float元素位于文本流上方,会受到文本流中背景的影响。
|
||||
{{./7-float-background.png?width=500}}
|
||||
|
||||
The practice of flowing text around an image goes back a long, long time. That's why the ability was added to the Web starting with Netscape 1.1, and why CSS makes it possible using the property float.[1] But look closely at Figure 2. __The floated image is sticking out of its containing element.__ We can see this more clearly by adding borders to the paragraphs, as shown in Figure 3.
|
||||
{{./fig3.gif?width=352}}
|
||||
Figure 3. Adding borders to the paragraphs.
|
||||
|
||||
So now we can see why it's important that __floats stick out of their containing elements__. If they didn't, then Figure 2 would have looked like Figure 4 instead.
|
||||
{{./fig4.gif}}
|
||||
Figure 4. If floats expanded their ancestor elements.
|
||||
|
||||
That's something __designers would never have accepted.__ So, in order to keep with Web design tradition and author expectation, CSS is written to allow floated elements to stick out of the bottom of their containing elements. While this is necessary for normal text flow, i__t's a major problem when floats are used for layout purposes__.
|
||||
|
||||
===== A Clear Solution =====
|
||||
|
||||
__If floats are to be used in creating non-table layouts, then there needs to be a way to make their containing elements stretch around them. __At present, this requires __a bit of a structural hack__. Since we want the bottom of the containing element to be placed clear past the bottom of the float, then clear is our answer. __We need only insert a block-level element just before the end of the container, and clear it.__ Consider:
|
||||
|
||||
<div class="item">
|
||||
<img src="w6144.gif">
|
||||
Widget 6144
|
||||
<br>$39.95
|
||||
__ <hr>__
|
||||
</div>
|
||||
<div class="item">
|
||||
<img src="w6145.gif">
|
||||
Widget 6145
|
||||
<br>$44.95
|
||||
__<hr>__
|
||||
</div>
|
||||
|
||||
Now we apply the following rules to the preceding markup, and get the result shown in Figure 5.
|
||||
|
||||
div.item hr {**display: block; clear: left;** margin: -0.66em 0; **visibility: hidden**;}
|
||||
{{./fig5.gif}}
|
||||
Figure 5. Using a horiztonal rule to force expansion.
|
||||
|
||||
By ensuring that __the hr elements are block-level__, part of the normal flow, and cleared, we force the divs to "stretch around" the left-floated images.
|
||||
|
||||
**PS:**因为inline-level 元素的纵向框参数不起突出和隔离作用而是溢出所在的行,block-level的纵向margin总是起作用。
|
||||
|
||||
The __negative top and bottom margins __have the general effect of closing up the space that the hr occupies. However, this effect is not precise, and not necessarily identical across browsers. The semi-mysterious nature of horizontal rules makes it difficult to predict exactly what will happen. The effective height of the hr might be zero, or a small positive amount, or even a negative height.
|
||||
|
||||
Therefore, in situations where a precise clearing effect is needed, authors can __use a div instead of an hr to create a clearing effect__. For example:
|
||||
|
||||
div.clearer {clear: left; **line-height: 0; height: 0;**}
|
||||
|
||||
<div class="item">
|
||||
<img src="w6144.gif">
|
||||
Widget 6144
|
||||
<br>$39.95
|
||||
** <div class="clearer"> </div>**
|
||||
</div>
|
||||
PS:height是框里内容的高度,使用div块元素是因为其框参数如padding,border,margin都为0。下图中蓝色为内容所占的height,宽度为块元素的特性:占满一行。
|
||||
{{./div-margin-0.png?width=700}}
|
||||
将height设为0时会使内容溢出,但默认的overflow=visible,会使溢出区域显示。
|
||||
{{./div-height=0.png?width=800}}
|
||||
|
||||
===== Set a Float to Fix a Float =====
|
||||
|
||||
There is a way to avoid over-use of the structural hacks discussed so far, although they are still necessary at times. In most browsers, and as defined in CSS2.1, __a floated element will expand to contain any floated elements that descend from it. __So in our widget example, we could remove all of the "clearer" elements and instead write these styles:
|
||||
|
||||
div.item {**float: left;** border: 1px solid; padding: 5px; **width: 60%**;}
|
||||
div.item img {float: left; margin: 5px;}
|
||||
|
||||
Note that we've floated both the images and the "item" divs. By setting the width of the divs to be greater than 50%, we ensure that they will **never be next to each other**, but will instead stack up vertically. This has the result shown in Figure 6.
|
||||
{{./fig6.gif}}
|
||||
Figure 6. Using floats to stretch around floats.
|
||||
|
||||
This is obviously simpler to manage, both in terms of markup and style. However, the hacks discussed thus far are still useful. Suppose you want to put some advisory text underneath the items. In order to keep the text from flowing to the right of the items(因为上面的两个div都是浮动的,接着第二个div的元素有可能会浮动到它的右边), we need to__ insert a clearing hack__. This would lead us to create markup like the following, which is illustrated in Figure 7.
|
||||
|
||||
<div class="item">
|
||||
<img src="w6144.gif">
|
||||
Widget 6144
|
||||
<br>$39.95
|
||||
</div>
|
||||
<div class="item">
|
||||
<img src="w6145.gif">
|
||||
Widget 6145
|
||||
<br>$44.95
|
||||
</div>
|
||||
|
||||
**<div class="clearer"> </div>**
|
||||
<p>Widgets are sold on an "as is" basis without
|
||||
warranty or guarantee.</p>
|
||||
|
||||
div.clearer {clear: left; **line-height: 0; height: 0;**}
|
||||
{{./fig7.gif}}
|
||||
Figure 7. Floats and hacks get the desired layout.
|
||||
|
||||
The clearing div effectively **pushes the normal flow downward**, forcing any following content to flow after the cleared element, and therefore after the floated divs.
|
||||
|
||||
The potential drawback to using floats to contain floats is that you rely on browsers to consistently interpret the layout of multiple nested floated elements. The situation becomes more fragile if these floats are part of a more complicated layout, one possibly using floats, positioning, or tables. This is not to say such layouts are impossible to achieve. They may, however, involve a good deal of trial and error to avoid obscure floating and other layout bugs that may lurk inside rendering engines.
|
||||
|
||||
===== Summary =====
|
||||
|
||||
By understanding how floats and the normal flow relate to each other, and understanding how clearing can be used to manipulate the normal flow around floats, authors can employ floats as a very powerful layout tool. Because floats were not originally intended to be used for layout, some hacks may be necessary to make them behave as intended. **This can involve floating elements that contain floats, "clearing" elements, or a combination of both.**
|
||||
|
||||
Looking to the future, there have been a variety of proposed enhancements to CSS that would allow an author to declare that an element should stretch to contain any floated elements within itself. These would obviously be welcome additions to CSS, but as of this writing, support for such abilities is likely to be a long time coming.
|
||||
|
||||
[1] The term "float" refers to the way in which an element floats to one side and down, as described in the original "Additions to HTML 2.0" document that accompanied the release of Netscape 1.1.
|
||||
|
||||
BIN
Zim/Web-Design/float/containing_float/1-inline-block.png
Normal file
|
After Width: | Height: | Size: 94 KiB |
BIN
Zim/Web-Design/float/containing_float/10-inline-elem.png
Normal file
|
After Width: | Height: | Size: 88 KiB |
BIN
Zim/Web-Design/float/containing_float/11-inline-elem.png
Normal file
|
After Width: | Height: | Size: 92 KiB |
BIN
Zim/Web-Design/float/containing_float/12-float.png
Normal file
|
After Width: | Height: | Size: 97 KiB |
BIN
Zim/Web-Design/float/containing_float/2-float-left.png
Normal file
|
After Width: | Height: | Size: 88 KiB |
BIN
Zim/Web-Design/float/containing_float/3-floated-element.png
Normal file
|
After Width: | Height: | Size: 93 KiB |
BIN
Zim/Web-Design/float/containing_float/4-element-before-float.png
Normal file
|
After Width: | Height: | Size: 88 KiB |
BIN
Zim/Web-Design/float/containing_float/5-float-element-.png
Normal file
|
After Width: | Height: | Size: 92 KiB |
|
After Width: | Height: | Size: 92 KiB |
BIN
Zim/Web-Design/float/containing_float/7-float-background.png
Normal file
|
After Width: | Height: | Size: 88 KiB |
|
After Width: | Height: | Size: 95 KiB |
|
After Width: | Height: | Size: 94 KiB |
BIN
Zim/Web-Design/float/containing_float/div-height=0.png
Normal file
|
After Width: | Height: | Size: 85 KiB |
BIN
Zim/Web-Design/float/containing_float/div-margin-0.png
Normal file
|
After Width: | Height: | Size: 88 KiB |
BIN
Zim/Web-Design/float/containing_float/fig1.gif
Normal file
|
After Width: | Height: | Size: 4.7 KiB |
BIN
Zim/Web-Design/float/containing_float/fig2.gif
Normal file
|
After Width: | Height: | Size: 22 KiB |
BIN
Zim/Web-Design/float/containing_float/fig3.gif
Normal file
|
After Width: | Height: | Size: 23 KiB |
BIN
Zim/Web-Design/float/containing_float/fig4.gif
Normal file
|
After Width: | Height: | Size: 22 KiB |
BIN
Zim/Web-Design/float/containing_float/fig5.gif
Normal file
|
After Width: | Height: | Size: 4.9 KiB |
BIN
Zim/Web-Design/float/containing_float/fig6.gif
Normal file
|
After Width: | Height: | Size: 4.7 KiB |
BIN
Zim/Web-Design/float/containing_float/fig7.gif
Normal file
|
After Width: | Height: | Size: 5.8 KiB |
82
Zim/Web-Design/height.txt
Normal file
@@ -0,0 +1,82 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-15T15:56:40+08:00
|
||||
|
||||
====== height ======
|
||||
Created Sunday 15 May 2011
|
||||
http://www.tutwow.com/htmlcss/quick-tip-css-100-height/
|
||||
|
||||
|
||||
===== Quick Tip: CSS 100% Height =====
|
||||
September 11, 2008 in HTML/CSS, Tips
|
||||
171
|
||||
|
||||
I don’t know about you, but I always get frustrated trying to figure out how to get my layout to stretch vertically to 100% of the page. I have a div that I want to stretch, but it just doesn’t stretch. Now why wouldn’t it do that? Today I will share the solution with you.
|
||||
|
||||
Say you have coded an HTML file like this:
|
||||
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
||||
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||||
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
|
||||
|
||||
<title>CSS 100% Height</title>
|
||||
<link rel="stylesheet" type="text/css" href="style.css" />
|
||||
</head>
|
||||
|
||||
<body>
|
||||
<div id="content">
|
||||
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
And you have a CSS file like this:
|
||||
|
||||
body {
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
}
|
||||
#content {
|
||||
background: #EEE;
|
||||
border-left: 1px solid #000;
|
||||
border-right: 1px solid #000;
|
||||
padding: 0 20px 0 20px;
|
||||
margin: auto;
|
||||
font: 1.5em arial, verdana, sans-serif;
|
||||
width: 960px;
|
||||
height: 100%;
|
||||
}
|
||||
|
||||
That gives you this example file. As you can see, the content box on that page doesn’t stretch to the whole height of the page, even though we added the “height: 100%;” line to the CSS file. Why is that?
|
||||
|
||||
Let me give you a different way of thinking about HTML. HTML is pretty much just a bunch of containers stacked inside each other. So in our page, first we have the <html> container, then the <body> container inside of that, and finally the <div id=”content”> container inside of that. When we put content into one of those boxes, it stretches that box and all the boxes containing that box so that they can hold the new content. So when we put our text into the <div id=”content”> box, that box streches, which in turn stretches all of the boxes that it is in (in our case the <body> and <html> boxes).
|
||||
|
||||
When we put the “height: 100%;” style onto the <div id=”content”> box, what we are doing is telling it to stretch to the full height of the box that it is in. In this example, the box that it is in is the <body> box. So the <div id=”content”> box is 100% of the height of the <body> box. Well, how tall is the <body> box? It’s just as tall as the <div id=”content”> box, because we never told it how tall it should be! So when we put the “height: 100%;” style onto the <div id=”content”> box, we are just telling it to be as tall as itself!
|
||||
|
||||
To fix this, we need to tell the <body> box to get bigger. But then we run into the same problem with the <html> box – it is only as big as the <body> box! So to fix our problem (to get the <div id=”content”> box to stretch the whole height of the page), we need to tell the <html> and <body> boxes to be the full height of the page.
|
||||
|
||||
So if we change our CSS file to this:
|
||||
|
||||
html {
|
||||
height: 100%;
|
||||
}
|
||||
body {
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
height: 100%;
|
||||
}
|
||||
#content {
|
||||
background: #EEE;
|
||||
border-left: 1px solid #000;
|
||||
border-right: 1px solid #000;
|
||||
padding: 0 20px 0 20px;
|
||||
margin: auto;
|
||||
font: 1.5em arial, verdana, sans-serif;
|
||||
width: 960px;
|
||||
height: 100%;
|
||||
}
|
||||
|
||||
And that’s it! This is what we have now. The content box is now stretched to the full height of the page!
|
||||
120
Zim/Web-Design/height/CSS中line-height属性详解.txt
Normal file
@@ -0,0 +1,120 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-15T19:18:15+08:00
|
||||
|
||||
====== CSS中line-height属性详解 ======
|
||||
Created Sunday 15 May 2011
|
||||
|
||||
其实想成为一个页面布局高手,并不是那么的容易!像我这样的上不了台面的水平,也就是在真正牛B的天地之外小打小闹混口饭吃而已。不过,我觉得若是有时间深入的了解一下css其中的微妙知识点,也是一件不错的事。技多不压身嘛。这是今天偶尔看到的一篇文章,对line-height属性讲解十分详细,相当不错。对于想深入了解css的童鞋们是一个不错的教程。下面开始播放:
|
||||
|
||||
**行高指的是文本行的**__基线__**间的距离,但是文本之间的空白距离不仅仅是行高决定的,同时也受**__字号__**的影响。**
|
||||
|
||||
===== 语法 =====
|
||||
|
||||
line-height属性的具体定义列表如下:
|
||||
|
||||
语法: line-height : normal | <实数> | <长度> | <百分比> | inherit
|
||||
说明: 设置元素中行的高度。
|
||||
值: normal:默认行高,一般为1到1.2; 实数:实数值,缩放因子; 长度:合法的长度值,可为负数; 百分比:百分比取值基于元素的字体尺寸。
|
||||
初始值: normal
|
||||
继承性: 继承
|
||||
适用于: 所有元素
|
||||
媒体: 视觉
|
||||
计算值: 长度和百分比值为绝对值;其他同指定值。
|
||||
|
||||
__行高__指的是文本行的基线间的距离。而基线(Base line),指的是一行字横排时下沿的基础线,**基线并不是汉字的下端沿,而是英文字母x的下 端沿**,同时还有文字的顶线(Top line)、中线(Middle line)和底线(Bottom line),用以确定文字行的位置,如下图 所示:
|
||||
{{./1.gif}}
|
||||
行高与字体尺寸的差称为__行距__(leading),如下图所示:
|
||||
{{./2.gif}}
|
||||
|
||||
|
||||
|
||||
===== 内容区域、行内框和行框 =====
|
||||
|
||||
理论上讲,一行中的每个元素都有一个__内容区域,它是由字体尺寸决定__的,如下图所示:
|
||||
{{./3.gif}}
|
||||
|
||||
行内元素会生成一个__行内框__(inline box),行内框只是一个概念,它__无法显示__出来,但是它又确实存在。在没有其他因素影响的时候,行内框等于内容区域,而设定行高则可以增加或者减少行内框的高度,即:__将行距的值(行高-字体尺寸)除以2,分别增加到内容区域的上下两边__,如下图所示:
|
||||
{{./4.gif}}
|
||||
由于行高可以应用在任何元素上,因此同一行内的若干元素可能有不同的行高和行内框高,例如有如下代码,其显示如下图所示。
|
||||
{{./5.gif}}
|
||||
|
||||
<p style=”line-height:20px;”>行高20px。
|
||||
<strong style=”line-height:50px;”> 行高50px。</strong>
|
||||
<span style=”line-height:30px;”>行高30px。</span>
|
||||
</p>
|
||||
|
||||
这里又有一个新的概念——__行框__(line box)。同行内框类似,行框是指本行的一个虚拟的矩形框,其高度等于__本行内所有元素中行高最大的值__。因此,当有多行内容时,每行都会有自己的行框,如下图所示:
|
||||
{{./6.gif}}
|
||||
提示:理解行框和行内框的概念对于学习本章[7.4垂直对齐:vertical-align属性]一节的内容非常重要。
|
||||
注意:行框的高度只同本行内元素的行高有关,而和父元素的高度(height)无关。
|
||||
|
||||
__小结:__
|
||||
行距是相邻两行的上一行基线和下一行的顶线间距离
|
||||
行高是相邻两行间的基线间距离。
|
||||
内容区域由字体尺寸决定,两者相等。
|
||||
行内框由其内的字体尺寸和line-height决定。
|
||||
行框由同一行中最大的行内框决定。
|
||||
|
||||
|
||||
|
||||
===== 行高的计算与继承 =====
|
||||
|
||||
以em、ex和百分比为单位的行高,其__基数是元素本身的字体尺寸__。例如有代码如下:
|
||||
|
||||
<p style=”font-size:20px;line-height:2em;”>字高20px,行高2em。</p>
|
||||
<p style=”font-size:30px;line-height:2em;”>字高30px,行高2em。</p>
|
||||
|
||||
个段落的行高都为2em,但是字体大小不同,因此显示如下图所示:
|
||||
{{./7.gif}}
|
||||
行高可以设定得比字体高度小,此时多行的文字将叠加到一起,例如有如下代码,其显示如下图所示:
|
||||
{{./8.gif}}
|
||||
p { font-size : 20px; line-height :10px; }
|
||||
<p>字高20px,行高10px。此时多行的文字将叠加到一起。</p>
|
||||
|
||||
行高是可继承的,但是__继承的是计算值__,例如有如下代码:
|
||||
|
||||
p { font-size :20px; line-height : 2em; }
|
||||
p span { font-size : 30px; }
|
||||
<p>字高20px。<span>字高30px。</span></p>
|
||||
|
||||
<p>元素的行高2em,字体尺寸为20px,因此计算值为40px,虽然<span>元素本身的字体尺寸为30px,不过其继承的行高仍为40px。但是在不同的浏览器内显示的效果却不尽相同,如下图所示:
|
||||
{{./9.gif}}
|
||||
由于继承的是计算值,因此当元素内的文字字体尺寸不一样的时候,如果设定固定的行高很可能造成字体的重叠,例如有如下代码,其显示如下图所示:
|
||||
{{./10.gif}}
|
||||
p { font-size : 20px; line-height : 1em; }
|
||||
p span { font-size : 30px; }
|
||||
|
||||
<p>字高20px,行高1em,当文本为多行时可能会发生文字重叠的现象。<span>字高30px。</span></p>
|
||||
|
||||
为了避免这种情况,可以为每个元素单独定义行高,但是这样很烦琐,因此可以定义一个没有单位的实数值作为缩放因子来统一控制行高__,缩放因子是直接继承的__,而不是继承计算值。例如修改上例中的行高为:
|
||||
|
||||
p { line-height : 1; }
|
||||
|
||||
则上例中的XHTML代码显示如下图所示:
|
||||
{{./11.gif}}
|
||||
当内容中含有图片的时候,如果图片的高度大于行高,则__含有图片行的行框将被撑开到图片的高度__,如下图所示:
|
||||
{{./12.gif}}
|
||||
注意:图片虽然撑开了行框,但是不会影响行高,因此也不会影响到基于行高来计算的其他属性。
|
||||
提示:当行内含有图片的时候,__图片和文字的垂直对齐方式默认是基线对齐__,关于垂直对齐将在本章[7.4 垂直对齐:vertical-align属性]一节中讨论
|
||||
|
||||
**PS:**如果line-height属性值有单位,那么继承的值则是换算后的一个具体的px级别的值;而如果属性值没有单位,则浏览器会直接继承这个 “因子(数值)”,而非计算后的具体值,此时它的line-height会根据本身的font-size值重新计算得到新的line-height 值。为了应付各种不可尽知的情况,请习惯不要给line-height单位。
|
||||
|
||||
|
||||
|
||||
===== 浏览器的差别与错误 =====
|
||||
|
||||
浏览器在显示的时候往往会有自己的表现形式,例如在Opera内,行高将按照CSS定义的将行距除以2增加到内容区域的上下两边,而IE和Firefox则不是完全平分,如下图所示:
|
||||
{{./13.gif}}
|
||||
不过,相差的1至2个像素在实际显示中一般不会有太大的影响,因此可以忽略不计。比较严重的错误是IE 6.0对于含有图片或者表单元等__可替换行内元素的行高失效的问题__,不过,在IE 7.0中已经修正了这个错误,但是其表现同其它浏览器也不相同。例如有如下代码,其显示如下图所示:
|
||||
{{./14.gif}}
|
||||
#lineHeight4 p { line-height : 60px; }
|
||||
#lineHeight4 fieldset{ border : 0; }
|
||||
<div id=”lineHeight4″>
|
||||
<p>内容含有图片在[IE 6]内浏览line-height将失效。<img src=”../../img/ddcat_anim.gif” alt=”图片” width=”88″ height=”31″ /></p>
|
||||
<form id=”testForm” action=”#”> <fieldset> <p><label for=”test1″>表单元素</label>< input type=”text” maxlength=”16″ value=”IE6内行高失效” /></p></fieldset> </form>
|
||||
</div>
|
||||
|
||||
由上图中读者可以发现,IE 7.0中,将半行距分别加在了图片的上下,而由于图片默认是基线对齐,因此文字的基线下移了,这显然不符合CSS中的规定。
|
||||
|
||||
对于IE 6.0中行高失效的问题,需要使用CSS Hack手段来针对IE 6.0设定替换元素的上下补白来修正。
|
||||
BIN
Zim/Web-Design/height/CSS中line-height属性详解/1.gif
Normal file
|
After Width: | Height: | Size: 9.9 KiB |
BIN
Zim/Web-Design/height/CSS中line-height属性详解/10.gif
Normal file
|
After Width: | Height: | Size: 5.4 KiB |
BIN
Zim/Web-Design/height/CSS中line-height属性详解/11.gif
Normal file
|
After Width: | Height: | Size: 5.9 KiB |
BIN
Zim/Web-Design/height/CSS中line-height属性详解/12.gif
Normal file
|
After Width: | Height: | Size: 4.4 KiB |
BIN
Zim/Web-Design/height/CSS中line-height属性详解/13.gif
Normal file
|
After Width: | Height: | Size: 4.4 KiB |
BIN
Zim/Web-Design/height/CSS中line-height属性详解/14.gif
Normal file
|
After Width: | Height: | Size: 15 KiB |
BIN
Zim/Web-Design/height/CSS中line-height属性详解/2.gif
Normal file
|
After Width: | Height: | Size: 6.1 KiB |
BIN
Zim/Web-Design/height/CSS中line-height属性详解/3.gif
Normal file
|
After Width: | Height: | Size: 4.6 KiB |
BIN
Zim/Web-Design/height/CSS中line-height属性详解/4.gif
Normal file
|
After Width: | Height: | Size: 8.2 KiB |
BIN
Zim/Web-Design/height/CSS中line-height属性详解/5.gif
Normal file
|
After Width: | Height: | Size: 6.8 KiB |
BIN
Zim/Web-Design/height/CSS中line-height属性详解/6.gif
Normal file
|
After Width: | Height: | Size: 8.1 KiB |
BIN
Zim/Web-Design/height/CSS中line-height属性详解/7.gif
Normal file
|
After Width: | Height: | Size: 6.7 KiB |
BIN
Zim/Web-Design/height/CSS中line-height属性详解/8.gif
Normal file
|
After Width: | Height: | Size: 6.7 KiB |
BIN
Zim/Web-Design/height/CSS中line-height属性详解/9.gif
Normal file
|
After Width: | Height: | Size: 7.6 KiB |
55
Zim/Web-Design/height/css_百分比_定义高度_小结.txt
Normal file
@@ -0,0 +1,55 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-15T22:01:30+08:00
|
||||
|
||||
====== css 百分比 定义高度 小结 ======
|
||||
Created Sunday 15 May 2011
|
||||
|
||||
http://blog.csdn.net/nailwl/archive/2010/07/16/5740057.aspx
|
||||
css 百分比 定义高度 小结
|
||||
|
||||
在符合标准的 XHTML 模式下,将 DIV 的高度简单的设置为 100% 往往并不能达到想要的效果,
|
||||
|
||||
原因是“百分比”是个相对于父节点的值,
|
||||
|
||||
如果你没有设置他们的父节点的高度,那么设置 DIV 的高度为100%就没有了意义。
|
||||
|
||||
另外一个问题是你或许期望的并不是100%,而是在页面高度不够一屏时按照100%显示,
|
||||
|
||||
当你的页面超过视窗的大小时,DIV 要能够撑开,这样的话min-height才是你真正想要的。
|
||||
|
||||
下面的代码可以让页面不足一屏时按照100%显示,当超过一屏时,又能够撑开:
|
||||
|
||||
CSS:
|
||||
|
||||
html, body {
|
||||
|
||||
height: 100%;
|
||||
|
||||
}
|
||||
|
||||
#container {
|
||||
|
||||
/* this is the div you want to fill the window */
|
||||
|
||||
min-height: 100%;
|
||||
|
||||
}
|
||||
|
||||
由于 Internet Explorer (IE) 6 及其以下的版本并不支持 min-height 属性,
|
||||
|
||||
因此,我们需要添加针对 IE 的代码。
|
||||
|
||||
CSS:
|
||||
|
||||
* html #container {
|
||||
|
||||
height:100%
|
||||
|
||||
}
|
||||
|
||||
在 IE 下,当 DIV 的内容超过 DIV 本身的高度时,
|
||||
|
||||
DIV 会自动撑开,因此这样的代码可以很好的解决上面的问题。
|
||||
|
||||
|
||||
44
Zim/Web-Design/height/height属性参考.txt
Normal file
@@ -0,0 +1,44 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-15T22:03:16+08:00
|
||||
|
||||
====== height属性参考 ======
|
||||
Created Sunday 15 May 2011
|
||||
http://www.w3school.com.cn/css/pr_dim_height.asp
|
||||
CSS height 属性
|
||||
|
||||
CSS 参考手册
|
||||
定义和用法
|
||||
|
||||
height 属性设置元素的高度。
|
||||
说明
|
||||
|
||||
这个属性定义元素内容区的高度,在内容区外面可以增加内边距、边框和外边距。
|
||||
|
||||
行内非替换元素会忽略这个属性。
|
||||
默认值: auto
|
||||
继承性: no
|
||||
版本: CSS1
|
||||
JavaScript 语法: object.style.height="50px"
|
||||
实例
|
||||
|
||||
设置段落的高度和宽度:
|
||||
|
||||
p
|
||||
{
|
||||
height:100px;
|
||||
width:100px;
|
||||
}
|
||||
|
||||
TIY
|
||||
浏览器支持
|
||||
|
||||
所有主流浏览器都支持 height 属性。
|
||||
|
||||
注释:任何版本的 Internet Explorer (包括 IE8)都不支持属性值 "inherit"。
|
||||
可能的值
|
||||
值 描述
|
||||
auto 默认。浏览器会计算出实际的高度。
|
||||
length 使用 px、cm 等单位定义高度。
|
||||
% 基于包含它的块级对象的百分比高度。
|
||||
inherit 规定应该从父元素继承 height 属性的值。
|
||||
7
Zim/Web-Design/height/overflow.txt
Normal file
@@ -0,0 +1,7 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-15T20:14:16+08:00
|
||||
|
||||
====== overflow ======
|
||||
Created Sunday 15 May 2011
|
||||
|
||||
134
Zim/Web-Design/一步步构建大型网站架构.txt
Normal file
@@ -0,0 +1,134 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-10-28T22:18:29+08:00
|
||||
|
||||
====== 一步步构建大型网站架构 ======
|
||||
Created Friday 28 October 2011
|
||||
|
||||
http://kb.cnblogs.com/page/99549/
|
||||
|
||||
之前我简单向大家介绍了各个知名大型网站的架构,MySpace的五个里程碑、Flickr的架构、YouTube的架构、PlentyOfFish的架构、WikiPedia的架构。这几个都很典型,我们可以从中获取很多有关网站架构方面的知识,看了之后你会发现你原来的想法很可能是狭隘的。
|
||||
|
||||
今天我们来谈谈一个网站一般是如何一步步来构建起系统架构的,虽然我们希望网站一开始就能有一个很好的架构,但马克思告诉我们__事物是在发展中不断前进的__,网站架构也是随着业务的扩大、用户的需求不断完善的,下面是一个网站架构逐步发展的基本过程,读完后,请思考,你现在在哪个阶段。
|
||||
|
||||
**架构演变第一步:物理分离WebServer和数据库**
|
||||
|
||||
最开始,由于某些想法,于是在互联网上搭建了一个网站,这个时候甚至有可能主机都是租借的,但由于这篇文章我们只关注架构的演变历程,因此就假设这个时候已经是托管了一台主机,并且有一定的带宽了。这个时候由于网站具备了一定的特色,吸引了部分人访问,逐渐你发现系统的压力越来越高,响应速度越来越慢,而这个时候比较明显的是__数据库和应用互相影响__,应用出问题了,数据库也很容易出现问题,而数据库出问题的时候,应用也容易出问题。于是进入了第一步演变阶段:将应用和数据库从物理上分离,变成了两台机器,这个时候技术上没有什么新的要求,但你发现确实起到效果了,系统又恢复到以前的响应速度了,并且支撑住了更高的流量,并且不会因为数据库和应用形成互相的影响。
|
||||
|
||||
看看这一步完成后系统的图示:
|
||||
{{~/sync/notes/zim/Web-Design/一步步构建大型网站架构/1.png}}
|
||||
|
||||
**架构演变第二步:增加页面缓存**
|
||||
|
||||
好景不长,随着访问的人越来越多,你发现响应速度又开始变慢了,查找原因,发现是__访问数据库的操作太多__,导致数据连接竞争激烈,所以响应变慢。但数据库连接又不能开太多,否则数据库机器压力会很高,因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力。这个时候首先也许会选择采用squid等类似的机制来将系统中__相对静态__的页面(例如一两天才会有更新的页面)进行缓存(当然,也可以采用将页面静态化的方案),这样程序上可以不做修改,就能够很好的减少对WebServer的压力以及减少数据库连接资源的竞争,OK,于是开始采用squid来做相对静态的页面的缓存。
|
||||
|
||||
看看这一步完成后系统的图示:
|
||||
{{~/sync/notes/zim/Web-Design/一步步构建大型网站架构/2.png}}
|
||||
这一步涉及到了这些知识体系:
|
||||
|
||||
前端页面缓存技术,例如squid,如想用好的话还得深入掌握下squid的实现方式以及__缓存的失效算法__等。
|
||||
|
||||
**架构演变第三步:增加页面片段缓存**
|
||||
|
||||
增加了squid做缓存后,整体系统的速度确实是提升了,WebServer的压力也开始下降了,但随着访问量的增加,发现系统又开始变的有些慢了。在尝到了squid之类的动态缓存带来的好处后,开始想能不能让现在那些**动态页面里相对静态的部分**也缓存起来呢,因此考虑采用类似ESI之类的__页面片段缓存策略__,OK,于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。
|
||||
|
||||
看看这一步完成后系统的图示:
|
||||
{{~/sync/notes/zim/Web-Design/一步步构建大型网站架构/3.png}}
|
||||
这一步涉及到了这些知识体系:
|
||||
|
||||
页面片段缓存技术,例如ESI等,想用好的话同样需要掌握ESI的实现方式等;
|
||||
|
||||
**架构演变第四步:数据缓存**
|
||||
|
||||
在采用ESI之类的技术再次提高了系统的缓存效果后,系统的压力确实进一步降低了,但同样,随着访问量的增加,系统还是开始变慢。经过查找,可能会发现系统中存在一些__重复获取数据信息__的地方,像获取用户信息等,这个时候开始考虑是不是可以将这些数据信息也缓存起来呢,于是将这些数据缓存到本地内存,改变完毕后,完全符合预期,系统的响应速度又恢复了,数据库的压力也再度降低了不少。
|
||||
|
||||
看看这一步完成后系统的图示:
|
||||
{{~/sync/notes/zim/Web-Design/一步步构建大型网站架构/4.png}}
|
||||
这一步涉及到了这些知识体系:
|
||||
|
||||
缓存技术,包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。
|
||||
|
||||
**架构演变第五步: 增加WebServer**
|
||||
|
||||
好景不长,发现随着系统访问量的再度增加,webserver机器的压力在高峰期会上升到比较高,这个时候开始考虑增加一台webserver,这也是为了同时解决__可用性__的问题,避免单台的webserver down机的话就没法使用了,在做了这些考虑后,决定增加一台webserver,增加一台webserver时,会碰到一些问题,典型的有:
|
||||
1、如何让访问分配到这两台机器上,这个时候通常会考虑的方案是Apache自带的__负载均衡方案__,或LVS这类的软件负载均衡方案;
|
||||
2、如何保持状态信息的同步,例如用户session等,这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等;
|
||||
3、如何保持数据缓存信息的同步,例如之前缓存的用户数据等,这个时候通常会考虑的机制有缓存同步或分布式缓存;
|
||||
4、如何让上传文件这些类似的功能继续正常,这个时候通常会考虑的机制是使用共享文件系统或存储等;
|
||||
在解决了这些问题后,终于是把webserver增加为了两台,系统终于是又恢复到了以往的速度。
|
||||
|
||||
看看这一步完成后系统的图示:
|
||||
{{~/sync/notes/zim/Web-Design/一步步构建大型网站架构/5.png}}
|
||||
这一步涉及到了这些知识体系:
|
||||
|
||||
负载均衡技术(包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等)、主备技术(包括但不限于ARP欺骗、linuxheart-beat等)、状态信息或缓存同步技术(包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等)、共享文件技术(包括但不限于NFS等)、存储技术(包括但不限于存储设备等)。
|
||||
|
||||
**架构演变第六步:分库**
|
||||
|
||||
享受了一段时间的系统访问量高速增长的幸福后,发现系统又开始变慢了,这次又是什么状况呢,经过查找,发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈,导致了系统变慢,这下怎么办呢?此时可选的方案有**数据库集群和分库策略**,集群方面像有些数据库支持的并不是很好,因此分库会成为比较普遍的策略,分库也就意味着要对原有程序进行修改,一通修改实现分库后,不错,目标达到了,系统恢复甚至速度比以前还快了。
|
||||
|
||||
看看这一步完成后系统的图示:
|
||||
{{~/sync/notes/zim/Web-Design/一步步构建大型网站架构/6.png}}
|
||||
这一步涉及到了这些知识体系:
|
||||
|
||||
这一步更多的是需要__从业务上做合理的划分__,以实现分库,具体技术细节上没有其他的要求;
|
||||
|
||||
但同时随着数据量的增大和分库的进行,在数据库的设计、调优以及维护上需要做的更好,因此对这些方面的技术还是提出了很高的要求的。
|
||||
|
||||
**架构演变第七步:分表、DAL和分布式缓存**
|
||||
|
||||
随着系统的不断运行,数据量开始大幅度增长,这个时候发现分库后查询仍然会有些慢,于是按照分库的思想开始做分表的工作。当然,这不可避免的会需要对程序进行一些修改,也许在这个时候就会发现应用自己要关心分库分表的规则等,还是有些复杂的。于是萌生能否增加一个__通用的框架__来实现分库分表的数据访问,这个在ebay的架构中对应的就是DAL,这个演变的过程相对而言需要花费较长的时间。当然,也有可能这个通用的框架会等到分表做完后才开始做。同时,在这个阶段可能会发现之前的缓存同步方案出现问题,因为数据量太大,导致现在不太可能将缓存存在本地,然后同步的方式,需要采用**分布式缓存**方案了。于是,又是一通考察和折磨,终于是将大量的数据缓存转移到分布式缓存上了。
|
||||
|
||||
看看这一步完成后系统的图示:
|
||||
{{~/sync/notes/zim/Web-Design/一步步构建大型网站架构/7.png}}
|
||||
这一步涉及到了这些知识体系:
|
||||
|
||||
分表更多的同样是业务上的划分,技术上涉及到的会有动态hash算法、consistenthash算法等;
|
||||
|
||||
DAL涉及到比较多的复杂技术,例如数据库连接的管理(超时、异常)、数据库操作的控制(超时、异常)、分库分表规则的封装等;
|
||||
|
||||
**架构演变第八步:增加更多的WebServer**
|
||||
|
||||
在做完分库分表这些工作后,数据库上的压力已经降到比较低了,又开始过着每天看着访问量暴增的幸福生活了。突然有一天,发现系统的访问又开始有变慢的趋势 了,这个时候首先查看数据库,**压力一切正常**,之后查看webserver,发现apache阻塞了很多的请求,而应用服务器对每个请求也是比较快的,看来是请求数太高导致需要**排队等待**,响应速度变慢。这还好办,一般来说,这个时候也会有些钱了,于是添加一些webserver服务器,在这个添加webserver服务器的过程,有可能会出现几种挑战:
|
||||
|
||||
1、Apache的软负载或LVS软负载等无法承担巨大的web访问量(请求连接数、网络流量等)的调度了,这个时候如果经费允许的话,会采取的方案是购买__硬件负载平衡设备__,例如F5、Netsclar、Athelon之类的,如经费不允许的话,会采取的方案是将应用从逻辑上做一定的分类,然后分散到不同的软负载集群中;
|
||||
|
||||
2、原有的一些状态信息同步__、文件共享__等方案可能会出现瓶颈,需要进行改进,也许这个时候会根据情况编写符合网站业务需求的分布式文件系统等;
|
||||
|
||||
在做完这些工作后,开始进入一个看似完美的无限伸缩的时代,当网站流量增加时,应对的解决方案就是不断的添加webserver。
|
||||
|
||||
看看这一步完成后系统的图示:
|
||||
{{~/sync/notes/zim/Web-Design/一步步构建大型网站架构/8.png}}
|
||||
这一步涉及到了这些知识体系:
|
||||
|
||||
到了这一步,随着机器数的不断增长、数据量的不断增长和对系统可用性的要求越来越高,这个时候要求对所采用的技术都要有更为深入的理解,并需要根据网站的需求来做更加定制性质的产品。
|
||||
|
||||
**架构演变第九步:数据读写分离和廉价存储方案**
|
||||
|
||||
突然有一天,发现这个完美的时代也要结束了,数据库的噩梦又一次出现在眼前了。由于添加的webserver太多了,导致数据库连接的资源还是不够用,而这个时候又已经分库分表了,开始分析数据库的压力状况,可能会发现数据库的读写比很高,这个时候通常会想到**数据读写分离**的方案。当然,这个方案要实现并不容易,另外,可能会发现一些数据存储在数据库上有些浪费,或者说过于占用数据库资源,因此在这个阶段可能会形成的架构演变是实现数据读写分离,同时编写一些更为廉价的存储方案,例如BigTable这种。
|
||||
|
||||
看看这一步完成后系统的图示:
|
||||
{{~/sync/notes/zim/Web-Design/一步步构建大型网站架构/9.png}}
|
||||
这一步涉及到了这些知识体系:
|
||||
|
||||
数据读写分离要求对数据库的复制、standby等策略有深入的掌握和理解,同时会要求具备自行实现的技术;
|
||||
|
||||
廉价存储方案要求对OS的文件存储有深入的掌握和理解,同时要求对采用的语言在文件这块的实现有深入的掌握。
|
||||
|
||||
**架构演变第十步:进入大型分布式应用时代和廉价服务器群梦想时代**
|
||||
|
||||
经过上面这个漫长而痛苦的过程,终于是再度迎来了完美的时代,不断的增加webserver就可以支撑越来越高的访问量了。对于大型网站而言,人气的重要毋庸置疑,随着人气的越来越高,各种各样的功能需求也开始爆发性的增长。这个时候突然发现,原来部署在webserver上的那个web应用已经非常庞大 了,当多个团队都开始对其进行改动时,可真是相当的不方便,复用性也相当糟糕,基本是每个团队都做了或多或少重复的事情,而且部署和维护也是相当的麻烦。因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间,出问题的时候也不是很好查,另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导 致了全站都不可用,还有其他的像调优不好操作(因为机器上部署的应用什么都要做,根本就无法进行针对性的调优)等因素,根据这样的分析,开始痛下决心,将系统__根据职责进行拆分__,于是一个大型的分布式应用就诞生了,通常,这个步骤需要耗费相当长的时间,因为会碰到很多的挑战:
|
||||
|
||||
1、拆成分布式后需要提供一个高性能、稳定的**通信框架**,并且需要支持多种不同的通信和远程调用方式;
|
||||
2、将一个庞大的应用拆分需要耗费很长的时间,需要进行业务的整理和系统依赖关系的控制等;
|
||||
3、如何运维(依赖管理、运行状况管理、错误追踪、调优、监控和报警等)好这个庞大的分布式应用。
|
||||
经过这一步,差不多系统的架构进入相对稳定的阶段,同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量,结合这套架构以及这么多次演变过程吸取的经验来采用其他各种各样的方法来支撑着越来越高的访问量。
|
||||
|
||||
看看这一步完成后系统的图示:
|
||||
{{~/sync/notes/zim/Web-Design/一步步构建大型网站架构/10.png}}
|
||||
这一步涉及到了这些知识体系:
|
||||
|
||||
这一步涉及的知识体系非常的多,要求对通信、远程调用、消息机制等有深入的理解和掌握,要求的都是从理论、硬件级、操作系统级以及所采用的语言的实现都有清楚的理解。
|
||||
|
||||
最后,附上一张大型网站的架构图:
|
||||
{{~/sync/notes/zim/Web-Design/一步步构建大型网站架构/11.gif}}
|
||||
BIN
Zim/Web-Design/一步步构建大型网站架构/1.png
Normal file
|
After Width: | Height: | Size: 2.0 KiB |
BIN
Zim/Web-Design/一步步构建大型网站架构/10.png
Normal file
|
After Width: | Height: | Size: 26 KiB |
BIN
Zim/Web-Design/一步步构建大型网站架构/11.gif
Normal file
|
After Width: | Height: | Size: 69 KiB |
BIN
Zim/Web-Design/一步步构建大型网站架构/2.png
Normal file
|
After Width: | Height: | Size: 3.5 KiB |
BIN
Zim/Web-Design/一步步构建大型网站架构/3.png
Normal file
|
After Width: | Height: | Size: 6.0 KiB |
BIN
Zim/Web-Design/一步步构建大型网站架构/4.png
Normal file
|
After Width: | Height: | Size: 8.3 KiB |
BIN
Zim/Web-Design/一步步构建大型网站架构/5.png
Normal file
|
After Width: | Height: | Size: 8.9 KiB |
BIN
Zim/Web-Design/一步步构建大型网站架构/6.png
Normal file
|
After Width: | Height: | Size: 9.3 KiB |
BIN
Zim/Web-Design/一步步构建大型网站架构/7.png
Normal file
|
After Width: | Height: | Size: 14 KiB |
BIN
Zim/Web-Design/一步步构建大型网站架构/8.png
Normal file
|
After Width: | Height: | Size: 21 KiB |
BIN
Zim/Web-Design/一步步构建大型网站架构/9.png
Normal file
|
After Width: | Height: | Size: 24 KiB |
133
Zim/Web-Design/下拉菜单设计.txt
Normal file
@@ -0,0 +1,133 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-15T21:04:39+08:00
|
||||
|
||||
====== 下拉菜单设计 ======
|
||||
Created Sunday 15 May 2011
|
||||
http://www.cnblogs.com/dvbhack/archive/2009/04/17/best-practices-of-css-dropdown-menu.html
|
||||
结合JavaScript的下拉菜单,纯CSS的下拉菜单我也写过很多了。不过在微软 Microsoft Expression Web 的相关站点上看到这个纯CSS下拉菜单的时候,我还是觉得很赞赏。这应该是最精简、最干净的纯CSS下拉菜单了。
|
||||
|
||||
先看一下效果(这是我重新实现的):
|
||||
{{./1.png}}
|
||||
|
||||
下面是实现方法:
|
||||
|
||||
首先是菜单的XHTML代码:
|
||||
|
||||
<ul>
|
||||
<li><a href="#">菜单一</a></li>
|
||||
<li><a href="#">菜单二</a>
|
||||
<ul>
|
||||
<li><a href="#">子菜单一</a></li>
|
||||
<li><a href="#">子菜单二</a></li>
|
||||
<li><a href="#">子菜单三</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="#">菜单三</a></li>
|
||||
<li><a href="#">菜单四</a>
|
||||
<ul>
|
||||
<li><a href="#">子菜单一</a></li>
|
||||
<li><a href="#">子菜单二</a></li>
|
||||
<li><a href="#">子菜单三</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="#">菜单五</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
不设置任何CSS类,实在是干净到极点了(当然,考虑到实际应用的复杂性,我估计你不可能真的什么都不加。要么把这段代码放到一个特定的容器里,要么给第一层的ul加一个id或者class。
|
||||
|
||||
假设这是在一个新的HTML文档里,那么我们现在没有任何的CSS定义,这时候的网页显示效果是这样的:
|
||||
|
||||
{{./2.png}}
|
||||
|
||||
在我们的下拉菜单中,不需要内补丁、外边距这些东西,即使需要,我们也要自己重新设置,所以我们首先添加__第一条规则__:
|
||||
|
||||
ul {
|
||||
margin: 0px;
|
||||
padding: 0px;
|
||||
}
|
||||
|
||||
__为了跨浏览器兼容,必须同时把外边距和内补丁都设置为0__,因为有的浏览器默认使用外边距,有的则默认使用内补丁。这样设置以后,页面上可以看到两层列表项前面的缩进都没了,实心和空心的列表符号也不见了。然后设置__第二条规则__:
|
||||
|
||||
ul li {
|
||||
float: left;
|
||||
display: inline;
|
||||
font: 0.9em Arial, Helvetica, sans-serif;
|
||||
height: 30px;
|
||||
width: 100px;
|
||||
list-style: none;
|
||||
}
|
||||
|
||||
这是让原本各占一行的li元素变成嵌入式(inline)显示,另一种说法是把list-item元素变成行内元素。总而言之就是让li不要各占一行,并列起来,这样才能成为菜单。设置后,效果如下:
|
||||
|
||||
{{./3.png}}
|
||||
这样就得到了下拉菜单的雏形,当然了,外观很丑陋,下拉功能也还没实现。这里要说明的是,__最好给菜单项设置高度和宽度__,否则有可能出现不可预料的结果(取决于__页面或容器的宽度__)。为了让菜单项看起来像菜单,我们继续添加规则:
|
||||
|
||||
ul li a {
|
||||
color: #FFF;
|
||||
text-decoration: none;
|
||||
line-height: 29px; /*剩下的1px用于border-bottom*/
|
||||
width: 91px; /*剩下的19px:padding-right-width=8px,border-right=1px*/
|
||||
margin: 0px;
|
||||
padding: 0px 0px 0px 8px;
|
||||
display: block;
|
||||
border-right: solid 1px #ccc;
|
||||
border-bottom:solid 1px #ccc;
|
||||
background: #808080;
|
||||
}
|
||||
|
||||
__PS:__其实上面的ul li {中的width和height不是必需的,因为li的大小取决于其中包含的内容a的设置。
|
||||
|
||||
这一条规则比较长,从作用上说呢,就是加上背景和菜单间的隔离线,把默认有下划线蓝色的文字变成白色无下划线。增加了规则后的效果:
|
||||
{{./4.png}}
|
||||
|
||||
从外观上,这就已经是我们最终的下拉菜单样式了。不过,我们还要在细节上修饰一下,比如让子菜单和一级菜单的样式有所区别(当然了,由于字体设置的0.9em,所以在文字大小上已经有区别了(__这是因为子菜单的字体大小是相对于父li字体大小的0.9倍__),但是还不够,而且对于中文来说,很多时候我们未必能通过文字大小来区别,因为__适合中文的常规文字大小就12px和14px而已__),所以我们修改一下子菜单的背景色,并且让子菜单比一级菜单的高度要小一些。规则:
|
||||
|
||||
ul li ul li { height:25px; }
|
||||
ul li ul li a {
|
||||
background: #666;
|
||||
line-height:24px;
|
||||
}
|
||||
|
||||
这里包含两条规则,第一条是将子菜单的列表项目高度由之前统一设置的30px减小为25,第二是将子菜单项的背景改为#666,并且文字行高对应地减小到24设置完成后(列表项高度-1,减去的1正好是上边框的1像素),效果如下:
|
||||
{{./5.png}}
|
||||
|
||||
|
||||
通常我们鼠标滑过某个菜单项的时候,要让它跟其它项目有所区别(表示当前菜单处于激活状态,术语叫“高亮” ,所以我们对一级菜单的鼠标滑过样式做一下定义:
|
||||
|
||||
ul li a:hover { background: #666; }
|
||||
|
||||
注意,这里为鼠标滑过时设置的背景色和子菜单的背景色一样,原因?看效果就知道了:
|
||||
{{./6.png}}
|
||||
|
||||
这里的第二个菜单项就是鼠标滑过时候的样式,这样就跟弹出的(现在还不会弹出)子菜单背景色一致了。现在整个菜单的样式都设置完了,但是,**这只是静态的菜单啊**,我们要的是会动的。所以工作还没完成。接下来是什么呢?当然是**默认情况下把二级菜单隐藏起来**。我们要写JS来隐藏他们吗?No!样式如下:
|
||||
|
||||
__ul li ul { visibility: hidden; }__
|
||||
|
||||
**PS:**可以用display:none,然后用display:block来显示子菜单。
|
||||
|
||||
这样,子菜单并不是像“display:none”一样不显示,它还是在那个位置,文档结构什么的都没有发生任何改变,只是看不到它而已,而且下拉菜单中的链接当然也没不可以点击。
|
||||
{{./7.png}}
|
||||
|
||||
|
||||
最后一条规则,让鼠标滑过有下拉项的时候,显示下拉菜单。当然我们实际设置的是:如果某一个下拉菜单的父级元素(一级菜单项)被鼠标滑过,那么就让该下拉菜单可以被看见:
|
||||
|
||||
ul li:hover ul { visibility: visible; }
|
||||
|
||||
|
||||
这样就完成了整个设置下拉菜单制作,当然你还可以进一步修饰这个菜单,比如我们应该让子菜单中的项目在鼠标滑过的时候也变色:
|
||||
|
||||
ul li ul li a:hover { background: #333; }
|
||||
|
||||
最终效果
|
||||
|
||||
{{./8.png}}
|
||||
|
||||
|
||||
要强调的一点:这个下拉菜单在各主流浏览器(IE6以下的版本除外)中的外观及行为都是完全一致的。兼容性非常好。为什么不支持IE6呢?因为IE8都出来了,我们是不是应该彻底抛弃那个给网页设计师带来无限痛苦的万恶的IE6了?
|
||||
|
||||
如果IE6的兼容性对你的站点来说非常重要,那么你可以参考这盘文章:http://wukangrui.com/2009/06/22/whatever-hover-pseudo-class-without-javascript.html。
|
||||
|
||||
本文参考:http://www.microsoft.com/china/expression/newsletter/2008-11/article05.aspx
|
||||
本文首发自 刀刀博客,博客园同步更新。如需转载,请注明作者及出处。
|
||||
BIN
Zim/Web-Design/下拉菜单设计/1.png
Normal file
|
After Width: | Height: | Size: 4.7 KiB |
BIN
Zim/Web-Design/下拉菜单设计/2.png
Normal file
|
After Width: | Height: | Size: 4.3 KiB |
BIN
Zim/Web-Design/下拉菜单设计/3.png
Normal file
|
After Width: | Height: | Size: 3.5 KiB |
BIN
Zim/Web-Design/下拉菜单设计/4.png
Normal file
|
After Width: | Height: | Size: 5.4 KiB |
BIN
Zim/Web-Design/下拉菜单设计/5.png
Normal file
|
After Width: | Height: | Size: 4.9 KiB |
BIN
Zim/Web-Design/下拉菜单设计/6.png
Normal file
|
After Width: | Height: | Size: 5.2 KiB |
BIN
Zim/Web-Design/下拉菜单设计/7.png
Normal file
|
After Width: | Height: | Size: 2.1 KiB |
BIN
Zim/Web-Design/下拉菜单设计/8.png
Normal file
|
After Width: | Height: | Size: 4.7 KiB |
260
Zim/Web-Design/下拉菜单设计/纯css导航下拉菜单.txt
Normal file
@@ -0,0 +1,260 @@
|
||||
Content-Type: text/x-zim-wiki
|
||||
Wiki-Format: zim 0.4
|
||||
Creation-Date: 2011-05-15T21:44:18+08:00
|
||||
|
||||
====== 纯css导航下拉菜单 ======
|
||||
Created Sunday 15 May 2011
|
||||
http://www.tonjay.com/website/csstab.html
|
||||
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
<title>dropdown˵--A CROSS BROWSER DROP DOWN CASCADING VALIDATING MENU</title>
|
||||
<style type="text/css">
|
||||
/* common styling */
|
||||
/* set up the overall width of the menu div, the font and the margins */
|
||||
.menu {
|
||||
font-family: arial, sans-serif;
|
||||
width:1000px;
|
||||
margin:0;
|
||||
margin:50px auto;
|
||||
}
|
||||
/* remove the bullets and set the margin and padding to zero for the unordered list */
|
||||
.menu ul {
|
||||
padding:0;
|
||||
margin:0;
|
||||
list-style-type: none;
|
||||
}
|
||||
/* float the list so that the items are in a line and their position relative so that the drop down list will appear in the right place underneath each list item */
|
||||
.menu ul li {
|
||||
float:left;
|
||||
position:relative;
|
||||
}
|
||||
/* style the links to be 104px wide by 30px high with a top and right border 1px solid white. Set the background color and the font size. */
|
||||
.menu ul li a, .menu ul li a:visited {
|
||||
display:block;
|
||||
text-align:center;
|
||||
text-decoration:none;
|
||||
width:80px;
|
||||
height:30px;
|
||||
color:#000;
|
||||
border:1px solid #fff;
|
||||
border-width:1px 1px 0 0;
|
||||
background:#c9c9a7;
|
||||
line-height:30px;
|
||||
font-size:11px;
|
||||
}
|
||||
/* make the dropdown ul invisible */
|
||||
.menu ul li ul {
|
||||
display: none;
|
||||
}
|
||||
/* specific to non IE browsers */
|
||||
/* set the background and foreground color of the main menu li on hover */
|
||||
.menu ul li a:hover {
|
||||
color:#fff;
|
||||
background:#b3ab79;
|
||||
}
|
||||
/* make the sub menu ul visible and position it beneath the main menu list item */
|
||||
.menu ul li:hover ul {
|
||||
display:block;
|
||||
position:absolute;
|
||||
top:31px;
|
||||
left:0;
|
||||
width:79px;
|
||||
}
|
||||
/* style the background and foreground color of the submenu links */
|
||||
.menu ul li:hover ul li a {
|
||||
display:block;
|
||||
background:#faeec7;
|
||||
color:#000;
|
||||
}
|
||||
/* style the background and forground colors of the links on hover */
|
||||
.menu ul li:hover ul li a:hover {
|
||||
background:#dfc184;
|
||||
color:#000;
|
||||
}
|
||||
</style>
|
||||
<!--[if lte IE 6]>
|
||||
<style type="text/css">
|
||||
/* styling specific to Internet Explorer IE5.5 and IE6. Yet to see if IE7 handles li:hover */
|
||||
/* Get rid of any default table style */
|
||||
table {
|
||||
border-collapse:collapse;
|
||||
margin:0;
|
||||
padding:0;
|
||||
}
|
||||
/* ignore the link used by 'other browsers' */
|
||||
.menu ul li a.hide, .menu ul li a:visited.hide {
|
||||
display:none;
|
||||
}
|
||||
/* set the background and foreground color of the main menu link on hover */
|
||||
.menu ul li a:hover {
|
||||
color:#fff;
|
||||
background:#b3ab79;
|
||||
}
|
||||
/* make the sub menu ul visible and position it beneath the main menu list item */
|
||||
.menu ul li a:hover ul {
|
||||
display:block;
|
||||
position:absolute;
|
||||
top:32px;
|
||||
left:0;
|
||||
width:105px;
|
||||
}
|
||||
/* style the background and foreground color of the submenu links */
|
||||
.menu ul li a:hover ul li a {
|
||||
background:#faeec7;
|
||||
color:#000;
|
||||
}
|
||||
/* style the background and forground colors of the links on hover */
|
||||
.menu ul li a:hover ul li a:hover {
|
||||
background:#dfc184;
|
||||
color:#000;
|
||||
}
|
||||
</style>
|
||||
<![endif]-->
|
||||
</head>
|
||||
<body>
|
||||
<div class="menu">
|
||||
<ul>
|
||||
<li><a class="hide" href="http://www.tonjay.com">DEMOS</a>
|
||||
<!--[if lte IE 6]>
|
||||
<a href="http://www.tonjay.com">DEMOS
|
||||
<table><tr><td>
|
||||
<![endif]-->
|
||||
<ul>
|
||||
<li><a href="http://www.tonjay.com" title="The zero dollar ads page">zero dollars</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Wrapping text around images">wrapping text</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Styling forms">styled form</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Removing active/focus borders">active focus</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Multi-position drop shadow">shadow boxing</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Image Map for detailed information">image map</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="fun with background images">fun backgrounds</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="fade-out scrolling">fade scrolling</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="em size images compared">em sized images</a></li>
|
||||
</ul>
|
||||
<!--[if lte IE 6]>
|
||||
</td></tr></table>
|
||||
</a>
|
||||
<![endif]-->
|
||||
</li>
|
||||
<li><a class="hide" href="http://www.tonjay.com">MENUS</a>
|
||||
<!--[if lte IE 6]>
|
||||
<a href="http://www.tonjay.com">MENUS
|
||||
<table><tr><td>
|
||||
<![endif]-->
|
||||
<ul>
|
||||
<li><a href="http://www.tonjay.com" title="a coded list of spies">spies menu</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="a horizontal vertical menu">vertical menu</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="an enlarging unordered list">enlarging list</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="an unordered list with link images">link images</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="non-rectangular links">non-rectangular</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="jigsaw links">jigsaw links</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="circular links">circular links</a></li>
|
||||
</ul>
|
||||
<!--[if lte IE 6]>
|
||||
</td></tr></table>
|
||||
</a>
|
||||
<![endif]-->
|
||||
</li>
|
||||
<li><a class="hide" href="http://www.tonjay.com">LAYOUTS</a>
|
||||
<!--[if lte IE 6]>
|
||||
<a href="http://www.tonjay.com">LAYOUTS
|
||||
<table><tr><td>
|
||||
<![endif]-->
|
||||
<ul>
|
||||
<li><a href="http://www.tonjay.com" title="Cross browser fixed layout">Fixed 1</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Cross browser fixed layout">Fixed 2</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Cross browser fixed layout">Fixed 3</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Cross browser fixed layout">Fixed 4</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="A simple minimum width layout">minimum width</a></li>
|
||||
</ul>
|
||||
<!--[if lte IE 6]>
|
||||
</td></tr></table>
|
||||
</a>
|
||||
<![endif]-->
|
||||
</li>
|
||||
<li><a class="hide" href="http://www.tonjay.com">BOXES</a>
|
||||
<!--[if lte IE 6]>
|
||||
<a href="http://www.tonjay.com">BOXES
|
||||
<table><tr><td>
|
||||
<![endif]-->
|
||||
<ul>
|
||||
<li><a href="http://www.tonjay.com" title="a coded list of spies">spies menu</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="a horizontal vertical menu">vertical menu</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="an enlarging unordered list">enlarging list</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="an unordered list with link images">link images</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="non-rectangular links">non-rectangular</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="jigsaw links">jigsaw links</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="circular links">circular links</a></li>
|
||||
</ul>
|
||||
<!--[if lte IE 6]>
|
||||
</td></tr></table>
|
||||
</a>
|
||||
<![endif]-->
|
||||
</li>
|
||||
<li><a class="hide" href="http://www.tonjay.com">MOZILLA</a>
|
||||
<!--[if lte IE 6]>
|
||||
<a href="http://www.tonjay.com">MOZILLA
|
||||
<table><tr><td>
|
||||
<![endif]-->
|
||||
<ul>
|
||||
<li><a href="http://www.tonjay.com" title="A drop down menu">drop down menu</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="A cascading menu">cascading menu</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Using content:">content:</a></li>
|
||||
<li><a href="http://www.tonjay.com" title=":hover applied to a div">mozzie box</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="I can build a rainbow">rainbow box</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Snooker cue">snooker cue</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Target Practise">target practise</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Two tone headings">two tone headings</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Shadow text">shadow text</a></li>
|
||||
</ul>
|
||||
<!--[if lte IE 6]>
|
||||
</td></tr></table>
|
||||
</a>
|
||||
<![endif]-->
|
||||
</li>
|
||||
<li><a class="hide" href="http://www.tonjay.com">EXPLORER</a>
|
||||
<!--[if lte IE 6]>
|
||||
<a href="../ie/index.html">EXPLORER
|
||||
<table><tr><td>
|
||||
<![endif]-->
|
||||
<ul>
|
||||
<li><a href="http://www.tonjay.com" title="Example one">example one</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Weft fonts">weft fonts</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="Vertical align">vertical align</a></li>
|
||||
</ul>
|
||||
<!--[if lte IE 6]>
|
||||
</td></tr></table>
|
||||
</a>
|
||||
<![endif]-->
|
||||
</li>
|
||||
<li><a class="hide" href="http://www.tonjay.com">OPACITY</a>
|
||||
<!--[if lte IE 6]>
|
||||
<a href="http://www.tonjay.com">OPACITY
|
||||
<table><tr><td>
|
||||
<![endif]-->
|
||||
<ul>
|
||||
<li><a href="http://www.tonjay.com" title="colour wheel">opaque colours</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="a menu using opacity">opaque menu</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="partial opacity">partial opacity</a></li>
|
||||
<li><a href="http://www.tonjay.com" title="partial opacity II">partial opacity II</a></li>
|
||||
</ul>
|
||||
<!--[if lte IE 6]>
|
||||
</td></tr></table>
|
||||
</a>
|
||||
<![endif]-->
|
||||
</li>
|
||||
</ul>
|
||||
<!-- clear the floats if required -->
|
||||
<div class="clear"> </div>
|
||||
<div style="width:800px; height:100px; background:#000;"></div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
效果如下:
|
||||
{{./1.png?width=600}}
|
||||
{{./2.png?width=600}}
|
||||
{{./3.png?width=600}}
|
||||
|
||||
|
||||
BIN
Zim/Web-Design/下拉菜单设计/纯css导航下拉菜单/1.png
Normal file
|
After Width: | Height: | Size: 57 KiB |
BIN
Zim/Web-Design/下拉菜单设计/纯css导航下拉菜单/2.png
Normal file
|
After Width: | Height: | Size: 70 KiB |