- 2019-02-14之前选择器是从右往左匹配，好像跟这里的说法不一致，是理解错了吗？ 67
2019-02-14css的渲染过程：
1. 流式渲染，每生成一个dom节点，便立刻去匹配相应的css规则
2. dom节点的生成顺序是 从父-> 子。 css的渲染顺序也是 从 父节点-》子节点
3.混合选择器 在激活的时候父元素已经确定好了 。 后代选择器，所有元素都是父元素，并 选中自己的子元素。 子元素 选择器，只有父元素为当前节点的 dom 元素会被选中。 在父元素 结束标签时，关闭 选择器。展开 18- 2019-02-14老师好，文中后代选择器是说先检查父级，匹配后再检查子级，以前学习看到比较多的一种说法是从关键选择器开始匹配，然后左移查找选择器的祖先元素，实践中也一直把最后一个选择器权重加高。请问这是从开始就学错了，还是我对两种说法理解有偏差呢？
作者回复: 浏览器编写本身有不同的思路，但是按关键选择器这个思路，据我所知还没有实现。
16 
2019-02-14dom树构建与cssom构建有先后关系吗？css计算与dom树流式构建同步进行是不是意味着dom树流式构建之前cssom已经构建完成呢？ 14
2019-02-16请问DOM去匹配css rule的时候是不是必须先等页面的css都下载完成后才会去匹配的？否则如果DOM匹配的时候对应的css还没下载完，后面怎么得到正确的css？作者回复: head中的css是要下载完的，body中放CSS的话，会重新计算。
2 8
2019-03-01老师，对于这个问题，我也有疑问：
dom树构建与cssom构建有先后关系吗？css计算与dom树流式构建同步进行是不是意味着dom树流式构建之前cssom已经构建完成呢？作者回复: 我这里说的确实有点歧义，cssom是有rule部分和view部分的，rule部分是在dom开始之前就构件完成的，而view部分是跟着dom同步构建的。
7
2019-02-14<也就是说，未来也不可能会出现“父元素选择器”这种东西，
因为父元素选择器要求根据当前节点的子节点，来判断当前节点是否被选中，而父节点会先于子节点构建。>
这句话后半句好难理解，有大神能通俗地解释一下吗作者回复: 意思是DOM树构造到父节点的时候，还不知道它有没有子节点，所以算不出来CSS。
7
2019-02-26CSS 没有父选择器那里讲得太好了，这个原因不能更合理作者回复: 其实Selector Level 4里面已经打破这个规则了，现在还是draft，也不知道最后能不能过。
要是真过了 webkit这块差不多得重写…… 5
2019-02-14第一反应猜测 CSS 语法应该解析成对象（Object），然后根据 DOM 的树形结构，CSS 也会生成自己的树形结构。
查找验证后发现，这被称为 CSSOM（CSS Object Model）。
举个 CSSOM 的例子：
body {font-size: 16px;}
h1 {font-size: 2rem;}
.orange {color: orange;}
div {margin: 1rem 0;}
div p {padding-bottom: 1rem;}
从根结点 body 开始，树形结构如下：
* body {font-size: 16px;}
* h1 {font-size: 2rem;}
* .orange {color: orange;}
* div {margin: 1rem 0;}
* div p {padding-bottom: 1rem;}
不知道这样理解是否准确？展开作者回复: 哈哈 CSSOM不是这样子的，CSSOM主要是DOM结构上的盒的描述，它基本上是依附于DOM树的。
你说的这个东西，比较接近的是CSS的语法树。 4
2019-03-07我发现关于CSS选择从右到左开始匹配的理论网上还是有很多相关资料的，https://www.sitepoint.com/optimizing-css-id-selectors-and-other-myths/
看起来应该还是有点道理？不过这个东西浏览器引擎应该也会不断优化，不同版本不同引擎都可能有差异 3
2019-03-13老师，请问一下您说的「后退，前进」的含义，不太理解
a#b .cls 这个选择器中，分成 a#b 和 .cls ，当 DOM 树构造到 <a id=b> 这个节点时，css 匹配 a#b，并且「前进」看是否自带是否有 class="cls" 的元素，这里可能会有指针这个抽象，指向 .cls，当 DOM 树构建到 </a> 这里时，css 选择器指针「后退」到 a#b 这里，然后继续构造 DOM 树，而且这个选择器已经被构造所谓的 css 树之类的，只是指针会有回退和前进的时候
可以这样理解吗展开 2
2019-02-20请问老师，有一点不是很明白，如果是在构建dom树的同时，就开始构建css，带空格选择子元素的时候，css怎么知道dom树有没有构建完成，是否有没有子元素，是怎么做匹配的？作者回复: 并不管有没有子元素，只是让这条规则前进一格。
2- 2019-02-16看到老师一个分享会的视频，说到DOM匹配css rule的时候是从右往左匹配的，为什么跟文章提到的后代选择器的匹配顺序相反呢？
作者回复: 哈哈，是这样的没错，但是你看，新加了这么多运算符，所以思路也会有不一样。
其实浏览器实现是比较懒的，直接每条规则都检查了，没做合并优化。 2 
2019-06-19空格，和后代选择器有什么不一样吗？ 1 1
2019-02-22|| 列选择器 是最新的标准出的吗？ 我在w3school和 菜鸟教程 都找不到这个选择器作者回复: Selector Level 3里的，不过不太重要，不用太在意。
1
2019-09-04css选择器这里面最重要的一条规则就是没有父选择器，根据流式处理的dom规则，这样就节省了很多的重新计算
2019-05-30老师，DOM 和 CSSOM 都是流式构建的，按照您的讲解，我理解是 CSSOM 必须先解析好，才能和 DOM 做样式上的融合，然后流式绘制已经解析好的 DOM，单纯HTML的解析我认为时间是可以忽略不计的，遇到 script 标签才会导致 DOM 解析有停顿，这时候页面才会做渲染，所以我理解上的流式渲染是分批的，遇到 js 就立即渲染之前融合好的布局，不知道这样理解流式渲染是否正确？
还望老师指正，谢谢。作者回复: 不是分批的，也跟JS无关。
2019-05-08处理后退的情况那里没太理解，当找到匹配了a#b的元素才开始检查它的所有子代是否匹配.cls。那第三个span节点不是a#b元素的子节点，它本身就不会被选中的。为什么文中提到“必须使得规则a#b .cls回退一步，这样第三个span才不会被选中”
2019-05-08我还是比较认同，从左往右匹配的规则，这样就像老师讲的可以在构建dom树的同时来进行匹配css规则，相当于同时构建渲染树了，而不必等到dom构建完毕在进行css的规则匹配，进行构建渲染树，虽然从右向左匹配对于复杂的选择器更优，但是这里面浪费了等待dom构建完毕才能使用的css匹配规则。而且相对于同为id等单一选择器而言，明显从左向右更具有优势！这是我的一点想法，望老师指正！
2019-05-07程老师你好。我在很多地方看到的说法是：CSS会阻塞dom渲染，但不会阻塞dom的解析，且CSS文件的请求是异步请求。
那么如果按照上面文章中所说，DOM的构建和CSS属性的计算是同步的话，head中CSS文件的下载以及CSSOM的rule部分的构建应该会阻塞HTML的解析和DOM的构建。
好像这两种说法之间就有了冲突。。麻烦程老师有空的时候可以帮忙解释一下，万分感谢～