После старых. Если порядок в CSS является важным

Старший аспирант «Нетологии» Алена Батицкая перевела статьи Криса Койера Precedence in CSS (When Order of CSS Matters) о видимости в CSS.

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

Специфичность означает, что порядок имеет значение. Стили, которые находятся ниже по каскаду, выигрывает.

В рамках одной таблицы стилей

Предположим, что у нас есть HTML-теги:

!DOCTYPE html>
html lang=»ru»>
head>
meta charset=»UTF-8″>
title>Документ/title>
link rel=»stylesheet» href=»стили.css»>
/head>
body>
div class=»module module-module foo-bar»>
Содержание
/div>
/body>
/html>

Порядок атрибутов, в HTML значения не имеет. Все в порядке внутри таблицы стилей. Давайте посмотрим ближе на background:

/*
У всех избирателей под тем же специфика
*/

.module {
background: #ccc;
padding: 20px;
max-width: 400px;
margin: 20px auto;
}

.модуль-foo {
background: orange;
}

/* Объявлен ПОСЛЕДНИЙ, выигрывает это свойство/значение */
.модуль-бар {
background: lightblue; /* Я выйграл! */
}

Живой пример

Намеренно неудобный пример

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

Куски находятся в link rel=»stylesheet»> внутри тега
style type=»text/css»> или крепятся с помощью @import

!DOCTYPE html>
html lang=»ru»>
head>
meta charset=»UTF-8″>
title>Документ/title>

link rel=»stylesheet» href=»1.css»>

style>
.модуль-baz {
background-color: pink;
}
/style>

/head>
body>
div class=»module module-module foo-bar module-baz»>
Содержание
/div>

style>
@import «2.css»;
/*
Содержит
.модуль-бар { background: #f06d06; }
*/
/style>

/body>
/html>

Я подписал кусочки номерами 1, 2 и 3. Все они содержат CSS-селекторы с той же специфичностью. Нет. 3 объявлено последнее, потому что стили, которые он содержит, и использовать на странице.

Асинхронная загрузка CSS, следовательно, принимает во внимание последовательность документов

Возможно, вы скачать CSS с помощью чудесного подгрузчика как loadCSS. Что произойдет, если мы хотим загрузить четвертый CSS-файл? С настройками, которые совпадут с одним из подключенных файлов в нашем скручивание примере. loadCSS по умолчанию подключить таблицу стилей в самый конец шапки сайта (раньше Новый файл стал третьим в рейтинге, и @import — соответственно, четвертый. И еще победит!

DOCTYPE html>
html lang=»ru»>
head>
meta charset=»UTF-8″>
title>Документ/title>
link rel=»stylesheet» href=»1.css»>

script src=»loadCSS.js»>/script>
script>
loadCSS(«2.css»);
/script>

/head>
body>
div class=»module module-module foo-bar module-late»>
Содержание
/div>
/body>
/html>

Вообще-то это код, в котором ссылка> или style> расположены внутри , то будет считаться невалидным. Даже если будет работать. Так что стили, загруженные с помощью loadCSS чаще всего будут выигрывать.

После окончания верстки принято контролировать ее с помощью валидатора. Это вам поможет быстро найти и устранить ошибки. Проверка осуществляется в соответствии с текущей спецификацией HTML/CSS.

Кроме того, вы можете ввести специальный код для проверки последовательности загрузки CSS:

script id=»loadcss»>
// скачать CSS-файл непосредственно перед записью, которая содержит следующий код
loadCSS(«path/to/mystylesheet.css», document.идентификатору(«loadcss»));
/script>

Критичный CSS может создать проблемы?

Одна из причин, почему вы используете loadCSS — намеренная попытка отложить загрузку ваших стилей, потому что вы используете критичный CSS внутри. Эта техника помогает подгрузить стили в первых сериях и ускорения рендеринга страниц.

DOCTYPE html>
html lang=»ru»>
head>
meta charset=»UTF-8″>
title>Документ/title>
style>
/* #1
Критичный CSS здесь */
/style>
script>
/* #2
Скачать другую CSS
*/
/script>
/head>
body>
div class=»module module-module foo-bar»>
Содержание
/div>
/body>
/html>

Практика критичного CSS предполагает перемещение CSS-селекторов на более высокий (код) позиции. Кусок № 1. На часть с более низким приоритетом, и, как следствие, простой для перезаписи. Так что, теоретически, да, могут возникнуть конфликты/изменение между фазами, когда страница загружается только критичный CSS и когда весь CSS загружается и примерился к содержимому страницы. Но таблицы стилей загрузятся полностью, и будет находится под кодом относительно критичного CSS, так что в конечном итоге вы получите то, что ожидали.

Наследование принесет проблемы?

В препроцессорах да, может.

Предположим, что вы хотите стилизовать элемент, с вариациями:

div class=»module module-variation»>Содержание/div>

И код, препроцессор будет следующее (максимально упрощены для ясности:

%variation {
background: orange;
}

.module {
background: #ccc;
padding: 20px;
max-width: 400px;
margin: 20px auto;
}

.модуль- «variation» {
@extend %variation;
}

Вы думаете, что это НОРМАЛЬНО .модуль- «variation» идет ПОСЛЕДНИМ в списке избирателей, таким образом он выигрывает и цвет фона должен быть оранжевый. Но это не так, поскольку наследование (расширение) передвигает селектор там, где это наследование объявлен. В нашем случае это место прямо перед тем кодом, который мы стараемся подавить. Скомпилированный CSS выглядит следующим образом:

.модуль- «variation» {
background: orange;
}

.module {
background: #ccc;
padding: 20px;
max-width: 400px;
margin: 20px auto;
}

И так фон будет цвет #ccc, а не того, которого мы хотели. Вероятно, будет проще решить эту проблему с помощью своей специфики, а не при помощи порядка избирателей.

Нативное наследование, когда, наконец, появляется, то, скорее всего, будет менее запутанной.

Глупо этим управлять

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

Комментирование и размещение ссылок запрещено.

Комментарии закрыты.