​​Опасная высота
#qa #frontend

Создавая макеты мобильного адаптива, обычно ориентируются на самые маленькие экраны шириной в 320 px, например как у Apple iPhone 5s. При этом высоту экрана рассчитывают с точки зрения необходимости размещения законченного целостного блока на одном экране и визуального индикатора присутствия скролла «Скролльте вниз».

Здесь может произойти неочевидная подмена характеристик: screen size — размер физического экрана и viewport size — размер его контентной части в окне мобильного браузера.

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

Высота viewport-области может меняться даже в рамках одного устройства — при использовании различных браузеров. Более того, она может меняться в процессе навигации по сайту. Например, браузер iOS Safari уменьшает свою панель навигации при скролле вниз, из-за чего могут ложно срабатывать некоторые js-события, отслеживающие ресайз.

Дадим несколько советов, призванных помочь вам в борьбе за функциональность и красоту адаптивов 😉

1. Используйте динамическое позиционирование элемента относительно высоты текущего viewport. Например, блока с иконкой «Скролльте вниз».
2. При тестировании веб-интерфейса создавайте свои шаблоны мобильных устройств в браузерных инструментах с уменьшенной высотой по отношению к стандартным. Например, на 80—100 px меньше.
3. Проверяйте работу интерфейса на реальных устройствах или полноценных симуляторах. Например, Xcode Simulator для iOS.
4. И конечно, учитывайте высоту viewport-области в макетах дизайна.