[计算机软件及应用]浏览器内部工作原理.doc

上传人:sccc 文档编号:4561905 上传时间:2023-04-27 格式:DOC 页数:32 大小:781.85KB
返回 下载 相关 举报
[计算机软件及应用]浏览器内部工作原理.doc_第1页
第1页 / 共32页
[计算机软件及应用]浏览器内部工作原理.doc_第2页
第2页 / 共32页
[计算机软件及应用]浏览器内部工作原理.doc_第3页
第3页 / 共32页
[计算机软件及应用]浏览器内部工作原理.doc_第4页
第4页 / 共32页
[计算机软件及应用]浏览器内部工作原理.doc_第5页
第5页 / 共32页
点击查看更多>>
资源描述

《[计算机软件及应用]浏览器内部工作原理.doc》由会员分享,可在线阅读,更多相关《[计算机软件及应用]浏览器内部工作原理.doc(32页珍藏版)》请在三一办公上搜索。

1、前端必读:浏览器内部工作原理(1)2012-02-01 13:42 icysoul icysoul的博客 我要评论(0) 字号:T | T浏览器可以被认为是使用最广泛的软件,本文将介绍浏览器的工作原理,我们将看到,从你在地址栏输入到你看到google主页过程中都发生了什么。AD:浏览器可以被认为是使用最广泛的软件,本文将介绍浏览器的工作原理,我们将看到,从你在地址栏输入到你看到google主页过程中都发生了什么。将讨论的浏览器今天,有五种主流浏览器IE、Firefox、Safari、Chrome及Opera。本文将基于一些开源浏览器的例子Firefox、 Chrome及Safari,Safar

2、i是部分开源的。根据W3C(World Wide Web Consortium 万维网联盟)的浏览器统计数据,当前(2011年5月),Firefox、Safari及Chrome的市场占有率综合已接近60%。(原文为2009年 10月,数据没有太大变化)因此,可以说开源浏览器已经占据了浏览器市场的半壁江山。浏览器的主要功能浏览器的主要功能是将用户选择得web资源呈现出来,它需要从服务器请求资源,并将其显示在浏览器窗口中,资源的格式通常是HTML,也包括 PDF、image及其他格式。用户用URI(Uniform Resource Identifier 统一资源标识符)来指定所请求资源的位置,在网

3、络一章有更多讨论。HTML和CSS规范中规定了浏览器解释html文档的方式,由W3C组织对这些规范进行维护,W3C是负责制定web标准的组织。HTML规范的最新版本是HTML4(http:/www.w3.org/TR/html401/),HTML5还在制定中(译注:两年前),最 新的CSS规范版本是2(http:/www.w3.org/TR/CSS2),CSS3也还正在制定中(译注:同样两年前)。这些年来,浏览器厂商纷纷开发自己的扩展,对规范的遵循并不完善,这为Web开发者带来了严重的兼容性问题。但是,浏览器的用户界面则差不多,常见的用户界面元素包括: 用来输入URI的地址栏 前进、后退按钮

4、书签选项 用于刷新及暂停当前加载文档的刷新、暂停按钮 用于到达主页的主页按钮奇怪的是,并没有哪个正式公布的规范对用户界面做出规定,这些是多年来各浏览器厂商之间相互模仿和不断改进得结果。HTML5并没有规定浏览器必须具有的UI元素,但列出了一些常用元素,包括地址栏、状态栏及工具栏。还有一些浏览器有自己专有得功能,比如Firefox得下载管理。更多相关内容将在后面讨论用户界面时介绍。浏览器的主要构成High Level Structure浏览器的主要组件包括:1. 用户界面- 包括地址栏、后退/前进按钮、书签目录等,也就是你所看到的除了用来显示你所请求页面的主窗口之外的其他部分2. 浏览器引擎-

5、用来查询及操作渲染引擎的接口3. 渲染引擎- 用来显示请求的内容,例如,如果请求内容为html,它负责解析html及css,并将解析后的结果显示出来4. 网络- 用来完成网络调用,例如http请求,它具有平台无关的接口,可以在不同平台上工作5. UI 后端- 用来绘制类似组合选择框及对话框等基本组件,具有不特定于某个平台的通用接口,底层使用操作系统的用户接口6. JS解释器- 用来解释执行JS代码7. 数据存储- 属于持久层,浏览器需要在硬盘中保存类似cookie的各种数据,HTML5定义了web database技术,这是一种轻量级完整的客户端存储技术图1:浏览器主要组件需要注意的是,不同于

6、大部分浏览器,Chrome为每个Tab分配了各自的渲染引擎实例,每个Tab就是一个独立的进程。对于构成浏览器的这些组件,后面会逐一详细讨论。组件间的通信 Communication between the componentsFirefox和Chrome都开发了一个特殊的通信结构,后面将有专门的一章进行讨论。渲染引擎 The rendering engine渲染引擎的职责就是渲染,即在浏览器窗口中显示所请求的内容。默认情况下,渲染引擎可以显示html、xml文档及图片,它也可以借助插件(一种浏览器扩展)显示其他类型数据,例如使用PDF阅读器插件,可以显示PDF格式,将由专门一章讲解插件及扩展,

7、这里只讨论渲染引擎最主要的用途显示应用了CSS之后的html及图片。渲染引擎 Rendering engines本文所讨论得浏览器Firefox、Chrome和Safari是基于两种渲染引擎构建的,Firefox使用GeokoMozilla自主研发的渲染引擎,Safari和Chrome都使用webkit。Webkit是一款开源渲染引擎,它本来是为linux平台研发的,后来由Apple移植到Mac及Windows上,相关内容请参考http:/webkit.org。主流程 The main flow渲染引擎首先通过网络获得所请求文档的内容,通常以8K分块的方式完成。下面是渲染引擎在取得内容之后的基

8、本流程:解析html以构建dom树-构建render树-布局render树-绘制render树图2:渲染引擎基本流程渲染引擎开始解析html,并将标签转化为内容树中的dom节点。接着,它解析外部CSS文件及style标签中的样式信息。这些样式信息以及html中的可见性指令将被用来构建另一棵树render树。Render树由一些包含有颜色和大小等属性的矩形组成,它们将被按照正确的顺序显示到屏幕上。Render树构建好了之后,将会执行布局过程,它将确定每个节点在屏幕上的确切坐标。再下一步就是绘制,即遍历render树,并使用UI后端层绘制每个节点。值得注意的是,这个过程是逐步完成的,为了更好的用户

9、体验,渲染引擎将会尽可能早的将内容呈现到屏幕上,并不会等到所有的html都解析完成之后再去构建和布局render树。它是解析完一部分内容就显示一部分内容,同时,可能还在通过网络下载其余内容。图3:webkit主流程图4:Mozilla的Geoko 渲染引擎主流程从图3和4中可以看出,尽管webkit和Gecko使用的术语稍有不同,他们的主要流程基本相同。Gecko称可见的格式化元素组成的树为 frame树,每个元素都是一个frame,webkit则使用render树这个名词来命名由渲染对象组成的树。Webkit中元素的定位称为布局,而 Gecko中称为回流。Webkit称利用dom节点及样式信

10、息去构建render树的过程为attachment,Gecko在html和dom树之间 附加了一层,这层称为内容接收器,相当制造dom元素的工厂。下面将讨论流程中的各个阶段。解析 Parsing-general既然解析是渲染引擎中一个非常重要的过程,我们将稍微深入的研究它。首先简要介绍一下解析。解析一个文档即将其转换为具有一定意义的结构编码可以理解和使用的东西。解析的结果通常是表达文档结构的节点树,称为解析树或语法树。例如,解析“2+3-1”这个表达式,可能返回这样一棵树。图5:数学表达式树节点文法 Grammars解析基于文档依据的语法规则文档的语言或格式。每种可被解析的格式必须具有由词汇及

11、语法规则组成的特定的文法,称为上下文无关文法。人类语言不具有这一特性,因此不能被一般的解析技术所解析。解析器-词法分析器 Parser-Lexer combination解析可以分为两个子过程语法分析及词法分析词法分析就是将输入分解为符号,符号是语言的词汇表基本有效单元的集合。对于人类语言来说,它相当于我们字典中出现的所有单词。语法分析指对语言应用语法规则。解析器一般将工作分配给两个组件词法分析器(有时也叫分词器)负责将输入分解为合法的符号,解析器则根据语言的语法规则分析文档结构,从而构建解析树,词法分析器知道怎么跳过空白和换行之类的无关字符。图6:从源文档到解析树解析过程是迭代的,解析器从词

12、法分析器处取道一个新的符号,并试着用这个符号匹配一条语法规则,如果匹配了一条规则,这个符号对应的节点将被添加到 解析树上,然后解析器请求另一个符号。如果没有匹配到规则,解析器将在内部保存该符号,并从词法分析器取下一个符号,直到所有内部保存的符号能够匹配一项 语法规则。如果最终没有找到匹配的规则,解析器将抛出一个异常,这意味着文档无效或是包含语法错误。转换 Translation很多时候,解析树并不是最终结果。解析一般在转换中使用将输入文档转换为另一种格式。编译就是个例子,编译器在将一段源码编译为机器码的时候,先将源码解析为解析树,然后将该树转换为一个机器码文档。图7:编译流程解析实例 Pars

13、ing example图5中,我们从一个数学表达式构建了一个解析树,这里定义一个简单的数学语言来看下解析过程。词汇表:我们的语言包括整数、加号及减号。语法:1. 该语言的语法基本单元包括表达式、term及操作符2. 该语言可以包括多个表达式3. 一个表达式定义为两个term通过一个操作符连接4. 操作符可以是加号或减号5. term可以是一个整数或一个表达式现在来分析一下“2+3-1”这个输入第一个匹配规则的子字符串是“2”,根据规则5,它是一个term,第二个匹配的是“2+3”,它符合第2条规则一个操作符连接两个term, 下一次匹配发生在输入的结束处。“2+3-1”是一个表达式,因为我们已

14、经知道“2+3”是一个term,所以我们有了一个term紧跟着一个操作符及另 一个term。“2+”将不会匹配任何规则,因此是一个无效输入。词汇表及语法的定义词汇表通常利用正则表达式来定义。例如上面的语言可以定义为:INTEGER:0|1-90-9*PLUS:+MINUS:-正如看到的,这里用正则表达式定义整数。语法通常用BNF格式定义,我们的语言可以定义为:expression := term operation termoperation := PLUS | MINUSterm := INTEGER | expression如果一个语言的文法是上下文无关的,则它可以用正则解析器来解析。对上

15、下文无关文法的一个直观的定义是,该文法可以用BNF来完整的表达。可查看http:/en.wikipedia.org/wiki/Context-free_grammar。解析器类型 Types of parsers有两种基本的解析器自顶向下解析及自底向上解析。比较直观的解释是,自顶向下解析,查看语法的最高层结构并试着匹配其中一个;自底向上解析则从输入开始,逐步将其转换为语法规则,从底层规则开始直到匹配高层规则。来看一下这两种解析器如何解析上面的例子:自顶向下解析器从最高层规则开始它先识别出“2+3“,将其视为一个表达式,然后识别出”2+3-1“为一个表达式(识别表达式的过程中匹配了其他规则,但出

16、发点是最高层规则)。自底向上解析会扫描输入直到匹配了一条规则,然后用该规则取代匹配的输入,直到解析完所有输入。部分匹配的表达式被放置在解析堆栈中。StackInput 2 + 3 1term+ 3 - 1term operation3 1expression- 1expression operation1expression 自底向上解析器称为shift reduce 解析器,因为输入向右移动(想象一个指针首先指向输入开始处,并向右移动),并逐渐简化为语法规则。自动化解析 Generating parsers automatically解析器生成器这个工具可以自动生成解析器,只需要指定语言的文

17、法词汇表及语法规则,它就可以生成一个解析器。创建一个解析器需要对解析有深入的 理解,而且手动的创建一个由较好性能的解析器并不容易,所以解析生成器很有用。Webkit使用两个知名的解析生成器用于创建语法分析器的Flex及 创建解析器的Bison(你可能接触过Lex和Yacc)。Flex的输入是一个包含了符号定义的正则表达式,Bison的输入是用BNF格式表示的语法 规则。HTML解析器 HTML ParserHTML解析器的工作是将html标识解析为解析树。HTML文法定义 The HTML grammar definitionW3C组织制定规范定义了HTML的词汇表和语法。非上下文无关文法 N

18、ot a context free grammar正如在解析简介中提到的,上下文无关文法的语法可以用类似BNF的格式来定义。不幸的是,所有的传统解析方式都不适用于html(当然我提出它们并不只是因为好玩,它们将用来解析css和js),html不能简单的用解析所需的上下文无关文法来定义。Html 有一个正式的格式定义DTD(Document Type Definition 文档类型定义)但它并不是上下文无关文法,html更接近于xml,现在有很多可用的xml解析器,html有个xml的变体xhtml,它们间 的不同在于,html更宽容,它允许忽略一些特定标签,有时可以省略开始或结束标签。总的来说

19、,它是一种soft语法,不像xml呆板、固执。显然,这个看起来很小的差异却带来了很大的不同。一方面,这是html流行的原因它的宽容使web开发人员的工作更加轻松,但另一方面,这也使很难去写一个格式化的文法。所以,html的解析并不简单,它既不能用传统的解析器解析,也不能用xml解析器解析。HTML DTDHtml适用DTD格式进行定义,这一格式是用于定义SGML家族的语言,包括了对所有允许元素及它们的属性和层次关系的定义。正如前面提到的,html DTD并没有生成一种上下文无关文法。DTD有一些变种,标准模式只遵守规范,而其他模式则包含了对浏览器过去所使用标签的支持,这么做是为了兼容以前内容。

20、最新的标准DTD在http:/www.w3.org/TR/html4/strict.dtdDOM输出的树,也就是解析树,是由DOM元素及属性节点组成的。DOM是文档对象模型的缩写,它是html文档的对象表示,作为html元素的外部接口供js等调用。树的根是“document”对象。DOM和标签基本是一一对应的关系,例如,如下的标签:1 2 3 4 Hello DOM 5 6 7 8 将会被转换为下面的DOM树:图8:示例标签对应的DOM树和html一样,DOM的规范也是由W3C组织制定的。访问http:/www.w3.org/DOM/DOMTR,这是使用文档的一般规范。一 个模型描述一种特定的

21、html元素,可以在http:/www.w3.org/TR/2003/REC-DOM-Level-2-HTML- 20030109/idl-definitions.htm 查看html定义。这里所谓的树包含了DOM节点是说树是由实现了DOM接口的元素构建而成的,浏览器使用已被浏览器内部使用的其他属性的具体实现。解析算法 The parsing algorithm正如前面章节中讨论的,hmtl不能被一般的自顶向下或自底向上的解析器所解析。原因是:1. 这门语言本身的宽容特性2. 浏览器对一些常见的非法html有容错机制3. 解析过程是往复的,通常源码不会在解析过程中发生改变,但在html中,脚本

22、标签包含的“document.write”可能添加标签,这说明在解析过程中实际上修改了输入不能使用正则解析技术,浏览器为html定制了专属的解析器。Html5规范中描述了这个解析算法,算法包括两个阶段符号化及构建树。符号化是词法分析的过程,将输入解析为符号,html的符号包括开始标签、结束标签、属性名及属性值。符号识别器识别出符号后,将其传递给树构建器,并读取下一个字符,以识别下一个符号,这样直到处理完所有输入。图9:HTML解析流程符号识别算法 The tokenization algorithm算法输出html符号,该算法用状态机表示。每次读取输入流中的一个或多个字符,并根据这些字符转移到

23、下一个状态,当前的符号状态及构建树状态共同影响结果,这意味着,读取同样的字符,可能因为当前状态的不同,得到不同的结果以进入下一个正确的状态。这个算法很复杂,这里用一个简单的例子来解释这个原理。基本示例符号化下面的html:9 10 11 Hello world 12 13 初始状态为“Data State”,当遇到“”,每个字符都附加到这个符号名上,例子中创建的是一个html符号。当读取到“”,当前的符号就完成了,此时,状态回到“Data state”,“”重复这一处理过程。到这里,html和body标签都识别出来了。现在,回到“Data state”,读取“Hello world”中的字符“

24、H”将创建并识别出一个字符符号,这里会为“Hello world”中的每个字符生成一个字符符号。这样直到遇到“”中的“”。然后,产生一个新的标签符号并回到“Data state”。后面的“”将和“”一样处理。图10:符号化示例输入树的构建算法 Tree construction algorithm在树的构建阶段,将修改以Document为根的DOM树,将元素附加到树上。每个由符号识别器识别生成的节点将会被树构造器进行处理,规范中定义 了每个符号相对应的Dom元素,对应的Dom元素将会被创建。这些元素除了会被添加到Dom树上,还将被添加到开放元素堆栈中。这个堆栈用来纠正嵌套的未 匹配和未闭合标签

25、,这个算法也是用状态机来描述,所有的状态采用插入模式。来看一下示例中树的创建过程:14 15 16 Hello world 17 18 构建树这一阶段的输入是符号识别阶段生成的符号序列。首先是“initial mode”,接收到html符号后将转换为“before html”模式,在这个模式中对这个符号进行再处理。此时,创建了一个HTMLHtmlElement元素,并将其附加到根Document对象上。状态此时变为“before head”,接收到body符号时,即使这里没有head符号,也将自动创建一个HTMLHeadElement元素并附加到树上。现在,转到“in head”模式,然后是“

26、after head”。到这里,body符号会被再次处理,将创建一个HTMLBodyElement并插入到树中,同时,转移到“in body”模式。然后,接收到字符串“Hello world”的字符符号,第一个字符将导致创建并插入一个text节点,其他字符将附加到该节点。接收到body结束符号时,转移到“after body”模式,接着接收到html结束符号,这个符号意味着转移到了“after after body”模式,当接收到文件结束符时,整个解析过程结束。图11:示例html树的构建过程解析结束时的处理 Action when the parsing is finished在这个阶段,浏

27、览器将文档标记为可交互的,并开始解析处于延时模式中的脚本这些脚本在文档解析后执行。文档状态将被设置为完成,同时触发一个load事件。Html5规范中有符号化及构建树的完整算法(http:/www.w3.org/TR/html5/syntax.html#html-parser)。浏览器容错 Browsers error tolerance你从来不会在一个html页面上看到“无效语法”这样的错误,浏览器修复了无效内容并继续工作。以下面这段html为例:19 20 21 22 23 24 25 Really lousy HTML 26 27 这段html违反了很多规则(mytag不是合法的标签,p及

28、div错误的嵌套等等),但是浏览器仍然可以没有任何怨言的继续显示,它在解析的过程中修复了html作者的错误。浏览器都具有错误处理的能力,但是,另人惊讶的是,这并不是html最新规范的内容,就像书签及前进后退按钮一样,它只是浏览器长期发展的结果。一些比较知名的非法html结构,在许多站点中出现过,浏览器都试着以一种和其他浏览器一致的方式去修复。Html5规范定义了这方面的需求,webkit在html解析类开始部分的注释中做了很好的总结。解析器将符号化的输入解析为文档并创建文档,但不幸的是,我们必须处理很多没有很好格式化的html文档,至少要小心下面几种错误情况。1. 在未闭合的标签中添加明确禁止

29、的元素。这种情况下,应该先将前一标签闭合2. 不能直接添加元素。有些人在写文档的时候会忘了中间一些标签(或者中间标签是可选的),比如HTML HEAD BODY TR TD LI等3. 想在一个行内元素中添加块状元素。关闭所有的行内元素,直到下一个更高的块状元素4. 如果这些都不行,就闭合当前标签直到可以添加该元素。下面来看一些webkit容错的例子:替代一些网站使用替代,为了兼容IE和Firefox,webkit将其看作。代码:28 if (t-isCloseTag(brTag) & m_document-inCompatMode() 29 reportError(MalformedBREr

30、ror); 30 t-beginTag = true; 31 Note-这里的错误处理在内部进行,用户看不到。迷路的表格这指一个表格嵌套在另一个表格中,但不在它的某个单元格内。比如下面这个例子:32 33 34 inner table 35 36 outer table 37 webkit将会将嵌套的表格变为两个兄弟表格:38 39 outer table 40 41 42 inner table 43 代码:44 if (m_inStrayTableContent & localName = tableTag) 45 popBlock(tableTag); webkit使用堆栈存放当前的元素

31、内容,它将从外部表格的堆栈中弹出内部的表格,则它们变为了兄弟表格。嵌套的表单元素用户将一个表单嵌套到另一个表单中,则第二个表单将被忽略。代码:46 if (!m_currentFormElement) 47 m_currentFormElement = new HTMLFormElement(formTag, m_document); 48 太深的标签继承www.liceo.edu.mx是一个由嵌套层次的站点的例子,最多只允许20个相同类型的标签嵌套,多出来的将被忽略。代码:49 bool HTMLParser:allowNestedRedundantTag(const AtomicStrin

32、g& tagName) 50 51 52 unsigned i = 0; 53 for (HTMLStackElem* curr = m_blockStack; 54 i tagName = tagName; 55 currcurr = curr-next, i+) 56 return i != cMaxRedundantTagDepth; 57 放错了地方的html、body闭合标签又一次不言自明。支持不完整的html。我们从来不闭合body,因为一些愚蠢的网页总是在还未真正结束时就闭合它。我们依赖调用end方法去执行关闭的处理。代码:58 if (t-tagName = htmlTag |

33、 t-tagName = bodyTag ) 59 return; 所以,web开发者要小心了,除非你想成为webkit容错代码的范例,否则还是写格式良好的html吧。CSS解析 CSS parsing还记得简介中提到的解析的概念吗,不同于html,css属于上下文无关文法,可以用前面所描述的解析器来解析。Css规范定义了css的词法及语法文法。看一些例子:每个符号都由正则表达式定义了词法文法(词汇表):comment /*/*+(/*/*+)*/num 0-9+|0-9*.0-9+nonascii /200-/377nmstart _a-z|nonascii|escapenmchar _a-

34、z0-9-|nonascii|escapename nmchar+ident nmstartnmchar*“ident”是识别器的缩写,相当于一个class名,“name”是一个元素id(用“#”引用)。语法用BNF进行描述:1 ruleset 2 : selector , S* selector * 3 S* declaration ; S* declaration * S* 4 ; 5 selector 6 : simple_selector combinator selector | S+ combinator selector 7 ; 8 simple_selector 9 : ele

35、ment_name HASH | class | attrib | pseudo * 10 | HASH | class | attrib | pseudo + 11 ; 12 class 13 : . IDENT 14 ; 15 element_name 16 : IDENT | * 17 ; 18 attrib 19 : S* IDENT S* = | INCLUDES | DASHMATCH S* 20 IDENT | STRING S* 21 ; 22 pseudo 23 : : IDENT | FUNCTION S* IDENT S* ) 24 ; 说明:一个规则集合有这样的结构25

36、 div.error , a.error 26 color:red; 27 font-weight:bold; 28 div.error和a.error时选择器,大括号中的内容包含了这条规则集合中的规则,这个结构在下面的定义中正式的定义了:29 ruleset 30 : selector , S* selector * 31 S* declaration ; S* declaration * S* 32 ; 这说明,一个规则集合具有一个或是可选个数的多个选择器,这些选择器以逗号和空格(S表示空格)进行分隔。每个规则集合包含大括号及大括号中的一条或多条以分号隔开的声明。声明和选择器在后面进行定义

37、。Webkit CSS 解析器 Webkit CSS parserWebkit使用Flex和Bison解析生成器从CSS语法文件中自动生成解析器。回忆一下解析器的介绍,Bison创建一个自底向上的解析 器,Firefox使用自顶向下解析器。它们都是将每个css文件解析为样式表对象,每个对象包含css规则,css规则对象包含选择器和声明对象,以及 其他一些符合css语法的对象。图12:解析css脚本解析 Parsing scripts本章将介绍Javascript。处理脚本及样式表的顺序 The order of processing scripts and style sheets脚本web的

38、模式是同步的,开发者希望解析到一个script标签时立即解析执行脚本,并阻塞文档的解析直到脚本执行完。如果脚本是外引的,则网络必须 先请求到这个资源这个过程也是同步的,会阻塞文档的解析直到资源被请求到。这个模式保持了很多年,并且在html4及html5中都特别指定了。开发 者可以将脚本标识为defer,以使其不阻塞文档解析,并在文档解析结束后执行。Html5增加了标记脚本为异步的选项,以使脚本的解析执行使用另一个线 程。预解析 Speculative parsingWebkit和Firefox都做了这个优化,当执行脚本时,另一个线程解析剩下的文档,并加载后面需要通过网络加载的资源。这种方式可以

39、使资源并 行加载从而使整体速度更快。需要注意的是,预解析并不改变Dom树,它将这个工作留给主解析过程,自己只解析外部资源的引用,比如外部脚本、样式表及图 片。样式表 Style sheets样式表采用另一种不同的模式。理论上,既然样式表不改变Dom树,也就没有必要停下文档的解析等待它们,然而,存在一个问题,脚本可能在文档的解析 过程中请求样式信息,如果样式还没有加载和解析,脚本将得到错误的值,显然这将会导致很多问题,这看起来是个边缘情况,但确实很常见。Firefox在存 在样式表还在加载和解析时阻塞所有的脚本,而chrome只在当脚本试图访问某些可能被未加载的样式表所影响的特定的样式属性时才阻

40、塞这些脚本。渲染树的构造 Render tree construction当Dom树构建完成时,浏览器开始构建另一棵树渲染树。渲染树由元素显示序列中的可见元素组成,它是文档的可视化表示,构建这棵树是为了以正确的顺序绘制文档内容。Firefox将渲染树中的元素称为frames,webkit则用renderer或渲染对象来描述这些元素。一个渲染对象直到怎么布局及绘制自己及它的children。RenderObject是Webkit的渲染对象基类,它的定义如下:33 class RenderObject 34 virtual void layout(); 35 virtual void paint(

41、PaintInfo); 36 virtual void rect repaintRect(); 37 Node* node; /the DOM node 38 RenderStyle* style; / the computed style 39 RenderLayer* containgLayer; /the containing z-index layer 40 每个渲染对象用一个和该节点的css盒模型相对应的矩形区域来表示,正如css2所描述的那样,它包含诸如宽、高和位置之类的几何信息。盒模型的类 型受该节点相关的display样式属性的影响(参考样式计算章节)。下面的webkit代码说

42、明了如何根据display属性决定某个节点创建何种类型 的渲染对象。41 RenderObject* RenderObject:createObject(Node* node, RenderStyle* style) 42 43 Document* doc = node-document(); 44 RenderArena* arena = doc-renderArena(); 45 . 46 RenderObject* o = 0; 47 48 switch (style-display() 49 case NONE: 50 break; 51 case INLINE: 52 o = new (arena) RenderInline(node); 53 break; 54 case BLOCK: 55 o = new (arena) RenderBlock(node); 56 break; 57 case INLINE_BLOCK: 58 o = new (arena) RenderBlock(node); 59 break; 60 case LIST_ITEM: 61 o = new

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 教育教学 > 成人教育


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号