Несколько текущих причин пошли в текущий дизайн:
Мы специально не включали специфичностьсовсем.Это может раскрыть детали реализации компонента, что делает код хрупким - если компонент обновляется и меняет точный селектор, который он использует, он может начать переопределять внешние правила, которые раньше выигрывали, или наоборот, и для компонента нет подходящего способа.пользователь должен понять или манипулировать этим.
Таким образом, мы должны решить другим способом.Порядок документов (последний шаг каскада) здесь на самом деле не работает - он добавляет неожиданную зависимость от того, как именно вы загружаете пользовательский элемент, и может иметь интересную расу
Так что у нас остался Cascade Origin, иличто-то близкое к этому, что просто безоговорочно делает одну или другую победу.На самом деле введение нового источника в список не казалось хорошей идеей;непонятно, как с этим должны взаимодействовать таблицы стилей пользователя и автора.Поэтому вместо этого мы добавляем еще один каскадный шаг для этого.
И, наконец, мы должны принять решение о том, какой из них победит.Мы уже знаем, что независимо от того, какой порядок мы выбираем, важно иметь обратный порядок;это то, как происхождение каскада уже работает.Таким образом, мы должны решить, выиграет ли внешняя страница по умолчанию, но компонент выигрывает! Важный, или наоборот.Мы решили, что первое имеет больше смысла;это означает, что обычные стили автора компонента являются «значениями по умолчанию», пользовательские стили компонента (! важно или нет) могут переопределить это, а важные стили автора компонента! важные могут быть использованы для «блокировки» стилей, которые должны оставаться такими, как они есть.,Обратный путь, похоже, тоже не удовлетворял сценариям использования: это означало бы, что пользователи компонентов не могут переопределять стили по умолчанию;они должны использовать! важный для этого, возможно, вмешиваясь в их другие стили;и тогда авторы компонентов не смогут «заблокировать» стили.