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

生活中,最使人疲惫的往往不是道路的遥远,而是心中的郁闷;最使人痛苦的往往不是生活的不幸,而是希望的破灭;最使人颓废的往往不是前途的坎坷,而是自信的丧失;最使人绝望的往往不是挫折的打击,而是心灵的死亡。所以我们要有自己的梦想,让梦想的星光指引着我们走出落漠,走出惆怅,带着我们走进自己的理想。

导读:本篇文章讲解 「三」浏览器中CSS 语法解析过程,希望对大家有帮助,欢迎收藏,转发!站点地址:www.bmabk.com,来源:原文

CSS 语法解析过程

1.在浏览器系列文章中,今天终点讲下CSS解析这块内容.我们已知浏览器的渲染流程中HTML Parser会生成 DOM树,而 CSS Parser会将解析结果附加到 DOM 树上,如下图:
在这里插入图片描述解析分为词法分析 和 语法分析。
在这里插入图片描述词法分析,也是编译原理中的术语,从左到右一个字符一个字符的读入源程序,对字符流进行扫描,根据构词规则识别单词。这一过程可以使用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 语法对应的对象。

在这里插入图片描述3.CSS 解析过程会按照 Rule,Declaration 来操作:
在这里插入图片描述4.那么他是如何解析的呢,我们不妨打印一下 CSS Rules:

控制台输入:

document.styleSheets[0].cssRules

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

1.cssText:存储当前节点规则字符串
2.parentRule:父节点的规则
3.parentStyleSheet:包含 cssRules,ownerNode,rules 规则
…

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

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

5.CSS 解析和 Webkit 有什么关系?
在这里插入图片描述

	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 选择器时是从右往左解析,这是为什么呢?举个例子:

<div>
   <div class="jartto">
      <p><span> 111 </span></p>
      <p><span> 222 </span></p>
      <p><span> 333 </span></p>
      <p><span class='yellow'> 444 </span></p>
   </div>
</div>

<style>
  div > div.jartto p span.yellow {
   color: yellow;
  }
</style>

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

先找到所有 div 节点。
在 div 节点内找到所有的子 div,并且是 class = “jartto”。
然后再依次匹配 p span.yellow 等情况。
遇到不匹配的情况,就必须回溯到一开始搜索的 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

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/137397.html

(0)
飞熊的头像飞熊bm

相关推荐

发表回复

登录后才能评论
极客之音——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!