Я ненавиджу їх, він протистоїть каскадному характеру CSS, і якщо ви не використовуєте їх обережно, ви опиняєтесь у циклі додавання більше !important.

Але я хочу знати, чи погані вони для продуктивності?

EDIT
З (швидких) відповідей я можу зробити висновок, що це не матиме (істотного) впливу на продуктивність. Але це приємно знати, навіть якщо це просто як додатковий аргумент для відлякування інших;).

EDIT 2
BoltClock зазначив, що якщо є 2 !importantдекларації, специфікація говорить, що вона вибере найбільш конкретну.

Це насправді не повинно впливати на виставу. Побачивши CSS-аналізатор Firefox у,/source/layout/style/nsCSSDataBlock.cpp#572 і я думаю, що це відповідна процедура, обробка перезаписів правил 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 використовує аналізатор згори вниз, написаний вручну. В обох випадках кожен CSS-файл аналізується на об’єкт StyleSheet, кожен об'єкт містить правила CSS.

2. Потім Firefox створює контекстні дерева стилів, які містять кінцеві значення (після застосування всіх правил у правильному порядку)

Від: http://taligarsiel.com/Projects/howbrowserswork1.htm#CSS_parsing

Тепер ви можете легко бачити, як, наприклад, описана вище об'єктна модель, аналізатор може легко позначати правила, на які впливає !important, без особливих подальших витрат. Зниження продуктивності не є гарним аргументом проти !important.

Однак ремонтопридатність дійсно вражає (як згадуються інші відповіді), що може бути вашим єдиним аргументом проти них.

Я не думаю, що !important це по суті погано з точки зору того, наскільки швидко браузер відповідає правилам (він не є частиною селектора, лише частиною декларації)

Однак, як уже було зазначено, це призведе до зменшення ремонтопридатності вашого коду, а отже, ймовірно, він спричинить непотрібне збільшення його розміру через майбутні зміни. Використання!important також, ймовірно, знизить продуктивність розробника.

Якщо ви були дуже вибагливі, ви також можете сказати, що !importantдодає 11 додаткових байтів у ваш CSS-файл, це насправді не так багато, але, мабуть, у вас досить мало!important у вашому таблицю стилів с, це може скластися.

Тільки мої думки, на жаль, я не зміг знайти жодних орієнтирів щодо того, як це !importantмогло б вплинути на продуктивність.

!importantмає своє місце. Повірте мені це. Це врятувало мене багато разів і часто є більш корисним як короткочасне рішення, перш ніж знайти більш довгий і елегантний метод вашої проблеми.

Однак, як і більшість речей, це зловживають, але не потрібно турбуватися про «продуктивність». Б'юсь об заклад, що один невеликий 1x1 GIF має більше показів продуктивності на веб-сторінці, ніж!

Якщо ви хочете оптимізувати свої сторінки, є ще багато важливих маршрутів;);)

Тут відбувається за лаштунками, що під час обробки вашого CSS браузер читає його, зустрічається з !importantатрибутом, і браузер повертається назад, щоб застосувати стилі, визначені !important. Цей додатковий процес може здатися невеликим додатковим кроком, але якщо ви подаєте багато запитів, тоді ви отримаєте хіт у виконанні. (Джерело)

Використання! Важливого у вашому CSS зазвичай означає, що нарцисистський розробник & егоїстичний чи ледачий. Поважай чортів, що прийшли ...

Мислення розробника при використанні !important:

1. Моя гойдалка CSS не працює ... grrrr.
2. Що мені робити зараз ??
3. І тоді !importantтак .... зараз це працює добре.

Однак це не дуже вдалий підхід для використання !importantлише тому, що ми не дуже добре керували CSS. Це створює безліч проблем із дизайном - які гірші, ніж проблеми з продуктивністю - але це також змушує нас використовувати багато зайвих рядків коду, оскільки ми перекриваємо інші властивості, !importantі наш CSS переповнюється непотрібним кодом. Що ми повинні зробити замість цього - спочатку дуже добре керувати CSS, і не дозволяти властивостям переважати один одного.

Ми можемо використовувати !important. Але використовуйте це економно і лише тоді, коли іншого виходу немає.

Я погоджуюся з вами щодо того, що не використовуєте його, оскільки це погана практика, незалежно від продуктивності. Тільки з цих причин я б уникав використання, !importantде це можливо.

Але щодо питання продуктивності: Ні, це не повинно бути помітно. Це може мати певний ефект, але воно повинно бути таким крихітним, що ви ніколи цього не помічаєте, а також не турбуєтесь про це.

Якщо це досить важливо, щоб бути помітним, то у вас, швидше за все, виникають більші проблеми в коді, ніж просто !important. Просте використання звичайного елемента синтаксису основних мов, якими ви користуєтесь, ніколи не стане проблемою продуктивності.

Дозвольте мені відповісти на ваше запитання натомість запитанням; кут, який ви, мабуть, не враховували: про який браузер ви маєте на увазі?

Кожен браузер, очевидно, має свій механізм візуалізації, з власними оптимізаціями. Отже, тепер стає питання: які наслідки для продуктивності у кожному браузері? Можливо, !importantв одному браузері працює погано, але в іншому добре? І, можливо, у наступних версіях це буде навпаки?

Думаю, моя думка тут полягає в тому, що ми, як веб-розробники, не повинні думати про (або не потрібно думати) про наслідки для продуктивності окремих синтаксичних конструкцій мов, якими ми користуємося. Ми повинні використовувати ці синтаксичні конструкції, оскільки вони є правильним способом досягти того, що ми хочемо робити, не через те, як вони виконують.

Питання щодо продуктивності потрібно задавати спільно з використанням профілів для аналізу того, де у вашій системі знаходяться чіткі точки. Виправте речі, які насправді сповільнюють спочатку. Існує майже певне, що вам доведеться вирішити набагато більші проблеми, перш ніж ви перейдете до рівня окремих CSS-конструкцій.

Це не помітно впливає на продуктивність. Однак це, однак, знижує ремонтопридатність вашого коду, а тому, ймовірно, знизить продуктивність у довгостроковій перспективі.

Якщо раніше довелося використовувати !importantкілька разів, я особисто не помітив жодного показового результату при використанні.

Як примітку, дивіться відповідь на це питання про стек з причини, яку ви хочете використовувати !important.

Також згадаю щось, про що не вдалося згадати всі інші. !importantце єдиний спосіб переосмислити вбудований css, якщо написати функцію javascript (що вплине на вашу ефективність, навіть якщо небагато). Таким чином, це фактично може заощадити певний час продуктивності, якщо вам потрібно перекрити вбудований css.

хм ... важливо чи !! важливо?

Пройдемо цей крок за кроком:

1. Парсер повинен перевірити важливість для кожного ресурсу, незалежно від того, використовуєте ви його чи ні - тому різниця в продуктивності тут дорівнює 0
2. Перезаписуючи властивість, аналізатор повинен перевірити, чи є переписане властивість! Важливим чи ні - тому різниця в продуктивності тут знову 0
3. Якщо властивість, що перезаписується, є важливою, вона повинна перезаписати властивість - показник продуктивності -1, оскільки не використовується!
4. Якщо властивість, що перезаписується, важлива, вона пропускає замість властивості - підвищення продуктивності +1 для використання! Важливо
5. Якщо нове властивість! Важливо, синтаксичний аналіз повинен перезаписати його незалежно від того, що властивість буде перезаписано! Важливо або !! важливо - різниця в продуктивності 0 знову

Тому я думаю, що важливе насправді має кращі показники роботи, оскільки це може допомогти парсеру пропустити багато властивостей, які в іншому випадку не буде пропущено.

і як згадує @ryan нижче, єдиний спосіб переосмислити вбудований css і уникати використання javascript ... тож ще один спосіб уникнути непотрібного хіта на продуктивність

хм ... виявляється, що! важливо важливо

і також,

• використання! важливо економить багато часу для розробника
• іноді рятує вас від перероблення цілого css
• іноді html або батьківський файл css не є вашим контролем, тому це рятує ваше життя там
• Очевидно, заважає! важливі елементи випадково переписати інші важливі елементи
• а іноді веб-переглядачі просто не вибирають потрібних властивостей, не будучи занадто специфічними у селекторах, тому використання! тому я думаю, навіть якщо ви використовуєте більше байтів для написання! важливо, це може зберегти вас байти в інших місцях. і всі ми знаємо, css селектори можуть стати безладним.

Тому я думаю, що використання! Важливого може зробити щасливих розробників, і я думаю, що це дуже важливо : D

Я не можу передбачити !importantперешкоджання продуктивності, як не властиво. Якщо, однак, ваш CSS пронизаний !important, це вказує на те, що ви перевищили кваліфікаційних селекторів і занадто конкретні, і вам не вистачає батьків або кваліфікованих працівників, щоб додати конкретність. Отже, ваш CSS стане роздутим (що буде перешкоджати продуктивності) і його важко підтримувати.

Якщо ви хочете , щоб написати ефективний CSS , то ви хочете бути тільки в якості конкретного , як ви повинні бути , і написати модульний CSS . Доцільно утримуватися від використання ідентифікаторів (з хешами), ланцюжкових селекторів або кваліфікованих селекторів.

Ідентифікатори з префіксом #у CSS є явно конкретними, до того моменту, коли 255 класи не замінять ідентифікатор (скрипка: @Faust ). У ідентифікаторів є проблема з більш глибокою маршрутизацією, вони повинні бути унікальними, це означає, що ви не можете повторно використовувати їх для дублювання стилів, тому ви в кінцевому підсумку пишете лінійний css з повторюваними стилями. Вплив на це буде залежати від проекту до проекту, залежно від масштабу, але ремонтопридатність дуже сильно постраждає, а в кращих випадках - і продуктивність.

Як можна додати специфіку без !important, ланцюжка, кваліфікації чи ідентифікаторів (а саме #)

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

Гаразд, так як це працює?

Перший і другий приклади працюють однаково, перший - це буквально клас, а другий - селектор атрибутів. Класи та селектори атрибутів мають однакову специфіку. .eg1/2-barне успадковує свій колір, .eg1/2-fooоскільки має своє правило.

Третій приклад виглядає як відбірний або ланцюговий вибір, але це не те. Скування - це коли ви встановлюєте префікси селекторів разом з батьками, предками тощо; це додає специфіки. Кваліфікація подібна, але ви визначаєте елемент, до якого застосовується селектор. кваліфікація: ul.classта ланцюжок:ul .class

Я не впевнений, як би ви назвали цю методику, але поведінка навмисна і це зафіксовано W3C

Допускаються неодноразові зустрічі того ж простого селектора і підвищують специфічність.

Що відбувається, коли специфіка між двома правилами однакова?

Як зазначає @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