「三」浏览器中CSS 语法解析过程

CSS 语法解析过程

1.在浏览器系列文章中，今天终点讲下CSS解析这块内容.我们已知浏览器的渲染流程中HTML Parser会生成 DOM树，而 CSS Parser会将解析结果附加到 DOM 树上，如下图：

image.png

解析分为词法分析 和 语法分析。

image.png

词法分析，也是编译原理中的术语，从左到右一个字符一个字符的读入源程序，对字符流进行扫描，根据构词规则识别单词。这一过程可以使用lex等工具自动生成。

语法分析，主要任务是在词法分析的基础上，将单词序列组合成各类语法短语，如“程序”， “语句”，“表达式”

解析工作通常会被拆分为两个组件：

1. 词法分析器，负责将输入流分解成有效的字符。
2. 解析器，负责根据不同语言的语法规则来分析文档结构，最后构造出解析树。
   词法分析器知道如何去除不相关的字符，比如空格和换行

具体到css解析，因为它是上下文无关的语法，可以利用各种解析器进行解析。webkit 使用Flex 和 Bison 解析器生成器，通过css 语法文件自动创建解析器。解析器将CSS文件解析成StyleSheet对象，且每个对象都包含CSS规则。CSS规则包含选择器和声明对象。

2.CSS 有自己的规则，一般如下：
WebKit 使用 Flex 和 Bison 解析器生成器，通过 CSS 语法文件自动创建解析器。Bison 会创建自下而上的移位归约解析器。Firefox 使用的是人工编写的自上而下的解析器。

这两种解析器都会将 CSS 文件解析成 StyleSheet 对象，且每个对象都包含 CSS 规则。CSS 规则对象则包含选择器和声明对象，以及其他与 CSS 语法对应的对象。

image.png

3.CSS 解析过程会按照 Rule，Declaration 来操作：

image.png

4.那么他是如何解析的呢，我们不妨打印一下 CSS Rules：

控制台输入：

document.styleSheets[0].cssRules

打印出来的结果大致分为几类：

• cssText：存储当前节点规则字符串
• parentRule：父节点的规则
• parentStyleSheet：包含 cssRules，ownerNode，rules 规则
• …

规则貌似有点看不懂，不用着急，我们接着往下看。

打印出来的结果大致分为几类：

5.CSS 解析和 Webkit 有什么关系？

image.png

CSS 依赖 WebCore 来解析，而 WebCore 又是 Webkit 非常重要的一个模块。

要了解 WebCore 是如何解析的，我们需要查看相关源码：

CSSRule* CSSParser::createStyleRule(CSSSelector* selector)  
{  
    CSSStyleRule* rule = 0;  
    if (selector) {  
        rule = new CSSStyleRule(styleElement);  
        m_parsedStyleObjects.append(rule);  
        rule->setSelector(sinkFloatingSelector(selector));  
        rule->setDeclaration(new CSSMutableStyleDeclaration(rule, parsedProperties, numParsedProperties));  
    }  
    clearProperties();  
    return rule;  
}

从该函数的实现可以很清楚的看到，解析器达到某条件需要创建一个 CSSStyleRule 的时候将调用该函数，该函数的功能是创建一个 CSSStyleRule，并将其添加已解析的样式对象列表 m_parsedStyleObjects 中去，这里的对象就是指的 Rule。

注意：源码是为了参考理解，不需要逐行阅读！

Webkit 使用了自动代码生成工具生成了相应的代码，也就是说词法分析和语法分析这部分代码是自动生成的，而 Webkit 中实现的 CallBack 函数就是在 CSSParser 中。

CSS 选择器执行顺序

渲染引擎解析 CSS 选择器时是从右往左解析，这是为什么呢？举个例子：

   

      
 111 
      
 222 
      
 333 
      
 444 
   

我们按照「从左到右」的方式进行分析：

1. 先找到所有 div 节点。
2. 在 div 节点内找到所有的子 div，并且是 class = “jartto”。
3. 然后再依次匹配 p span.yellow 等情况。
4. 遇到不匹配的情况，就必须回溯到一开始搜索的 div 或者 p 节点，然后去搜索下个节点，重复这样的过程。

这样的搜索过程对于一个只是匹配很少节点的选择器来说，效率是极低的，因为我们花费了大量的时间在回溯匹配不符合规则的节点。

我们按照「从右向左」的方式进行分析：

1. 首先就查找到 class=“yellow” 的 span 元素。
2. 接着检测父节点是否为 p 元素，如果不是则进入同级其他节点的遍历，如果是则继续匹配父节点满足 class=“jartto” 的 div 容器。
3. 这样就又减少了集合的元素，只有符合当前的子规则才会匹配再上一条子规则。

综上所述，我们可以得出结论：

浏览器 CSS 匹配核心算法的规则是以从右向左方式匹配节点的。

这样做是为了减少无效匹配次数，从而匹配快、性能更优。

所以，我们在书写 CSS Selector 时，从右向左的 Selector Term 匹配节点越少越好。

不同 CSS 解析器对 CSS Rules 解析速度差异也很大，感兴趣的童鞋可以看看 CSS 解析引擎，这里不再赘述。

参考文档：
https://segmentfault.com/a/1190000018759693
https://segmentfault.com/a/1190000021073560