[TOC] # 加载css * 加载是异步，不会影响DOM树的构建，只是说在CSS没处理好之前，构建好的DOM并不会显示出来 * 启发：所以CSS不能太大，页面一打开将会停留较长时间的白屏，所以把图片/字体等转成base64放到CSS里面是一种不太推荐的做法 * DOM去匹配css rule的时候必须先等页面的css都下载完成 * 启发：head中的css是要下载完的，body中放CSS的话，会重新计算 <br> # css语法：选择器 * 特点(css设计原则)：选择器的出现顺序，必定跟构建 DOM 树的顺序一致，即：保证选择器在 DOM 树构建到当前节点时，已经可以准确判断是否匹配，不需要后续节点信息 * 流式渲染，每生成一个dom节点，便立刻去匹配相应的css规则 * `空格`: 后代，选中它的子节点和所有子节点的后代节点 * `>` : 子代，选中它的子节点 * `+`：直接后继选择器，选中它的下一个相邻节点 * `~`：后继，选中它之后所有的相邻节点 * `||`：列，选中表格中的一列 <br> # cssom * CSSOM主要是DOM结构上的盒的描述，它基本上是依附于DOM树的，不要和css的语法树混淆 * cssom是有rule部分和view部分的，rule部分是在dom开始之前就构件完成的，而view部分是跟着dom同步构建的。 <br> # 处理脚本及样式表的顺序 ## 脚本 web的模式是同步的，开发者希望解析到一个script标签时立即解析执行脚本，并阻塞文档的解析直到脚本执行完。如果脚本是外引的，则网络必须先请求到这个资源——这个过程也是同步的，会阻塞文档的解析直到资源被请求到。这个模式保持了很多年，并且在html4及html5中都特别指定了。开发者可以将脚本标识为defer，以使其不阻塞文档解析，并在文档解析结束后执行。Html5增加了标记脚本为异步的选项，以使脚本的解析执行使用另一个线程。 <br> ## 预解析 Webkit和Firefox都做了这个优化，当执行脚本时，另一个线程解析剩下的文档，并加载后面需要通过网络加载的资源。这种方式可以使资源并行加载从而使整体速度更快。需要注意的是，预解析并不改变Dom树，它将这个工作留给主解析过程，自己只解析外部资源的引用，比如外部脚本、样式表及图片。 样式表（Style sheets） <br> 样式表采用另一种不同的模式。理论上，既然样式表不改变Dom树，也就没有必要停下文档的解析等待它们，然而，存在一个问题，脚本可能在文档的解析过程中请求样式信息，如果样式还没有加载和解析，脚本将得到错误的值，显然这将会导致很多问题，这看起来是个边缘情况，但确实很常见。Firefox在存在样式表还在加载和解析时阻塞所有的脚本，而Chrome只在当脚本试图访问某些可能被未加载的样式表所影响的特定的样式属性时才阻塞这些脚本。 <br> # 参考资料 [浏览器工作原理（五）：CSS解析（CSS parsing）](https://blog.csdn.net/lxcao/article/details/52861953) 重学前端