浏览器Css加载原理.docx

浏览器Css加载原理.docx

《浏览器Css加载原理.docx》由会员分享，可在线阅读，更多相关《浏览器Css加载原理.docx（29页珍藏版）》请在冰豆网上搜索。

浏览器Css加载原理

前端必读：

浏览器Css加载原理

　　CSS解析（CSSparsing）

　　还记得简介中提到的解析的概念吗，不同于html，css属于上下文无关文法，可以用前面所描述的解析器来解析。

Css规范定义了css的词法及语法文法。

　　看一些例子：

　　每个符号都由正则表达式定义了词法文法（词汇表）：

comment///*[^*]*/*+（[^/*][^*]*/*+）*//

num[0-9]+|[0-9]*"."[0-9]+

nonascii[/200-/377]

nmstart[_a-z]|{nonascii}|{escape}

nmchar[_a-z0-9-]|{nonascii}|{escape}

name{nmchar}+

ident{nmstart}{nmchar}*

　　“ident”是识别器的缩写，相当于一个class名，“name”是一个元素id（用“＃”引用）。

　　语法用BNF进行描述：

ruleset

:

selector[','S*selector]*

'{'S*declaration[';'S*declaration]*'}'S*

;

selector

:

simple_selector[combinatorselector|S+[combinatorselector]]

;

simple_selector

:

element_name[HASH|class|attrib|pseudo]*

|[HASH|class|attrib|pseudo]+

;

class

:

'.'IDENT

;

element_name

:

IDENT|'*'

;

attrib

:

'['S*IDENTS*[['='|INCLUDES|DASHMATCH]S*

[IDENT|STRING]S*]']'

;

pseudo

:

':

'[IDENT|FUNCTIONS*[IDENTS*]'）']

;

说明：

一个规则集合有这样的结构

div.error,a.error{

color:

red;

font-weight:

bold;

}

div.error和a.error时选择器，大括号中的内容包含了这条规则集合中的规则，这个结构在下面的定义中正式的定义了：

ruleset

:

selector[','S*selector]*

'{'S*declaration[';'S*declaration]*'}'S*

;

　　这说明，一个规则集合具有一个或是可选个数的多个选择器，这些选择器以逗号和空格（S表示空格）进行分隔。

每个规则集合包含大括号及大括号中的一条或多条以分号隔开的声明。

声明和选择器在后面进行定义。

　　WebkitCSS解析器（WebkitCSSparser）

　　Webkit使用Flex和Bison解析生成器从CSS语法文件中自动生成解析器。

回忆一下解析器的介绍，Bison创建一个自底向上的解析器，Firefox使用自顶向下解析器。

它们都是将每个css文件解析为样式表对象，每个对象包含css规则，css规则对象包含选择器和声明对象，以及其他一些符合css语法的对象。

图12：

解析css

　　处理脚本及样式表的顺序（Theorderofprocessingscriptsandstylesheets）

　　脚本

　　web的模式是同步的，开发者希望解析到一个script标签时立即解析执行脚本，并阻塞文档的解析直到脚本执行完。

如果脚本是外引的，则网络必须先请求到这个资源——这个过程也是同步的，会阻塞文档的解析直到资源被请求到。

这个模式保持了很多年，并且在html4及html5中都特别指定了。

开发者可以将脚本标识为defer，以使其不阻塞文档解析，并在文档解析结束后执行。

Html5增加了标记脚本为异步的选项，以使脚本的解析执行使用另一个线程。

　　预解析（Speculativeparsing）

　　Webkit和Firefox都做了这个优化，当执行脚本时，另一个线程解析剩下的文档，并加载后面需要通过网络加载的资源。

这种方式可以使资源并行加载从而使整体速度更快。

需要注意的是，预解析并不改变Dom树，它将这个工作留给主解析过程，自己只解析外部资源的引用，比如外部脚本、样式表及图片。

　　样式表（Stylesheets）

　　样式表采用另一种不同的模式。

理论上，既然样式表不改变Dom树，也就没有必要停下文档的解析等待它们，然而，存在一个问题，脚本可能在文档的解析过程中请求样式信息，如果样式还没有加载和解析，脚本将得到错误的值，显然这将会导致很多问题，这看起来是个边缘情况，但确实很常见。

Firefox在存在样式表还在加载和解析时阻塞所有的脚本，而Chrome只在当脚本试图访问某些可能被未加载的样式表所影响的特定的样式属性时才阻塞这些脚本。

　　四、渲染树构建（Rendertreeconstruction）

　　当Dom树构建完成时，浏览器开始构建另一棵树——渲染树。

渲染树由元素显示序列中的可见元素组成，它是文档的可视化表示，构建这棵树是为了以正确的顺序绘制文档内容。

　　Firefox将渲染树中的元素称为frames，WebKit则用renderer或渲染对象来描述这些元素。

　　一个渲染对象知道怎么布局及绘制自己及它的children。

　　RenderObject是Webkit的渲染对象基类，它的定义如下：

classRenderObject{

virtualvoidlayout（）;

virtualvoidpaint（PaintInfo）;

virtualvoidrectrepaintRect（）;

Node*node;//theDOMnode

RenderStyle*style;//thecomputedstyle

RenderLayer*containgLayer;//thecontainingz-indexlayer

}

　　每个渲染对象用一个和该节点的css盒模型相对应的矩形区域来表示，正如css2所描述的那样，它包含诸如宽、高和位置之类的几何信息。

盒模型的类型受该节点相关的display样式属性的影响（参考样式计算章节）。

下面的webkit代码说明了如何根据display属性决定某个节点创建何种类型的渲染对象。

RenderObject*RenderObject:

:

createObject（Node*node,RenderStyle*style）

{

Document*doc=node->document（）;

RenderArena*arena=doc->renderArena（）;

...

RenderObject*o=0;

switch（style->display（））{

caseNONE:

break;

caseINLINE:

o=new（arena）RenderInline（node）;

break;

caseBLOCK:

o=new（arena）RenderBlock（node）;

break;

caseINLINE_BLOCK:

o=new（arena）RenderBlock（node）;

break;

caseLIST_ITEM:

o=new（arena）RenderListItem（node）;

break;

...

}

returno;

}

　　元素的类型也需要考虑，例如，表单控件和表格带有特殊的框架。

　　在Webkit中，如果一个元素想创建一个特殊的渲染对象，它需要重写“createRenderer”方法，使渲染对象指向不包含几何信息的样式对象。

　　渲染树和Dom树的关系（TherendertreerelationtotheDOMtree）

　　渲染对象和Dom元素相对应，但这种对应关系不是一对一的，不可见的Dom元素不会被插入渲染树，例如head元素。

另外，display属性为none的元素也不会在渲染树中出现（visibility属性为hidden的元素将出现在渲染树中）。

　　还有一些Dom元素对应几个可见对象，它们一般是一些具有复杂结构的元素，无法用一个矩形来描述。

例如，select元素有三个渲染对象——一个显示区域、一个下拉列表及一个按钮。

同样，当文本因为宽度不够而折行时，新行将作为额外的渲染元素被添加。

另一个多个渲染对象的例子是不规范的html，根据css规范，一个行内元素只能仅包含行内元素或仅包含块状元素，在存在混合内容时，将会创建匿名的块状渲染对象包裹住行内元素。

　　一些渲染对象和所对应的Dom节点不在树上相同的位置，例如，浮动和绝对定位的元素在文本流之外，在两棵树上的位置不同，渲染树上标识出真实的结构，并用一个占位结构标识出它们原来的位置。

图13：

渲染树及对应的Dom树

　　创建树的流程（Theflowofconstructingthetree）

　　Firefox中，表述为一个监听Dom更新的监听器，将frame的创建委派给FrameConstructor，这个构建器计算样式（参看样式计算）并创建一个frame。

　　Webkit中，计算样式并生成渲染对象的过程称为attachment，每个Dom节点有一个attach方法，attachment的过程是同步的，调用新节点的attach方法将节点插入到Dom树中。

　　处理html和body标签将构建渲染树的根，这个根渲染对象对应被css规范称为containingblock的元素——包含了其他所有块元素的顶级块元素。

它的大小就是viewport——浏览器窗口的显示区域，Firefox称它为viewPortFrame，webkit称为RenderView，这个就是文档所指向的渲染对象，树中其他的部分都将作为一个插入的Dom节点被创建。

　　样式计算（StyleComputation）

　　创建渲染树需要计算出每个渲染对象的可视属性，这可以通过计算每个元素的样式属性得到。

　　样式包括各种来源的样式表，行内样式元素及html中的可视化属性（例如bgcolor），可视化属性转化为css样式属性。

　　样式表来源于浏览器默认样式表，及页面作者和用户提供的样式表——有些样式是浏览器用户提供的（浏览器允许用户定义喜欢的样式，例如，在Firefox中，可以通过在FirefoxProfile目录下放置样式表实现）。

　　计算样式的一些困难：

　　1.样式数据是非常大的结构，保存大量的样式属性会带来内存问题。

　　2.如果不进行优化，找到每个元素匹配的规则会导致性能问题，为每个元素查找匹配的规则都需要遍历整个规则表，这个过程有很大的工作量。

选择符可能有复杂的结构，匹配过程如果沿着一条开始看似正确，后来却被证明是无用的路径，则必须去尝试另一条路径。

　　例如，下面这个复杂选择符

　　divdivdivdiv｛…｝

　　这意味着规则应用到三个div的后代div元素，选择树上一条特定的路径去检查，这可能需要遍历节点树，最后却发现它只是两个div的后代，并不使用该规则，然后则需要沿着另一条路径去尝试

　　3.应用规则涉及非常复杂的级联，它们定义了规则的层次

　　我们来看一下浏览器如何处理这些问题：

　　共享样式数据（Sharingstyledata）

　　WebkKit节点引用样式对象（渲染样式），某些情况下，这些对象可以被节点间共享，这些节点需要是兄弟或是表兄弟节点，并且：

　　1.这些元素必须处于相同的鼠标状态（比如不能一个处于hover，而另一个不是）

　　2.不能有元素具有id

　　3.标签名必须匹配

　　4.class属性必须匹配

　　5.对应的属性必须相同

　　6.链接状态必须匹配

　　7.焦点状态必须匹配

　　8.不能有元素被属性选择器影响

　　9.元素不能有行内样式属性

　　10.不能有生效的兄弟选择器，webcore在任何兄弟选择器相遇时只是简单的抛出一个全局转换，并且在它们显示时使整个文档的样式共享失效，这些包括＋选择器和类似:

first-child和:

last-child这样的选择器。

　　Firefox规则树（Firefoxruletree）

　　Firefox用两个树用来简化样式计算－规则树和样式上下文树，WebKit也有样式对象，但它们并没有存储在类似样式上下文树这样的树中，只是由Dom节点指向其相关的样式。

图14：

Firefox样式上下文树

　　样式上下文包含最终值，这些值是通过以正确顺序应用所有匹配的规则，并将它们由逻辑值转换为具体的值，例如，如果逻辑值为屏幕的百分比，则通过计算将其转化为绝对单位。

样式树的使用确实很巧妙，它使得在节点中共享的这些值不需要被多次计算，同时也节省了存储空间。

　　所有匹配的规则都存储在规则树中，一条路径中的底层节点拥有最高的优先级，这棵树包含了所找到的所有规则匹配的路径（译注：

可以取巧理解为每条路径对应一个节点，路径上包含了该节点所匹配的所有规则）。

规则树并不是一开始就为所有节点进行计算，而是在某个节点需要计算样式时，才进行相应的计算并将计算后的路径添加到树中。

　　我们将树上的路径看成辞典中的单词，假如已经计算出了如下的规则树：

　　假如需要为内容树中的另一个节点匹配规则，现在知道匹配的规则（以正确的顺序）为B-E-I，因为我们已经计算出了路径A-B-E-I-L，所以树上已经存在了这条路径，剩下的工作就很少了。

　　现在来看一下树如何保存。

　　结构化

　　样式上下文按结构划分，这些结构包括类似border或color这样的特定分类的样式信息。

一个结构中的所有特性不是继承的就是非继承的，对继承的特性，除非元素自身有定义，否则就从它的parent继承。

非继承的特性（称为reset特性）如果没有定义，则使用默认的值。

　　样式上下文树缓存完整的结构（包括计算后的值），这样，如果底层节点没有为一个结构提供定义，则使用上层节点缓存的结构。

　　使用规则树计算样式上下文

　　当为一个特定的元素计算样式时，首先计算出规则树中的一条路径，或是使用已经存在的一条，然后使用路径中的规则去填充新的样式上下文，从样式的底层节点开始，它具有最高优先级（通常是最特定的选择器），遍历规则树，直到填满结构。

如果在那个规则节点没有定义所需的结构规则，则沿着路径向上，直到找到该结构规则。

　　如果最终没有找到该结构的任何规则定义，那么如果这个结构是继承型的，则找到其在内容树中的parent的结构，这种情况下，我们也成功的共享了结构；如果这个结构是reset型的，则使用默认的值。

　　如果特定的节点添加了值，那么需要做一些额外的计算以将其转换为实际值，然后在树上的节点缓存该值，使它的children可以使用。

　　当一个元素和它的一个兄弟元素指向同一个树节点时，完整的样式上下文可以被它们共享。

　　来看一个例子：

假设有下面这段html

thisisa

bigerror

thisisalsoa

verybigerror

error