⁣Cascade Layers без specificity-войн: @import с supports()

На реальном проекте с тысячами строк CSS проблема не в адаптивности, а в том, что каждый второй селектор — #page .wrapper .card .title a, а !important разбросан, как конфетти. Специфичность растёт быстрее, чем число страниц. Выход — Cascade Layers, но на legacy-коде переписать всё под @layer нельзя. Помогает связка @import с supports().

Схема миграции

Сначала объявляешь слой для старых стилей: @layer legacy;. Всё, что туда попадёт, получает самый низкий приоритет. Даже #header .card .title из legacy не перекроет .card из более высокого слоя. Затем задаёшь иерархию для новых: @layer base, components, utilities;. Теперь есть чёткая линейка — компоненты перебивают базу, утилиты перебивают компоненты. Без вложенности в 5 уровней.

Production-подключение через @import

Современные браузеры грузят новый CSS через @import с supports() и сразу кладут его в нужный слой:

@import url("new.css") supports(display: grid) layer(components);

А для старых (IE11, древний Safari) — обычный @import на legacy файл. Они проигнорируют supports и layer, получат старые стили и не сломаются. Это даёт cross-browser fallback без хаков.

Типичная ошибка и trade-off

Ошибка — пытаться засунуть в @layer всё сразу. На деле слой legacy должен быть объявлен до всех @import. А лучше постепенно вытаскивать компоненты в свои слои. Это про распределение приоритетов, а не про переписывание кода с нуля. Из нюансов: старые браузеры, не поддерживающие @layer (например, IE11), увидят только обычные стили, поэтому важно, чтобы legacy-файл не переопределял новые компоненты через высокую специфичность.

Вывод:
Связка @import supports(...) layer() позволяет внедрить Cascade Layers на legacy-проекте без слома старых стилей и specificity-войн, сохраняя предсказуемость layout.