但是,如果“样式表中的任何位置都遇到任何兄弟选择器…”,则该优化将完全关闭整个页面.这包括选择器和选择器,如：first-child和：last-child.
有没有人知道选择器类型的完整列表禁用此优化？
–
更多信息
>在Tali Garsiel关于浏览器内部结构的研究中讨论了优化：How Browsers Work.
>以下是Dave Hyatt的兄弟选择器的完整报价,他显然撰写了浏览器代码：“根本没有兄弟选择器,当遇到任何兄弟选择器时,WebCore只会抛出一个全局开关,并禁用整个文档的样式共享当他们在场时,这包括选择器和选择器,如：first-child和：last-child.
这个引文似乎来自于Hyatt在2005年写的一篇文章.下面他将更详细地讨论这个内容(与以前一样的来源)：“WebCore(即将到来的Safari版本)有一个非常酷的优化,我想出了避免甚至计算适用于元素的声明集,实际上这种优化甚至不需要匹配页面上大约60％的元素的样式.优化背后的想法是识别页面中的两个元素是通过DOM(和其他状态)检查具有相同的风格,并尽可能简单地分享这两个元素之间的前端样式信息.
>这个article by Nate Koechley更详细地讨论了算法.他总结说：“在网络开发中,通常有6种不同的相似方式来做同样的事情,一个好的网页开发人员是不断选择几乎无法区分的最佳路径,这些来自凯悦的内部提示给我们一个更完整的了解浏览器的内容,并帮助我们选择最佳方法.“
>凯悦还讨论了这个W3C mailing list archive的优化
>它也在Stack chat从Ryan Kinal简单地出来：“哇,只是哇,我永远不会再使用另一个兄弟选择.
我特别有兴趣知道：
解决方法
WebKit处理样式更新
属性更改
如果该元素尚未标记样式recalc,并且如果该属性是id属性,或者存在涉及该属性的选择器,那么该元素将被标记为一个样式重新计算.没有试图仔细检查这些选择器是否与元素有任何关系,也没有尝试处理涉及“〜”和“”的情况.当类属性更改时,还有一个单独的钩子,除了其他事情之外,无条件地将元素标记为需要样式重新计算.再次,没有尝试处理’〜’和”.在这些情况下,没有一个尝试优化后代的选择器匹配.
状态变化
WebKit中的状态更改没有统一的设置.对于通过Gecko中的布尔状态处理的每个伪类,选择器匹配具有专用函数,它可以调用该元素来测试该伪类是否匹配.元素内的状态的更改负责直接将该元素标记为需要样式重新计算.再次,没有尝试优化对后代的选择器匹配或处理“或”〜“.这里有一些类似于Gecko所做的优化：hover覆盖：hover,：active和关于拖动的东西.
处理插入和删除
RenderStyle有标志,表明它的孩子是否受到各种结构伪类和’或’〜’组合者的影响.在DOM突变上,变更后的第一个受影响的元素(子列表顺序)被标记为需要一个样式重新计算,或者如果可能需要重新计算,则该父元素的第一个子代.如果更改之前的更多事情可能需要重新计算,那么父级会被标记为需要重新计算样式,这将重新计算所有的孩子.
在所有这些情况下,当在元素上实际重新计算样式时,检查它的孩子是否受“或”〜“的影响.如果是这样,那么如果任何一个孩子被标记为需要的样式,则重新计算孩子或其后的所有孩子(取决于是否涉及“〜”)也被标记为需要的风格重新计算.我认为这里有一些错误链在多个链“.
结果是,在某些情况下,WebKit最终会比Gecko更多的元素重新计算样式,据我所知,但在其他情况下,最终可以在更少的元素上重新计算样式.例如,给定一个像“.foo〜span”这样的选择器和一个将类从“foo”改为“bar”的div,Gecko将会恢复所有后来的div的兄弟姐妹,如果有的话,WebKit根本不会做任何工作没有“跨”的孩子,因为在这种情况下,它永远不会标示父母受到“影响”.我不知道这在多大程度上影响插入行为,似乎两者应该更相似.不知何故,WebKit在HTML5单页规范脚本上似乎比Gecko做得更好,我不知道为什么在这一点上.也许这只是因为它的风格重新计算似乎比Gecko的实际运行便宜得多.
另一个结论是,个人属性和状态变化所涉及的工作远远少于壁虎,而不是花费更多的风格重新计算. DOM插入/删除中涉及的工作大致相同.
