Ширина в медиа запросах и вертикальный скроллбар.

Перевод статьи:  Media Query width and vertical scrollbars.
Автор:  Roger Johansson.

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

Два года назад я уже затрагивал эту тему в статье Медиа запросы, ширина вьюпорта, полосы прокрутки и WebKit браузеры. Там же я указал на следующие формулировки из Media Queries спецификации:

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

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

В результате увидел три основные закономерности в их поведении:

Размер полосы прокрутки включается в ширину медиа запроса.

Многие десктоп браузеры учитывают размер скроллбара при определении ширины вьюпорта. Это Firefox, Opera и Internet Explorer.

Размер полосы прокрутки не включается в ширину медиа запроса.

Как уже упоминалось в моей предыдущей статье, на которую я сослался в начале поста, настольные версии браузеров на движке WebKit, такие как Chrome, Safari и другие, не учитывают величину скроллбара при определении указанной в конструкции медиа запроса ширины. Немного сложнее, если, конечно, не принимать во внимание следующий случай.

Полоса прокрутки входит в ширину медиа запроса, но не влияет на ширину области контента.

В Mac OS X 10.7 и выше предусмотрены настройки на вкладке General системного конфигурационного меню, позволяющие установить отображение полос прокрутки только в том случае, если пользователь прокручивает окно. И если пользователь активировал эту функцию, то браузер включает размер скроллбара в ширину медиа запроса, но отображает его только в том случае, когда прокручивается окно браузера. Кроме того, полоса прокрутки отображаются сверху, а не как положено сбоку области контента. По этой причине в данном случае ширина области контента, находящегося в рамках вьюпорта, шире на размер скроллбара, чем в других браузерах.

Аналогичным образом ведут себя и протестированные мной мобильные браузеры (различные устройства с iOS и ее версии, Opera Mobile, Android 2.3.3 и 4.1.2).

Возникает вопрос. Противоречит ли такое поведение браузеров спецификации Media Queries? Трудно дать однозначный ответ. Ведь, в конце концов, скроллбар включается в значение ширины, но в данном вопросе меня интересует то, действительно ли такое поведение рассматривалось CSS рабочей группой консорциума при создании спецификации.

В большинстве случаев это не является проблемой, но может стать.

Как же это на практике касается вас, как веб-разработчика? В качестве примера давайте рассмотрим как безупречно обрабатывается адаптивный дизайн в последних версиях Firefox. Они включают вертикальную полосу прокрутки в ширину вьюпорта и как только контент страницы не вмещается в окно браузера вертикально, отображают ее непрерывно, а не только во время прокрутки его содержимого. А это значит, что если вы будете использовать эти браузеры для проверки корректности отображения своего дизайна в размерах вьюпорта, характерных мобильным устройствам, вы не получите объективных результатов, которые будут в точности отображать настоящее поведение сайта при достижении переходных точек, свойственных размеру вьюпорта реального устройства, его симулятора или эмулятора.

Такое же поведение характерно настольным версиям браузеров Safari и Chrome (кроме тех случаев, когда они установлены на Mac с OS X 10.7 или выше и конфигурацией системы предусмотрено отображение скроллбаров только при прокручивании содержимого окна).

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

  1. Каким-то образом (к примеру, распознавание браузера пользователя при помощи скриптов или других альтернативных методов) определить включает ли браузер скроллбар в ширину медиа запросов.
  2. Определяя позиции для точек перехода, добавляйте к их значению ширину вертикальной полосы прокрутки, что предотвратит появление горизонтальной полосы прокрутки в тех браузерах, которые включают размер скроллбара в ширину вьюпорта и постоянно его отображают (не зависимо от того прокручивает пользователь окно браузера или нет).
  3. Сделайте шаблон сайта максимально гибким, который подразумевает плавное изменение ширины области контента, так что различия отображения скроллбара не будут иметь значения (во всяком случае решающего значения).

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

А что может быть лучшей альтернативой? К примеру, возможность включения в конструкцию медиа запроса фрагмента, проверяющего положение скроллбара. Таким вот образом:

@media only screen and (max-width:768px) and (vertical-scrollbar:[inside|outside|on-top]) {
/* необходимые преобразования */
}

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *