【发布时间】:2012-08-04 04:24:38
【问题描述】:
这是一个长镜头,但是否有可用的工具通过删除不需要的特异性来优化 CSS 选择器?
我发现当我写 CSS 时,我故意让我的选择器比必要的更具体,以避免冲突和准文档。
如果有一种工具可以分析给定的一组规则,确定它们与其他规则重叠的“唯一性”,然后去除任何不必要的特殊性,那就太好了。
我什至无法想象工具开发人员会如何处理这需要的所有场景,但我之前曾被其他人在该领域的独创性所震撼,并认为值得一问。
更新:
我在这个问题上加了一个赏金,我越想它,我就越意识到 CSS 特异性过滤器 的价值。
例如,在Sass 和LESS 中使用嵌套规则/选择器时,过度嵌套 是common 和well-known 反模式,很容易导致选择器过于具体。
在优秀的 TutsPlus 课程Maintainable CSS with Sass and Compass中有一个很好的说明:
body {
div.container {
p {
a {
color: purple;
}
}
}
}
Sass 将遵循这些嵌套指令并生成以下 CSS 输出,不会对任何不必要的特殊性提出异议:
body div.container p a {
color: purple;
}
但是,如果存在/确实存在特异性过滤器,它将为 CSS 开发人员带来潜在的好处:
您可以将样式表组织为 DOM 的 1:1 映射,类似于您在 Firebug 和 Chrome 开发工具中检查样式规则时看到的内容。智能编辑器/IDE 可以为具有共享样式/类的 DOM 元素自动填充样式。当然,这种冗余会被特异性过滤器/优化器过滤掉。
样式表的结构可以由扫描 DOM 并将其转换为 CSS 选择器/规则的工具预先填充。这意味着开发人员只需要更新 HTML; CSS“树”将保持同步以反映 DOM 的当前状态。智能编辑器可以让您跳转到元素/类的 CSS 定义以进行样式设置——甚至可以在单独的面板中显示其样式规则。
在某种程度上,这似乎是一种倒退——就像您在 Dreamweaver 或 WebAssist 中发现的帮助新手学习 CSS 的功能一样。但是 CSS 选择器优化工具的基本思想似乎很简单,我所描述的工作流自动化类型将是合乎逻辑的下一步——催化剂将是特异性过滤器。
我研究了一些更知名的 CSS 编辑器和 Web IDE,但除了定位单个元素并为其生成选择器之外,没有发现任何提供此类功能的东西。
更新 2:CSS 选择器性能
针对 Spliff 的评论,这里有两篇关于 CSS 选择器性能的精彩文章:
Efficiently Rendering CSS by Chris Coyier
两者都同意微优化 CSS 不值得努力,但过度限定的后代选择器是“效率灾难”。我自己还没有进行基准测试,但我怀疑我建议的那种“DOM 映射”方法会在没有手动或自动优化步骤的情况下导致性能下降。
相关问题、链接和工具:
【问题讨论】:
-
当然,这样的工具需要检查 DOM 或页面以作为样式表的基础并做出正确的观察/假设(例如,是否只有一个带有 @ 的
header元素987654341@?aside元素是否只会出现在section.sidebar?) 中。否则,在不从根本上改变选择器含义的情况下,从选择器中去除特异性的唯一方法是删除重复的简单选择器,(例如,section > div.foo.foo:nth-of-type(odd)变为section > div.foo:nth-of-type(odd))。 -
@BoltClock:另外,如果遇到 ID,通常可以安全地消除它之前的任何内容。
html body div p#lorem span通常可以缩写为#lorem span -
老实说,除了遵循一些简单的规则(不要将元素添加到 id/class 选择器中,不要对嵌套感到疯狂等),我认为这不值得担心关于。这几天browser vendors are optimizing for this。
-
这就是为什么我一开始不使用预处理器...
-
@Truth 它也不一定适用于动态生成的 HTML。在这种情况下,实际元素和嵌套可能取决于上下文,并且您可能只想将样式应用于该 ID,如果它在该特定上下文中遇到(它周围的元素)。但问题本身也有同样的问题。具有生成 HTML(无论是服务器端还是客户端)的高度动态页面将难以编写可靠工作的过滤器。
标签: css css-selectors sass less css-specificity