Так когда же всё таки можно использовать !important?

Любая фича в «кривых» руках становится плохой. Импортант —  не исключение. Плохо не то, что он умеет, а то, как его используют.

Анимированное изображение на котором Маллой добавляет яд в блюдо

Как работает !important


В CSS для определения приоритета стилей мы пользуемся механизмом специфичности. Мы пишем каскады или сложные селекторы, повышаем вес селектора, таким образом указываем браузеру приоритетность одних стилей над другими.

Например:

.content .title {
    color: red;
}

.title {
    color: blue;
}

В этом случае, несмотря на то, что синий цвет применяется к заголовку после красного, в результате мы получим все же красный заголовок. Потому, что первый селектор является более специфичным (если вдруг вы с этим не знакомы, не читайте дальше  —  будет только хуже, лучше вот сюда и учите специфичность).

Так вот, используя этот же пример, но с !important, мы вдруг узнаём, что ему «плевать» на вашу специфичность.

.content .title {
    color: red;
}

.title {
    color: blue !important;
}

Заголовок будет синим! Это свойство нарушает естественный поток написанных нами правил и менее приоритетным стилям даёт наибольший приоритет.

Ну хотя, как «плевать»… Не совсем уж и плевать. Допишем ещё один импортант.

.content .title {
    color: red !important;
}

.title {
    color: blue !important;
}

И заголовок снова красный. Потому что у нас конфликтуют два !important и решается этот конфликт сравнением весов селекторов.

Импортант —  это плохо, когда так:

.title {
    color: red;
}

«Хм, я же написал “красный”, почему мой заголовок не красный? А если так?»

.title {
    color: red !important;
}

«Отлично! Красный!» А точно ли отлично?

Такой подход плох как минимум потому, что вы переопределяете стили не разобравшись, почему они не применялись без импортанта. Скорее всего, вес селектора, которым вы воспользовались, оказался просто недостаточным и, написав чуть более точный и «тяжелый» селектор, вы бы решили свою проблему, а так вы жестко переопределили стили, и хорошо, если вы знаете и проверили все места, где использовался этот класс, но если это не так, то вы подчинили элемент в одном месте и, вероятно, сломали в другом.

Инструмент для hotfix


Очень часто, когда я задаю кому-то вопрос про импортанты, я слышу ответ в стиле: «Я использую important тогда, когда мне нужно быстро пофиксить проблему и некогда разбираться в коде, который писал не я и который написан очень плохо».

Да, но только задачи всегда «срочные», такие задачи, как правило, никто и никогда не доделает, так это и оставив. Вы и сами не заметили, как сделали «плохой чужой код» ещё хуже.

Что значит «быстро»? Разве узнать необходимый вес селектора для переопределения так сложно и долго? Мы очень активно используем DevTools при разработке, и для решения этой задачи ответ у нас есть там же.

Инспектируем элемент, который хотим изменить. Его текущий цвет — черный. Смотрим, по какому же селектору был назначен этот цвет?

Скриншот веб-инспектора с примером инспектирования цвета у элемента

Используем этот же селектор для назначения нового цвета или для повышения веса, и дело в шляпе, какой бы сложности не был этот селектор.

Скриншот веб-инспектора с примером инспектирования цвета у элемента

Разве это долго? Мне кажется, по времени это мало отличается от того, чтобы дописать !important, однако намного правильнее и безопаснее.

Сторонние решения и чужой код


Второй по популярности ответ на вопрос про необходимость использования импортантов: «Я использую !important, когда переопределяю стили сторонних библиотек и плагинов или CMS-ок».

Этот ответ чуть ближе к правде, но только если его чуть более точно сформулировать. Именно в такой форме он неправильный, потому как стили сторонних файлов можно перезаписывать точно так же, как и свои, просто дописывая их после подключения чужих стилей и повышая вес селектора.

Однако в некоторых случаях этот ответ «попадает» в вопрос. Например, если вы подключили слайдер к своей странице, который реализован так, что при переключении слайда JavaScript-ом перезаписываются значения некоторых свойств в CSS.

Скриншот веб-инспетора с динамическим изменением стилей у элемента

А вам почему-то надо переопределить эти свойства, проигнорировав изменения самого плагина.

JS может переназначать значения свойств только с помощью inline-стилей. То есть фактически любые свойства, изменённые у элемента с помощью JavaScript, будут просто записаны в атрибут style. С точки зрения механизма специфичности, эти стили более приоритетные, и как бы вы ни повышали вес селектора, вы не сможете перезаписать их.

Это именно тот первый случай, в котором нам просто не обойтись без important.
Если нам нужно переопределить инлайновые стили, то нам поможет только important.
Приоритетность стилей с импортантом выше, чем приоритетность инлайн-стилей, и если у вас почему-то появилась необходимость перезаписывать инлайновые стили, то у вас нет вариантов, кроме как использовать !important.

Important во благо


Рассмотрим ещё один случай, который иногда применяют в коде различных библиотек и плагинов.

Если вы откроете исходный CSS-код библиотеки Bootstrap, то увидите, что там разработчики библиотеки очень часто прибегают к использованию импортантов. Возможно, им тоже просто нужно было быстро пофиксить, и они так поступили (сарказм), но вообще этому есть более подходящее объяснение. В этом случае important-ы используются «во благо». Таким образом разработчики Bootstrap «защищают» свой код.

Дело в том, что вы, подключая к своему сайту эту библиотеку, можете переопределять её исходные стили. Таким образом, разработчики перестраховались, и сломать поведение их кода будет сложнее, если вы не знаете, как работает специфичность. Но если вы понимаете, как работает механизм специфичности в CSS, то можете переопределить их импортант, записав свои стили тоже с импортантом, но с более «тяжелым» селектором.

Тем самым мы приходим к второму случаю, когда без импортанта нельзя.
Если вам нужно переопределить important (ваш или из сторонней библиотеки), то вам поможет только !important.

Именно поэтому некорректно говорить: «Я использую импортанты, когда мне нужно переопределить стили сторонних библиотек», правильнее будет сказать: «Я использую импортанты, когда мне нужно переопределить inline-стили или другие !important». И совсем не важно откуда эти стили: из ваших файлов или из сторонних.

Хелперы


В предыдущем абзаце, по сути, описаны все случаи, когда использование импортантов будет нормальным и правильным. Это те случаи, в которых применение импортантов будет неизбежным. Но существуют ещё случаи, в которых использование импортантов будет допустимым, хоть, возможно, уже и не совсем уместным.

Иногда нам необходимы вспомогательные универсальные классы, которые мы используем в своём коде с целью повторного использования кода и некоторого упрощения.
Например, мы создаём какой-то класс .warning, который будем применять к различным элементам на странице, тем самым обозначая их важность.

.warning {
     color: red;
}

И мы хотим, чтобы, применяя этот класс к любому элементу, мы точно делали текст в этом элементе красным. Но ведь у элемента могут быть более приоритетные стили, записанные по более точному селектору, и тогда наш цвет из класса .warning перетрется. В таком случае, добавив important в наш классхелпер, мы делаем его более универсальным, потому что цвет, применяемый в этом классе, будет более приоритетным. Однако сказать, что это хорошо, я не могу. Ведь это делает стили класса более приоритетными, но все равно не гарантирует вам стопроцентной работы, поскольку этот хелпер может столкнуться с другим important, и все равно всё пойдёт не по плану. А потом, когда окажется, что все же в определенном случае этот класс должен делать текст «не таким уж и красным», то вы сразу же «родите» новый селектор с повторением импортанта.

Когда всё таки можно


Правильно и нормально использовать !important, когда вам нужно переопределить inline-стили или другие !important.

Если следовать этому правилу, то выходит, что в обычной верстке, особенно если вы верстаете страницу с нуля, у вас не возникает необходимости использовать импортант вплоть до того момента, пока вы не начинаете подключать сторонние решения к своей странице, но даже это, как мы разобрались выше, не обязательно приводит к их использованию.

Современные методологии вроде БЭМ тоже диктуют свои правила, в которых использование инлайновых стилей или импортантов будет неуместным.

Импортант вам не нужен не потому, что он какой-то загадочный и ужасный, а просто потому, что в большинстве случаев можно обойтись без него.

Все исключения, которые я определил для себя, как правило, сводятся к не очень типичным случаям. Например, у вас может появиться необходимость использовать это, когда вы разрабатываете собственную библиотеку, плагин или браузерное расширение и вам нужно какое-то более приоритетное поведение конкретных стилей. Однако это далеко не про типичное регулярное использование.
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 72

    0
    Я не web-разработчик и вёрстку знаю постольку поскольку, но…
    Секция «Important во благо» выглядит как искусственное решение искусственно созданной проблемы
      0
      Да, так и есть. Разработчики либ добавляют импортанты к некоторым своим стилям не потому, что не знают как писать без импортантов, а чтобы не дать сломать свой код новичкам, ну или тем кто не понимает как это работает. Защита такая себе. И это больше похоже на защиту от дурака, но раз используют, значит всё таки помогает)
        +2
        Есть и другой момент — «конечным» разработчикам бывает виднее, чем разработчикам либ, какой стиль они хотят получить в своём проекте. Как по мне, бездумно увлекаться !important не стоит, но тупо переопределить библиотечный стиль через !important вместо игры с селекторами — это абсолютно нормальная практика, если вам нужно не какое-то частное правило для одного элемента, а именно изменить библиотечный стиль глобально для своего проекта.
          0
          Опять же, в этом случае important нужен, только чтобы переопределить импортанты в этой либе. Если их там нет, то в этом нет необходимости. Особенно если стили надо переопределить глобально.
            0
            … и получить important во всех локальных?
            Имо, правильное решение выкинуть его из библиотеки
              0
              Если бы всё так легко решалось) Ты предлагаешь переписать bootstrap?)
                +1
                не обязательно переписывать. для многих проектов, особенно маленьких, достаточно выдернуть из всей библиотеки нужный кусок и вуаля. Зачем грузить целую либу ради одной модалки или навигации, в которой потом придется переопределять стили… жесть)
                  0

                  Так это уже совсем другая ситуация. Даже если ты подключил весь бутстрап, но не используешь те компоненты в которых импортанты, то тебе не придётся их переопределять)

                  +1
                  Я предлагаю решить искусственно созданную проблему с гибкостью. А переписывать для этого библиотеку или нет — это уже проблемы веб-разработчиков. (вообще, заметил за многими авторами библиотек манию запрещать модификацию поведения, вплоть до превращения хорошей библиотеки в бесполезную)
                    0
                    Плюсую. Я наблюдал плагины с инлайновыми стилями с !important. И проблемами в отображении.
            0

            Несколько лет назад Гарри Робертс предлагал использовать !important для гарантии неизменяемости для служебных классов, этакий аналог const для CSS.

              0
              классический пример в том же бутстрапе класс .d-none {display:none !important;} сделано для того чтобы однозначно скрыть элемент, ведь на том же элементе могут быть заданы другие display с более высоким приоритетом, например, .dropdown-menu.show { display: bock;} (пример высосан из пальца, но тем не менее)
                0
                Да, я это и имел в виду, когда описывал то как использует это бутстрап. Но именно по-этому я называл это «защитой от дурака», так как чисто по такому же совпадению разработчик может почему-то написать: .dropdown-menu.show { display: bock !important;}

                И будет всё равно печаль.

                Так, что этот способ существует, но сказать что он хороший или надежный — я бы не сказал.
                  0
                  если в этом случае не использовать !important, то придется писать display:none для всех вариантов, например в моем же примере придется прописать след правила .dropdown-menu.show.d-none { display: none;} ну и кучу кучу других
              +1
              Вы попробуйте написать плагин для вордпресс и потом погоняйте его на разных вордпресс темах — вы увидите что всё поехало вкривь и вкось. Потому как автор темы посчитал что изображение обязательно быть круглым, ссылка такой то. Не говорю про input-ы и кнопки (button)
              Если вы этот плагин будете отдавать в массы — то вам придется решать эти не искусственно созданные проблемы. Потому как ваш плагин будет работать с сторонними плагинами и кучей сторонних тем. А там такой зоопарк.

              И это не камень в сторону вордпресс — любая система которая имеет плагины и темы и массового пользователя, который бесплатно их получает и ставит в самых разных наборах и вариациях.

              Я писал об этой проблеме и способах решения: «Верстка под контент выводимый плагином или дополнением в вордпресс» — картинка оттуда yadi.sk/i/l-If2cwF3K3txW

              Ну и как вам? Надуманные проблемы или все же из жизни?
                0
                Да, в случае с плагинами и расширениями это оправданная мера. Не стопроцентная безопасность, но хоть что-то.
              +5
              Моя мечта — important второго уровня. Чтобы можно было перекрыть все «обычные» important
                0
                Я боюсь в таком случае образования черной дыры, прям в браузере)
                  +1
                  Просто иногда в библиотеках устанавливается important, и его никак не перебить, а код библиотеки править не хочется. Только с селекторами играться, чтобы приоритет повысить.
                    0
                    Код библиотеки править — точно плохая идея. А вот с селекторами играться, вполне здоровое решение, так как вот этот «импортант второго уровня» скорее всего сделает всё ещё хуже и ещё больше запутает.

                    Ну и как правило, не так уж и много в этих библиотеках приходится перебивать импортантов, а значит не так много селекторов.

                    А вообще, иногда стоит задуматься, точно ли надо перебивать эти импортанты в сторонней библиотеке.
                  0

                  Два-три уровня из 8 описанных в стандарте заюзать можно:)

                  0
                  1. Никогда не понимал чем плох important. Если вы стреляете себе в ногу, то это ваши проблемы.

                  2. > Это свойство нарушает естественный поток написанных нами правил и менее приоритетным стилям даёт наибольший приоритет
                  Нет. important просто повышает приоритет правила. И нет никакого «естественного потока», есть вполне логичные приоритеты селекторов, зная которые перестаешь бить себе по пальцам.
                    0
                    Important просто повышает приоритет правила… До наибольшего приоритета. И автор не говорит о том что important плох, а о том что каждому инструменту своя ситуация. Микроскопом тоже можно гвозди забивать.
                      0

                      Емнип, не до максимума, а даёт +1000 к приоритету.


                      То есть если к какому-то блоку применяется два взаимоисключающих правила с приоритетами 1 и 5 (то есть применится второе, первое будет затёрто), и если у каждого написать !important, то результат не изменится, а приоритеты будут 1001 и 1005, соответственно. Но если написать этот модификатор только к первому правилу, то таки-да, будет применено оно, ибо 1001 > 5.

                        +1
                        Это задокументированное поведение? Почему +1000, а не +10? =) Логично что при одинаковом весе, в данном случае оба имеют импортант, далее будут сравниваться менее приоритетные правила, пока мы не дойдем до того момента кто был раньше определен. Но +1000 это какая то ваша выдумка, не сочтите за оскорбление.
                          +1

                          Это слышанное однажды краем уха со слов старшего товарища. :)


                          Дальше внизу там обсуждение, которое мне действительно пролило свет на некоторые моменты, происходящие в царстве css'а. Например, этот комментарий про 1.0.0.0.0 и эта статья про 256 классов и id. Мне ещё многому предстоит научиться. `:)

                            0
                            Так 1,0,0,0 и 1000 это разные вещи =) А статья насчет 256 интересная, спасибо.
                          0
                          Да, так и работает. Я про это не писал, так как написал сноску про то, что читая эту статью вы уже должны быть знакомы с тем как работает специфичность)
                            0
                            А так может быть 10 > 50? Немного не понятно объяснял человек и я был сбит с толку.
                              0
                              Да, может запутано. Но там не 10 > 50, а 10010 > 00050 имелось в виду.
                            0

                            Не совсем так. Во многих популярных руководствах вес селекторов записывают трех-четырехзначными числами, что возникает такое впечатление, но по стандарту это числа в "бесконечноричной", в крайнем случае "дофигаричной", системе:). Когда-то давно был в некоторых браузерах курьез, что 256 классов перебивали-таки один id. Но это с тех пор исправили. А !important и вовсе не перебить никаким кол-вом id, потому что по стандарту он считается отдельным уровнем происхождения и важности, который важнее специфичности.

                              0
                              Да, но я считаю, что его уместно учитывать в расчете веса селектора таким образом. Так как его приоритет может комбинироваться с обычным приоритетом селекторов по id, class, tag. Выглядит вполне уместно.
                                0

                                Не спорю, общая суть верна, просто хотел предостеречь от буквальной трактовки этой "тысячи" как какой-то реальной волшебной константы

                                  0
                                  Есть такое заблуждение, когда это начинают считать «тысячей».
                                  На деле это ж скорее 1.0.0.0.0.

                                  Где каждая цифра это:
                                  !important | inline | id | class | tag

                                  Участие в этой схеме инлайновых стилей тоже спорная история, но если они учитываются в расчете веса, то так будет вполне разумно считать
                                    0

                                    Анимации немного в эту схему не вписываются, в них !important, судя по всему, просто игнорируется. Но в большинстве случаев – вполне удобное правило

                          0
                          Вы лишь подтверждаете те заблуждения, которые есть в сообществе по поводу important исходя из которых я и писал этот материал
                          0
                          Лекарство в больших количествах станет ядом, а яд в малых дозах может стать лекарством. Вопрос в нашем здравомыслии и задокументированных соглашениях о том, что и каким образом использовать. С !important то же самое. Если не регламентировать — найдутся люди, которые превратят весь CSS на проекте в important-hell и убъют производительность труда на ровном месте, а если регламентировать, на уровне методологии, как например в rscss, то important станет удобным и полезным инструментом в тулбоксе верстальщика.
                            0
                            Полностью согласен)
                            0

                            Если полноценно использовать вменяемую методологию (БЭМ или тот же rscss), то important не нужен никогда.


                            Его приходится использовать временно, переходя с CSS, написанного "как получилось", на вменяемую методологию: в legacy часто встречаются излишняя вложенность и, как следствие, излишняя специфичность, и единственный способ — временно — пока то legacy не переписали — поставить !important и комментарий, поясняющий, почему он временно понадобился, и когда его можно будет убрать.


                            Что касается "универсальных классов" — лучше их просто не делать, а для DRY использовать миксины. Бутстрап вообще пример того, как делать не надо; точнее говоря, он удобен, если дизайна вообще как такового нет, и хочется быстро сделать что-то, выглядящее прилично (типа внутренней админки) не заморачиваясь. В проекте, где бутстрап используется по назначению, кастомного CSS вообще будет минимум.

                              0
                              Да, насчет методологий согласен.

                              Бутстрап не лучший пример, но он тут не в качестве хорошего примера. Он тут в качестве одной из популярных либ, в которой есть импортанты. Если посмотреть количество загрузок бутстрапа в неделю, то можно понять, что очень и очень много разработчиков потенциально сталкиваются с импортантами в бутстрапе)
                                0

                                То, что бутстрап стал использоваться не по назначению где попало — это вообще одна из главных бед фронтенда :)

                                  0
                                  Но это уже совсем другая история)
                              0
                              Ещё есть такая штука, что инлайн-стиль с important является последним в иерархии, его переопределить никак нельзя. Например, вы раздаёте какой-то платный виджет в демо-режиме с надписью «демо» (а шаловливые негодяи могут захотеть её скрыть). Ещё вариант — поля для ввода на страницах паролей, 3D-secure и прочего, которым нужна защита от кликджакинга и похожих техник.
                                0
                                Да, спасибо. Я про этот случай умышленно не писал, чтобы дополнительно не путать. Но это всё сводится к тем ситуациям, о которых я сказал в конце. Что это исключения, а не регулярное использование. И как раз чаще всего и используется в плагинчиках и расширениях.
                                  +1

                                  В некоторых случаях, напр., если этот стиль навешивается динамически по условию/событию, то можно. А если Firefox не важен, то можно практически всегда (пока:). Но это не по стандарту и дикий хак.

                                    0
                                    Да это отличный пример, спасибо! Как мы можем называться верстальщиками если не используем таких хаков :)
                                  0

                                  Используя css-modules столкнулся с проблемой, что в библиотеках иногда селекторы довольно многословны и, поэтому, имеют высокий приоритет и просто с использованием модулей (ровно как и styled-component) перебить без impotant их иногда не выходит. Жутко раздражает, хотелось бы, конечно, иметь более декларативный способ описания приоритета стиля, чем через селектор.

                                    0
                                    Так модуль же изолирует свои стили, и в пределах модуля ты можешь переопределять все что тебе нужно обычным способом. Я не совсем понял кейс, когда там нужен импортант.
                                    0
                                    JS может переназначать значения свойств только с помощью inline-стилей.

                                    let newStyle = document.createElement( 'style' );
                                    newStyle.textContent = '.redBorder{border:solid 5px red;}';
                                    document.body.appendChild( newStyle );
                                    document.body.classList.add( 'redBorder' );

                                    PROFIT!
                                      –2

                                      Надеюсь ты так никогда не делаешь в реальных задачах)

                                        +1
                                        А чем работа с CSS хуже работы с отдельными элементами (да ещё и в цикле, не дай Бог, если надо с несколькими)?
                                        А так, можно и инлайн-стили менять по разному, хоть через
                                        element.setAttribute('style', element.getAttribute('style') + newStyle);
                                          0
                                          Это и есть перезапись инлайн-стилей. А тот вариант, что ты привёл до этого — это очень не хорошо)
                                            0
                                            Я так и написал, что это способ менять инлайн-стили.
                                            Хотя я обычно пользуюсь традиционным element.style.fontSize = '18pt';
                                            Но всё же: «очень не хорошо» это субъективная оценка.
                                            А что в этом объективно нехорошо?
                                              0
                                              Ну если даже не говорить уже о том, что просто, на то, чтобы поменять один цвет в CSS будет написано 4 строки JS, то плохо как минимум то, что мы вмешиваемся в DOM и с точки зрения производительности это значительно хуже, чем просто перезапись стилей, даже инлайном.
                                                0
                                                Ну, один цвет у меня всего лишь для примера, в newStyle.textContent может быть килобайт текста :).
                                                Впрочем, и вставка нового элемента у меня лишь для ясности способа, можно вставить текст в последний имеющийся style. И только в случае его отсутствия использовать appendChild.
                                      0
                                      Что значит «быстро»? Разве узнать необходимый вес селектора для переопределения так сложно и долго? Мы очень активно используем DevTools при разработке, и для решения этой задачи ответ у нас есть там же.



                                      Разве это долго? Мне кажется, по времени это мало отличается от того, чтобы дописать !important, однако намного правильнее и безопаснее.


                                      А потом заказчик вас спросит, почему у него на мобильном ничего не поменялось. И нет, окажется, что проблема не в очистке кэша, а в том, что там есть ещё десяток других дублирующих селекторов для разных разрешений, которые вы в инспекторе объектов на десктопе не увидели.

                                      Или окажется, что на разные типы заголовков прописан десяток разных «тяжелых» селекторов, а вам нужно просто быстро показать заказчику, почему белый на сером — плохая идея в любом месте сайта.

                                      То есть я не спорю, что чем меньше !important, тем правильнее, но таки да, написать !important в основном быстрее. В этом-то и его trade-off.
                                        0
                                        Ну это ж уже следствие другой проблемы, а не импортантов. Если в проекте плохая организация кода и чтобы заменить цвет заголовка, нужно несколько часов искать все места где этот цвет назначался, то да, в таком случае используя !important ты ускоряешь процесс. Но при этом ухудшаешь и без того паршивую ситуацию)

                                        А «быстрее» писать !important это опять же, если приводить синтетический случай. Ты его написал, показал заказчику и удалил. А если ты его написал и оставил, то это ускорение сработает ровно один раз. До следующего раза, когда тебе импортанты надо будет писать поверх импортантов и ты все равно придешь к работе с весом селекторов)
                                        0

                                        !important нужно использовать только для скрытия через display: none в медиа-выражениях. Например для адаптивных хелперов. Это нужно если порядок свойств компонентов идёт после наших хелперов и мы гарантированно хотим скрыть элемент. Во всех остальных случаях повышайте специфичность селектора (потому что если вы сделали это один раз скорее всего вы сделаете это ещё раз) и используйте изоляцию стилей. Переопределять стили в атрибуте style совсем плохо. Лучше обновите сам style.

                                          0
                                          Ну это ж тоже может породить потом important поверх important'ов. Типа: мы скрываем на маленьком размере экрана какой-то блок, а потом решаем что на всех маленьких экранах он должен быть скрыт, а на маленьком экране с соотношением сторон 4:3, например, показать. И начинается та же проблема. Случай синтетический, но вполне реальный. Кажется тут тоже можно просто на весе селекторов сделать.
                                            0
                                            Это уже ошибка архитектуры, не должно быть таких правил в медиа-выражениях которые перезаписывают то что уже задано через !important. Чтобы эту проблему решить нужно указывать более конкретные условия в медиа-выражении.
                                              0
                                              Просто я не до конца понимаю зачем тут нужны импортанты в принципе. Лучший вариант не перезаписывать импортанты это не писать их вообще)
                                                0
                                                Они нужны потому что вы можете в каком-то куске кода иметь повышенную специфичность, в таком случае в этих хелперах придётся её ещё раз повышать чтобы перезаписать это правило, это можно повторять до бесконечности. Так как мы наверняка уверены что элемент должен быть скрыт то здесь оправдано использование !important, а не специфичности. Перезаписывать !important я не предлагаю, я предлагаю им перекрывать стили которые мы гарантированно хотим перекрыть и мы можем гарантировать что их не придётся перекрывать ещё раз (выше ответил как это сделать: через уточнение самих правил).
                                          0
                                          Аналогом css-правила !important для кода является использование оператора goto — пользоваться можно, но очень аккуратно и осознавая последствия.
                                            0
                                            С умом)
                                            0

                                            Вообще не использую! important, потому что всегда пишу стили от родителя. Сам Яша рекомендует использовать импортант, только в самых необходимых моментах, когда например стили слайдера у вас на 2560 строчке в файле css, а стили доп блока в слайдере вы уже написали на 30 строчке, тут можно конечно перетащить эти стили на 2561 строчку, но тогда может поехать стиль другого блока и т.д, вот поэтому и надо задавать такой селектор

                                              0
                                              Ну опять же, то, что стили в файле записаны раньше, это еще не значит, что нам нужен импортант. У нас для этого есть вес селектора и он с этим справляется. Это как раз тот случай, в котором я бы точно не советовал использовать !important
                                              0
                                              В версии сайта для слепых мне кажется очень неплохо заходит
                                                0
                                                Если я бы писал плагин, который помогает такой версии страницы стать лучше, или аналогичное расширение, то с большой вероятностью использовал бы там important. Но если это просто моя вёрстка, то в принципе, могу вполне обойтись весом селектора. По крайней мере вспоминая все такие случаи, не помню исключений.
                                                0
                                                очень спорная статья, в important нет ничего критического, можно испольлзывать для быстрого фикса пробллемы и для переопределения (но всегда с умом)
                                                  0
                                                  а статья разве не об этом?
                                                    0
                                                    сейчас перечиталл статью, сорри, речь именно об этом)
                                                  0

                                                  Работал в одной вебстудии, так там один верстальщик писал стили как попало и потом когда дальше стили не применялись добавлял id к элементы и стили к нему с помощью !important дописывал, я сколько ему не объяснял, что это бред, но так и не добился результата. Сам !important использую когда inline нужно переопределить или когда заказ на тестирование нового интерфейса и этот код отдельно подключается и только на время

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое