Статьи

Адаптивный веб-дизайн и полосы прокрутки: лучше ли реализация Chrome?

В моем недавнем сообщении, Ваш Отзывчивый Веб-дизайн слишком хрупок? Я описал несоответствие между браузерами при запуске событий медиазапроса:

  • Chrome и Safari исключают размеры полосы прокрутки.
  • Firefox, Opera и IE включают размеры полосы прокрутки.

Предположим, у нас есть медиа-запрос, который обнаруживает минимальную ширину 800 пикселей, например

@media (min-width: 800px) { ... } 

Chrome и Safari будут включать эти стили, когда ширина тела составляет 800 пикселей или больше. Однако, если ваша ОС показывает вертикальные полосы прокрутки шириной 20 пикселей, другие браузеры будут включать стили с разрешением 780 пикселей.

Давайте прочитаем спецификацию медиазапроса W3C для ширины :

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

Движок Webkit неверен. Но так ли это лучше?

На первый взгляд реализация Chrome кажется логичной, но важно понимать, что «ширина» относится к размерам области просмотра, т.е. к общей площади внутри окна браузера, а не к ширине страницы . Используя предположения выше, ширина области просмотра Chrome на самом деле составляет 820px (тело прокрутки 800px + полоса прокрутки 20px). В других браузерах ширина области просмотра составляет 800px (тело прокрутки 780px + полоса прокрутки 20px).

К сожалению, знание ширины области просмотра не помогает разработке CSS, так как вы не знаете, видима ли полоса прокрутки или каковы ее размеры. Тем не менее, альтернатива Chrome намного хуже, так как введение или удаление полосы прокрутки может вызвать медиа-запрос . Это немного сложно, поэтому я объясню на примере:

  1. Предположим, у вас есть простой адаптивный сайт, который показывает макет рабочего стола в 800px или больше и мобильный сайт в 799px или меньше. Ширина полосы прокрутки составляет 20 пикселей.
  2. В настоящее время окно браузера имеет размер окна просмотра 810 пикселей. Высота достаточно велика, чтобы показать текущую страницу (в макете рабочего стола) без полос прокрутки.
  3. Вы переходите на другую страницу. Здесь содержимое длиннее, чем высота области просмотра, и появляется вертикальная полоса прокрутки. Это уменьшает ширину корпуса до 790 пикселей, и Chrome мгновенно переключается с настольного компьютера на мобильный макет. Пользователь смущается и клянется никогда больше не возвращаться на ваш сайт.

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

Firefox, Opera и IE не демонстрируют это поведение, потому что размеры области просмотра никогда не изменяются, пока пользователь не изменит размер окна своего браузера. Тем не менее, пользователи Chrome и Safari могут использовать разные макеты только потому, что на одной странице вашего сайта немного больше контента, чем на другой. Насти.

Правда, это крайний случай:

  • Мобильные браузеры обычно не отображают постоянные полосы прокрутки, поэтому проблема никогда не является очевидной на этих устройствах.
  • Пользователю настольного браузера не повезло, если бы размеры окна были установлены в точке, где макеты заметно изменились.
  • Вы можете предотвратить переключение макетов Chrome, обеспечив вертикальную полосу прокрутки всегда видимой, т.е. body { overflow-y: scroll; } body { overflow-y: scroll; }

Тем не менее, я считаю, что команда Webkit и Blink считает, что для решения этой проблемы есть веская причина. Я подозреваю, что медиазапросы были реализованы в Webkit до того, как синтаксис стал стандартом. Однако теперь у нас есть Рекомендация W3C; имеет смысл следовать окончательным правилам и предоставлять согласованный опыт для пользователей и разработчиков.