Фрэйн . - HTML5 и CSS3. Разработка сайтов для любых браузеров и устройств. 2-е изд.

Вложение медиазапросов путем их встраивания

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

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

Как поступать — объединять медиазапросы или же записывать их там, где они пригодятся?

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

.thing {

width: 50%;

}

@media screen and (min-width: 30rem) {

.thing {

width: 75%;

}

}

/* Здесь между рассматриваемыми фрагментами кода помещаются другие стили */

.thing2 {

width: 65%;

}

@media screen and (min-width: 30rem) {

.thing2 {

width: 75%;

}

}

Поначалу все это выглядит весьма странно. У нас есть два медиазапроса, и оба они имеют отношение к экранам с минимальной шириной 30 rem. Неужели повторение @media-объявления не считается многословием и расточительством? Наверное, мне следовало бы сгруппировать все идентичные медиазапросы в единый блок:

.thing {

width: 50%;

}

.thing2 {

width: 65%;

}

@media screen and (min-width: 30rem) {

.thing {

width: 75%;

}

.thing2 {

width: 75%;

}

}

Безусловно, это один из способов такой группировки. Но с точки зрения сопровождения кода он представляется мне более сложным. Правильного способа не существует, но я предпочитаю сначала определить одно правило для отдельного селектора и располагать определения любых изменений этого правила (например, изменения внутри медиазапросов) непосредственно после него. При этом мне не придется искать отдельные блоки кода, чтобы найти объявление, относящееся к конкретному селектору.

примечание

Еще более удобным может стать использование препроцессоров и постпроцессоров CSS, поскольку вариант правила, заключенный в медиазапрос, может быть вложен непосредственно в набор правил. В моей книге Sass and Compass for Designers этой теме посвящен целый раздел.

Казалось бы, вполне резонно выступить против вышеупомянутой технологии по причине ее многословия. Неужели один лишь размер файла может стать достаточной причиной для того, чтобы не записывать медиазапросы таким образом? В конце концов, никому не хочется иметь раздутый CSS-файл для обслуживания своих потребностей. Но нужно считаться с тем простым фактом, что gzip-сжатие, которому должны подвергаться все возможные ресурсы на вашем сервере, сокращает разницу до совершенно ничтожных величин. Ранее я провел соответствующие тесты, и если у вас появилось желание получить дополнительные сведения, можете обратиться по адресу http://benfrain.com/inline-or-combined-media-queries-in-sass-fight/. Суть в том, что я не верю, что вас будет тревожить размер файла, если вы предпочтете записывать медиазапросы непосредственно после стандартных стилей.

совет

Если вам хочется разрабатывать свои медиазапросы непосредственно после исходных правил, но при этом иметь все идентичные определения медиазапросов объединенными в один запрос, то для этого существует несколько рабочих инструментов (на момент написания данной книги соответствующие дополнительные модули были как у Grunt, так и у Gulp).

Метатег viewport

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

Когда в 2007 году компания Apple выпустила iPhone, она ввела собственный метатег под названием viewport, который теперь поддерживается Android и постоянно растущим количеством других платформ. Предназначением метатега viewport является предоставление веб-страницам способа связи с браузерами мобильных устройств для сообщения им предпочтительного способа вывода страницы на экран.

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