对于性能来说重要的不好?

我恨他们,它无视CSS的级联性质,如果你不小心使用它们,最终会增加更多!important的循环。

但是我想知道他们对performance不好?

编辑
从(快速)答复我可以得出结论,它不会对性能产生(重大)影响。 但是很高兴知道这一点,即使这只是一个让人沮丧的额外论据)。

编辑2
BoltClock指出,如果有2个!important声明,说明会select最具体的声明。

真的不应该对性能有任何影响。 /source/layout/style/nsCSSDataBlock.cpp#572看到firefox的CSSparsing器,我认为这是相关的例程,处理CSS规则的覆盖

它似乎是一个简单的检查“重要”。

  if (aIsImportant) { if (!HasImportantBit(aPropID)) changed = PR_TRUE; SetImportantBit(aPropID); } else { // ... 

另外,在source/layout/style/nsCSSDataBlock.h#219处注释

  /** * Transfer the state for |aPropID| (which may be a shorthand) * from |aFromBlock| to this block. The property being transferred * is !important if |aIsImportant| is true, and should replace an * existing !important property regardless of its own importance * if |aOverrideImportant| is true. * * ... */ 

  1. Firefox使用手动编写的自顶向下的parsing器。 在这两种情况下,每个CSS文件都被分析成一个StyleSheet对象,每个对象都包含CSS规则。

  2. Firefox然后创build包含最终值的样式上下文树(在以正确顺序应用所有规则之后)

CSS解析器Firefox

来自:http://taligarsiel.com/Projects/howbrowserswork1.htm#CSS_parsing

现在,您可以很容易地看到,在上述对象模型的情况下,parsing器可以!important容易地标记!important的规则,而不需要太多的后续成本。 性能下降不是一个很好的反对!important论点。

然而,可维护性确实受到了打击(如其他答案所提到的),这可能是你唯一的反对他们的论点。

我认为这并不!important ,因为浏览器匹配规则的速度有多快(它不构成select器的一部分,只是声明的一部分)

但是,正如已经指出的那样,这会降低代码的可维护性,从而可能会导致它在未来的变化中不必要地增长。 !important的用法也可能会降低开发人员的性能。

如果你真的很挑剔,那么你也可以这么说!important是你的CSS文件增加了11个额外的字节,这并不是很多,但是我猜如果你的样式表中有一些!important的东西可以加起来。

只是我的想法,不幸的是我无法find任何基准!important可能会影响性能。

!important有它的地方。 请相信我。 它为我节省了很多时间,而且在find一个更长更优雅的方法之前,它通常会作为一个短期解决scheme更有用。

然而,就像大多数事情一样,它被滥用,但是没有必要担心“性能”。 我敢打赌,一个小小的1×1 GIF在网页上的performance更胜一筹!

如果你想优化你的页面,还有更多重要的路线可以采用;);)

好阅读:CSS!重要完整参考

这里幕后发生的事情是,当你的CSS正在被处理时,浏览器读取它,遇到一个!important属性,浏览器返回去应用!important定义的样式。 这个额外的过程似乎只是一小步额外的步骤,但如果你提出了很多要求,那么你将在性能上受到打击。 (资源)

在CSS中使用!important通常意味着开发者自恋,自私或懒惰。 尊重开发者来.​​..

开发人员在使用时的想法!important

  1. 我摇摆的CSS不工作… grrrr。
  2. 我现在应该怎么做??
  3. 然后!important是啊….现在它工作正常。

然而它不是一个好的方法来使用!important是因为我们没有很好地pipe理CSS。 它创造了很多devise问题 – 比性能问题更糟 – 但是它也迫使我们使用许多额外的代码行,因为我们用!important其他属性来覆盖其他属性,而且我们的CSS变得杂乱无章的代码。 我们应该做的就是先pipe理好CSS,不要让属性互相重叠。

我们可以使用!important 。 但是,只有在没有其他出路的时候,才会谨慎地使用它。

在这里输入图像描述

我同意你不使用它,因为不pipe性能如何,这是不好的做法。 单凭这些理由,我会尽可能避免使用!important

但是在performance的问题上:不,不应该引起注意。 它可能有一些效果,但它应该是如此之小,你不应该注意到,也不应该担心。

如果它足够显着,那么在代码中可能会遇到更大的问题,而不仅仅是!important 。 简单地使用你正在使用的核心语言的正常语法元素永远不会是一个性能问题。

作为回报,我要回答你的问题。 你可能没有考虑的angular度:你是指哪个浏览器?

每个浏览器显然都有自己的渲染引擎,并有自己的优化。 所以现在的问题是:每个浏览器的性能影响是什么? 也许!importantperformance在一个浏览器performance不好,但在另一个浏览器performance不错 也许在下一个版本中,这将是相反的方向?

我想我的观点是,我们作为Web开发人员不应该考虑(或需要考虑)我们正在使用的语言的单个语法结构的性能影响。 我们应该使用这些语法结构,因为它们是实现我们想要的而不是因为它们如何执行的正确方法。

性能问题应该与使用性能分析器一起分析,以分析系统中的夹点。 修复那些真正让你放慢脚步的事情。 几乎可以肯定的是,在深入到各个CSS结构的层面之前,需要解决的问题要远远大得多。

它不会显着影响性能。 但是,它会降低代码的可维护性,因此可能会长期降低性能。

以前不得不使用!important ,我个人注意到使用它时没有明显的性能问题。

作为一个注意事项,请参阅此堆栈问题的答案,因为您可能想要使用!important

另外我会提到其他人都没有提到的东西。 !important是唯一的方法来重写内联的CSS写短的JavaScript函数(这将影响你的performance,即使只有一点点)。 所以如果你需要重写内联的CSS,它实际上可以节省一些性能时间。

嗯…!重要的或重要的?

让我们一步一步来看看:

  1. parsing器必须检查每个属性的重要性,不pipe你是否使用它 – 所以这里的性能差异是0
  2. 当覆盖一个属性时,parsing器必须检查被覆盖的属性是否重要 – 因此这里的性能差异再次为0
  3. 如果被覆盖的属性是重要的,它必须覆盖属性 – 性能命中-1不使用重要
  4. 如果被覆盖的属性是重要的,它会跳过覆盖属性 – 性能提升+1使用!重要
  5. 如果新的属性是重要的,parsing必须覆盖它,不pipe被覆盖的属性是重要还是重要 – 性能差异再次

所以我猜!重要的是实际上有更好的性能,因为它可以帮助parsing器跳过许多不会跳过的属性。

并作为@ryan下面提到,唯一的方法来覆盖内联的CSS和避免使用JavaScript …所以另一种方法来避免不必要的性能打击

嗯…事实certificate,重要的是重要的

并且,

  • 使用!重要的是为开发人员节省了大量的时间
  • 有时可以避免重新devise整个CSS
  • 有时候HTML或父css文件不在你的控制之下,所以它可以节省你的生命
  • 显然可以防止重要元素被其他重要元素意外覆盖
  • 有时浏览器只是不select正确的属性,没有在select器中太具体,所以使用!重要真的变得非常重要,并且避免了在你的css中编写大量特定的cssselect器。 所以我猜即使你使用更多的字节来写!重要的是,它可以节省你在其他地方的字节。 我们都知道,CSSselect器可能会变得混乱。

所以我想使用!重要的可以使开发人员开心,我认为这是非常重要的 :D

我无法预见!important阻碍performance,而不是天生的。 但是,如果你的CSS充斥着!important ,那就表明你已经超过了资格select者,而且太过于具体,而你已经没有父母或者限定符来增加特殊性。 因此,你的CSS会变得臃肿(这妨碍性能)并且难以维护。

重要的CSS规则meme

如果你想编写高效的CSS,那么你需要像你需要的一样具体,写出模块化的CSS 。 build议不要使用ID(带有散列),链接select器或合格的select器。

在CSS中用#作为前缀的ID是恶意的,直到255个类不会覆盖一个id (fiddle by: @Faust )。 ID也有一个更深的路由问题,虽然他们必须是唯一的,这意味着你不能重复使用他们的重复样式,所以你最终编写重复样式的线性CSS。 这样做的后果将会改变项目的规模,取决于规模,但可维护性将遭受巨大的和边缘的情况下,性能也是如此。

你如何添加特性而不需要!important ,链接,资格或ID(即#

HTML

 <div class="eg1-foo"> <p class="eg1-bar">foobar</p> </div> <div id="eg2-foo"> <p id="eg2-bar">foobar</p> </div> <div class="eg3-foo"> <p class="eg3-foo">foobar</p> </div> 

CSS

 .eg1-foo { color: blue; } .eg1-bar { color: red; } [id='eg2-foo'] { color: blue; } [id='eg2-bar'] { color: red; } .eg3-foo { color: blue; } .eg3-foo.eg3-foo { color: red; } 

的jsfiddle

好的,那怎么办?

第一个和第二个例子的工作原理是相同的,第一个是字面上的类,第二个是属性select器。 类和属性select器具有相同的特征。 .eg1/2-bar不会从.eg1/2-fooinheritance它的颜色,因为它有自己的规则。

第三个例子看起来像排位赛或者链接select器,但是它们都不是。 链接是当你select父母,祖先等select器时, 这增加了特异性。 排位赛是类似的,但是你定义了select者所应用的元素。 符合条件: ul.class和链接: ul .class

我不确定你会怎么称呼这个技术,但是这个行为是有意的,并且被W3Clogging下来

同样的简单select的重复发生是允许的,并且增加特异性。

当两个规则之间的特异性相同时会发生什么?

正如@BoltClock所指出的那样 ,如果有多个重要的声明,则规范规定最具体的声明应该优先。

在下面的例子中, .foo.bar具有相同的特性,所以这种行为可以回归到CSS的级联特性,即CSS中声明的最后一个规则声明优先级,即.foo

HTML

 <div> <p class="foo bar">foobar</p> </div> 

CSS

 .bar { color: blue !important; } .foo { color: red !important; } 

的jsfiddle