本站原创
摘要:由于W3C标准的存在,让DIV+CSS成为主流页面布局技术。可是由于标准与实际的浏览器之间存在一定的偏差,让我们可能对CSS的使用和标准的理解产生头痛,本文就是通过对文档流的讨论和研究,从浏览器角度,揭开CSS问题的神秘面纱。
关键词:文档流;CSS;浏览器;WEB;布局定位模式
:A文章编号:1007-9599 (2012) 13-0000-02
由于一直都找不到关于文档流(Document Flow)的正式定义,故在此用本文作者自己的语言来通俗阐述一下个人观点:文档流就是一个文档(Document)在计算机中的读取流和输出流的综合。而所谓的读取流(Input Flow),就是以文本形式存储的文档作为数据源时,一点点读入程序进程或计算机内存中的整个时域性的数据流。相对地,输出流就是由程序或相应进程将读入的数据经一定的算法或操作以一定的格式输出或显示的整个输出过程。
那么在WEB中,即对于网页文档(Web Page),其文档流则可以十分容易地理解为,浏览器(Browser)对网页数据的读取和其对应的格式输出。所谓的网页数据则无非就是HTML+CSS+JS脚本语言文本,而输出的格式也就是网页的图文排版。如此一来,我们在WEB中讨论文档流,其实质上就是在讨论浏览器对于网页脚本的解析流。故在此作如下几方面展开:
本文作者认为,文档流(Document Flow)就可以作为一个具有一般性的,能解释CSS和浏览器对WEB的解析情况的理论。同时本文中所讨论的角度主要从浏览器实际行为出发,故在下面阐述的观点中,与W3C所定标准之间存在一定的偏差。
在计算机中,一个程序进程读取文件一定是通过文件指针(File Pointer),从起始位一直移动到文件结束(End Of File)。而对应该进程的输出过程也一定是与输入过程相同的顺序,故可形象地将文件指针的移动过程本身看作文档流。
那么浏览器进程输出显示网页排版内容,就一定是按照其在文档流中的顺序而输出的。形象地说,整个文档开始的内容一定是最先输出,而且其后所跟的内容在文档中也一定是记载于其对应部分之后。(Content at the top of the document,for example,is displayed first and is followed by the content after it.)
在WEB里,所有内容都是通过HTML作为载体。故其文档流,就是由一个个的HTML元素(HTML Elements)组成。在代码上,HTML元素又是通过HTML标签来作为实体,故在W3C标准中,将HTML标签分成块级元素(Block-level Elements)与行级元素(Inline-level Elements)两类,来定义WEB中的文档流工作实质:
1.在同一文档流平面中,块级元素在显示时独占一行,同级的块级元素也只能与其上下相邻。HTML4中与之对应的标签是
2.行级元素是作为其所在文档流中的一个内
由上可见,WEB中文档流如何工作的讨论重点,就是浏览器对块级元素与行级元素的解析与输出规则。
而这两类元素之间,行级元素就是含在块级元素中的内容,而块级元素是作为一个个的盒子(Box Model)在整个页面中起占位排版的作用。
这样就可以很好地在整个空间体系中来形象描述CSS的布局定位模式。在此将整个浏览器屏幕所在平面定义为xoy平面,那么在这个空间中的z轴则是垂直于屏幕,这其实正是CSS中的z-index属性——垂直于屏幕向外为该z轴的正方向。
在一个文件中,可以由多个流组成,而每个流从xoy平面上来看均占满整个平面。那么流与流之间就是在z轴上的层叠关系。这个关系也有点类似于作图软件中的图层关系,即每一个流相当于一个图层。
流也分成三类,那么不同类型的流则也表现不同:
1.常规流(Normal Flow)是一个文档流内部的原始体系,可以想像成一张平铺的白纸。
2.绝对定位流(Absolute Positioning)是脱离原始的流而形成一层新的流,并按给定的相应属性或规则(如z-index),与其他流之间形成层叠覆盖关系。
3.浮动流(Floats)在本文中认为其本身未脱离所在的流,却相对于所在的母体流形成突起,从而使得在表现上类似于绝对定位流,与母体流形成层叠覆盖关系,可其实质上却并未脱离母体文档流。也就是相当于半个绝对定位。
对于元素与流之间的关系,又可将不同定位属性的HTML元素分为如下三类:1.置入文档流(In Flow):所有非绝对定位的元素均为置入文档流。而元素在文档流中可以形成突起浮动(Float),从而使得在输出表现上与脱离文档流相同。
2.基本文档流
3.脱离文档流(Out Of Flow):所有绝对定位的元素均脱离文档流。而所谓的流又都是通过HTML元素作为载体来表现的,那么每一个元素脱离文档流,实质上就是,该元素脱离了其父标签元素所在的文档流而独立形成一个新的流。
以上观点虽与W3C标准略有出路,却可以更好地来解释和理解浏览器行为。
HTML文档本身是由一个个HTML元素组成,在XHTML中,这些元素也被称为DOM元素。而根据以上观点,每一个元素本身又一定属于一种文档流,所以自然可以得出:
元素作为整个HTML文档的根结点元素(Node),本身就是基本文档流。
而元素中的一级子结点元素,若赋予绝对定位,那么该属性则是脱离基本文档流而形成一层新的流。
综上所述,一个元素A的流,实质上就是一个由A元素本身和其内所有的置入文档流子元素所组成的集合。
也有:常规流中的所有元素均为置入文档流。
至此,CSS布局体系则可通过文档流来得到完全解释:
因为本文作者认为浮动流是介于常规流和绝对定位流之间,从而能同时看到这两种流各自的特点。而问题就是不同的浏览器引擎对于这个之间的程度把握不同。
IE6、IE7中将浮动流很大程度上作为常规流解析,导致在IE6中并未做到浮动流相对于其母体流的突起,所以会出现IE6在边界问题上(margin值问题)与其他浏览器之间存在很大偏差。
典型的IE捉迷藏问题(Peekaboo Bug)也可以通过文档流来进行很好的解释,其原因就是在于行级元素甚至直接就是文本内容与块级元素同级存放。这对浏览器的解析本身就是形成了困难,因为像IE6、IE7这样不突起形成z-index为0.5的浮动流,与IE8+和Firefox与Chrome这样接近W3C标准,将浮动流突起的浏览器引擎之间,解析自然就有问题了。所以也正如过去对捉迷藏问题的解决方案,注意DIV的嵌套习惯,避开不同级别元素和文本同级情况。
至此,可以看到其实浏览器兼容性问题的起因就是因为对文档流的解析输出不同,就是与W3C标准的输出存在偏差。若以文档流来讨论这些问题,会发现连怪异模式(Quirks Mode)也其实并不怪异。
那么既然浏览器引擎的兼容性问题可以得到解释,CSS HACK管理的难度自然可以彻底下降。这样,不论是对于学习CSS还是设计WEB都可以在很大程度上减少对浏览器兼容性的思考,而将更大的精力集中于如何设计美观并具艺术性的网页上了。
关键词:文档流;CSS;浏览器;WEB;布局定位模式
:A文章编号:1007-9599 (2012) 13-0000-02
由于一直都找不到关于文档流(Document Flow)的正式定义,故在此用本文作者自己的语言来通俗阐述一下个人观点:文档流就是一个文档(Document)在计算机中的读取流和输出流的综合。而所谓的读取流(Input Flow),就是以文本形式存储的文档作为数据源时,一点点读入程序进程或计算机内存中的整个时域性的数据流。相对地,输出流就是由程序或相应进程将读入的数据经一定的算法或操作以一定的格式输出或显示的整个输出过程。
那么在WEB中,即对于网页文档(Web Page),其文档流则可以十分容易地理解为,浏览器(Browser)对网页数据的读取和其对应的格式输出。所谓的网页数据则无非就是HTML+CSS+JS脚本语言文本,而输出的格式也就是网页的图文排版。如此一来,我们在WEB中讨论文档流,其实质上就是在讨论浏览器对于网页脚本的解析流。故在此作如下几方面展开:
一、为什么要在WEB中引入文档流(Document Flow)
其主要原因如下:1.系统化学习,并高效理解CSS标准
2.从原理级理解浏览器对网页的解析过程
3.让CSS HACK得到可遵循解释
4.降低CSS HACK管理的难度
设想,如果对CSS的学习和理解,可以像其他理工课程内容一样,有一个一般性的原理和规则来解释其中的现象或行为,那么无疑对于解决以上四个问题均提供了有力保证。本文作者认为,文档流(Document Flow)就可以作为一个具有一般性的,能解释CSS和浏览器对WEB的解析情况的理论。同时本文中所讨论的角度主要从浏览器实际行为出发,故在下面阐述的观点中,与W3C所定标准之间存在一定的偏差。
二、文档流在WEB中如何工作
如开篇所述,文档流是在浏览器中输入与输出的综合。那么讨论文档流在WEB中如何工作,其实就是在讨论浏览器对网页的解析过程,也就是浏览器本身的行为过程。在计算机中,一个程序进程读取文件一定是通过文件指针(File Pointer),从起始位一直移动到文件结束(End Of File)。而对应该进程的输出过程也一定是与输入过程相同的顺序,故可形象地将文件指针的移动过程本身看作文档流。
那么浏览器进程输出显示网页排版内容,就一定是按照其在文档流中的顺序而输出的。形象地说,整个文档开始的内容一定是最先输出,而且其后所跟的内容在文档中也一定是记载于其对应部分之后。(Content at the top of the document,for example,is displayed first and is followed by the content after it.)
在WEB里,所有内容都是通过HTML作为载体。故其文档流,就是由一个个的HTML元素(HTML Elements)组成。在代码上,HTML元素又是通过HTML标签来作为实体,故在W3C标准中,将HTML标签分成块级元素(Block-level Elements)与行级元素(Inline-level Elements)两类,来定义WEB中的文档流工作实质:
1.在同一文档流平面中,块级元素在显示时独占一行,同级的块级元素也只能与其上下相邻。HTML4中与之对应的标签是
2.行级元素是作为其所在文档流中的一个内
一般论文格式范文www.udooo.com
容部分来显示,相当于是段落中的文本内容部分,HTML4中与之对应的标签就是。由上可见,WEB中文档流如何工作的讨论重点,就是浏览器对块级元素与行级元素的解析与输出规则。
而这两类元素之间,行级元素就是含在块级元素中的内容,而块级元素是作为一个个的盒子(Box Model)在整个页面中起占位排版的作用。
三、用文档流解释CSS布局定位模式(Positioning Schemes)
根据W3C标准,在布局定位模式(Positioning Schemes)中,将文档流分成三类:常规流(Normal Flow)、浮动流(Floats)与绝对定位流(Absolute Positioning)。这样就可以很好地在整个空间体系中来形象描述CSS的布局定位模式。在此将整个浏览器屏幕所在平面定义为xoy平面,那么在这个空间中的z轴则是垂直于屏幕,这其实正是CSS中的z-index属性——垂直于屏幕向外为该z轴的正方向。
在一个文件中,可以由多个流组成,而每个流从xoy平面上来看均占满整个平面。那么流与流之间就是在z轴上的层叠关系。这个关系也有点类似于作图软件中的图层关系,即每一个流相当于一个图层。
流也分成三类,那么不同类型的流则也表现不同:
1.常规流(Normal Flow)是一个文档流内部的原始体系,可以想像成一张平铺的白纸。
2.绝对定位流(Absolute Positioning)是脱离原始的流而形成一层新的流,并按给定的相应属性或规则(如z-index),与其他流之间形成层叠覆盖关系。
3.浮动流(Floats)在本文中认为其本身未脱离所在的流,却相对于所在的母体流形成突起,从而使得在表现上类似于绝对定位流,与母体流形成层叠覆盖关系,可其实质上却并未脱离母体文档流。也就是相当于半个绝对定位。
对于元素与流之间的关系,又可将不同定位属性的HTML元素分为如下三类:1.置入文档流(In Flow):所有非绝对定位的元素均为置入文档流。而元素在文档流中可以形成突起浮动(Float),从而使得在输出表现上与脱离文档流相同。
2.基本文档流
摘自：毕业论文翻译www.udooo.com
(Fundamental Flow):作为整个文档中各层流的一个参考系。一般以z-index为0的那层流作为基本文档流。那么在基本文档流中的浮动流在表现上,相当于是形成了一层z-index为0.5的文档流(注:z-index必须为整数,此处的0.5只是为作一形象阐述)。3.脱离文档流(Out Of Flow):所有绝对定位的元素均脱离文档流。而所谓的流又都是通过HTML元素作为载体来表现的,那么每一个元素脱离文档流,实质上就是,该元素脱离了其父标签元素所在的文档流而独立形成一个新的流。
以上观点虽与W3C标准略有出路,却可以更好地来解释和理解浏览器行为。
HTML文档本身是由一个个HTML元素组成,在XHTML中,这些元素也被称为DOM元素。而根据以上观点,每一个元素本身又一定属于一种文档流,所以自然可以得出:
元素作为整个HTML文档的根结点元素(Node),本身就是基本文档流。
而元素中的一级子结点元素,若赋予绝对定位,那么该属性则是脱离基本文档流而形成一层新的流。
综上所述,一个元素A的流,实质上就是一个由A元素本身和其内所有的置入文档流子元素所组成的集合。
也有:常规流中的所有元素均为置入文档流。
至此,CSS布局体系则可通过文档流来得到完全解释:
四、用文档流解释不同浏览器引擎的兼容性问题
不同浏览器引擎对网页的兼容性问题,主要就是来自浮动流(Floats)上。因为本文作者认为浮动流是介于常规流和绝对定位流之间,从而能同时看到这两种流各自的特点。而问题就是不同的浏览器引擎对于这个之间的程度把握不同。
IE6、IE7中将浮动流很大程度上作为常规流解析,导致在IE6中并未做到浮动流相对于其母体流的突起,所以会出现IE6在边界问题上(margin值问题)与其他浏览器之间存在很大偏差。
典型的IE捉迷藏问题(Peekaboo Bug)也可以通过文档流来进行很好的解释,其原因就是在于行级元素甚至直接就是文本内容与块级元素同级存放。这对浏览器的解析本身就是形成了困难,因为像IE6、IE7这样不突起形成z-index为0.5的浮动流,与IE8+和Firefox与Chrome这样接近W3C标准,将浮动流突起的浏览器引擎之间,解析自然就有问题了。所以也正如过去对捉迷藏问题的解决方案,注意DIV的嵌套习惯,避开不同级别元素和文本同级情况。
至此,可以看到其实浏览器兼容性问题的起因就是因为对文档流的解析输出不同,就是与W3C标准的输出存在偏差。若以文档流来讨论这些问题,会发现连怪异模式(Quirks Mode)也其实并不怪异。
那么既然浏览器引擎的兼容性问题可以得到解释,CSS HACK管理的难度自然可以彻底下降。这样,不论是对于学习CSS还是设计WEB都可以在很大程度上减少对浏览器兼容性的思考,而将更大的精力集中于如何设计美观并具艺术性的网页上了。