4

所以我正在构建一组 JavaScript (jQuery) 小部件，我想确保这些小部件的所有元素都在使用box-sizing: border-box（是的，我知道这意味着我只能支持 8 或更高版本的 IE 版本我很好）。

现在我听说做 a[selector] > *很慢，但到底有多慢？

我的意思是对于其中一个小部件，我有这个选择器来确保所有元素都具有正确的框大小：

.jg-grid-wrap,
.jg-grid-content-outer-wrap,
.jg-grid-colum-actions a,
.jg-grid-content-wrap,
.jg-grid-wrap .hide,
.jg-grid-wrap ul,
.jg-grid-wrap ul li,
.jg-grid-header-wrap,
.jg-grid-header-wrap li,
.jg-grid-header-wrap .sort-indicator,
.jg-grid-row,
.jg-grid-row li,
.jg-grid-footer-wrap,
.jg-grid-footer-wrap .column-selection
.jg-grid-wrap .controls,
.jg-grid-wrap .controls .first-page-link,
.jg-grid-wrap .controls .previous-page-link,
.jg-grid-wrap .controls .next-page-link,
.jg-grid-wrap .controls .last-page-link,
.jg-grid-wrap .controls .column-selection-link,
.jg-grid-wrap .controls .set-page-link,
.jg-grid-wrap .controls .total-page-count,
.jg-grid-wrap .controls .record-counts,
.jg-grid-wrap .controls .record-display-text
{
    box-sizing: border-box;
}

但是写起来会更小更容易：

.jg-grid-wrap *
{
    box-sizing: border-box;
}

另外，如果我添加一个元素，我现在必须记住将它添加到带有星号的巨大选择器中，我不必担心它。

真的值得我花时间单独列出每个可能的元素，因为[selector] > *它真的那么慢吗？

更新

最后，我将继续：

[class^=jg-] *
{
    box-sizing: border-box;
}

基于谷歌浏览器，这个选择器有大约 14% 的总 4 毫秒。其他的稍微小一点（~4%），但是考虑一下，CSS 将是我可能需要担心性能的最后一个地方（我的 javascript 和服务器端代码将成为瓶颈的主要部分）。如果我真的需要优化我的 CSS chrome 分析器，我需要它时就在那里。

4

2 回答 2

6

如果你真的想要标记有该类的容器下的所有元素，你会想要

.jg-grid-wrap *

运算符将>匹配限制为直接子级。

性能影响源于这样一个事实，即当以相关方式更新布局时，必须测试每个元素。您可以通过以下方式使它变得更好：

.jg-grid-wrap div, .jg-grid-wrap form, .jg-grid-wrap ul

等等，以及您真正关心的任何块级元素。（也就是说，你真的关心你的<span>标签是否有“box-sizing”属性吗？）

Chrome 的 CSS 分析器对于查找昂贵的 CSS 规则非常有帮助。这应该是您在过分担心之前进行经验调查的事情；现代 CSS 引擎非常快。

于 2012-06-09T13:35:49.853 回答
1

当页面被（重新）绘制时，浏览器从右到左评估 CSS：

.jg-grid-wrap > *

这基本上会首先匹配页面上的所有元素；然后它检查所有元素的直接祖先并比较类。

听起来很糟糕，但情况可能更糟：

.jg-grid-wrap *

对于它下面的元素.jg-grid-wrap来说还不错，但是其他元素会导致浏览器一直遍历元素树html以找到祖先。

其中一些逻辑可以进行一些优化，但最好避免它。因此，诀窍是使 CSS 规则的最右侧部分尽可能具体。

所以我的结论是：不要管代码，人眼看来最佳的东西对于糟糕的浏览器可能是灾难性的:)

于 2012-06-09T13:58:07.107 回答