Screen Orientation API и адаптивные интерфейсы
Используйте смену ориентации как состояние адаптивной верстки, сохраняя доступность, выбор пользователя и приватность.
Нужна структурированная документация по теме Отпечатки?
Эта статья относится к редакционной библиотеке. Для пошаговой настройки, справки и постоянных обновлений переходите сразу в соответствующий раздел docs.
Screen Orientation API позволяет наблюдать текущую ориентацию и в поддерживаемом контексте запросить предпочтительную. Адаптивный дизайн должен считать ориентацию меняющимся состоянием макета, а не меткой устройства. Телефон можно держать в любом направлении, окно ноутбука можно изменить, а окно разделённого экрана бывает уже дисплея. Стройте интерфейс по доступному месту, сохраняйте задачу пользователя и используйте ориентацию только для видимого решения продукта.
Спецификация W3C Screen Orientation описывает объект ориентации, type, angle, события и условия блокировки. Справочник MDN описывает интерфейс и совместимость. Источники объясняют возможные данные браузера, но не требуют блокировать экран или хранить историю ориентации.
О геометрии читайте в руководстве по экрану и viewport и руководстве по доступности указателей.
Считайте ориентацию состоянием макета
screen.orientation.type описывает категории portrait-primary и landscape-primary, а angle показывает угол относительно естественной ориентации. Во время поворота оба значения могут измениться, а порядок событий зависит от браузера и ОС. Дождитесь стабилизации области просмотра вместо предположения, что одно событие описывает весь переход.
Большинство решений о макете относится к CSS. Медиазапрос (orientation: portrait) может сменить сетку, а container queries позволяют компоненту реагировать на собственную ширину в разделённом окне или встроенном документе. JavaScript может использовать matchMedia или объект ориентации для конкретного поведения, например изменения размера canvas. Условие должно быть связано с видимым результатом, а не с каталогом устройств.
Ориентация не говорит, используется ли телефон, планшет, компьютер или удалённый сеанс. Панели браузера, управление окнами, масштаб, специальные возможности и виртуальная клавиатура меняют фактическое место. Узкое окно на компьютере остаётся допустимым состоянием. Не выводите из ориентации личность, местоположение, возраст или возможности человека.
Сохраняйте задачу при повороте
Поворот происходит во время чтения, редактирования или заполнения формы. Сохраняйте введённые данные, полезную позицию прокрутки, выбранную вкладку и фокус. Не пересоздавайте страницу и не переходите на другой экран из-за поворота. Если компонент всё же нужно пересоздать, явно восстановите фокус и объявляйте только важное изменение.
Используйте гибкие колонки, переносимые подписи, адаптивные изображения и точки перехода, выбранные содержимым. Двухколоночная форма может стать одноколоночной; широкая таблица может показать приоритетные столбцы и доступный с клавиатуры просмотр остальных. Скрытый в портретном режиме элемент должен иметь равнозначное действие. Критическая операция не должна зависеть от жеста в одном направлении.
Виртуальная клавиатура, панель браузера или разделитель окна могут закрыть содержимое. Держите активное поле видимым, не размещайте основную кнопку под перекрытием и заново размещайте диалог при изменении визуальной области. Спецификация CSSOM View задаёт понятия геометрии, но за рабочий результат отвечает приложение.
Запрашивайте ориентацию только по необходимости
screen.orientation.lock() является запросом, а не универсальной командой. Видимость документа, контекст, активация пользователя, полноэкранный режим и политика платформы задают ограничения. Обещание может быть отклонено. Страница должна работать и без блокировки.
Игре, предпросмотру камеры или презентации иногда нужен стабильный формат. До запроса объясните эффект, дайте заметный выход и снимите блокировку после завершения. Не блокируйте ориентацию ради упрощения настольного макета, классификации посетителя или запрета адаптации.
Режим, меняющий весь экран, должен начинаться с явного действия пользователя. Открытая по ссылке страница не должна неожиданно поворачиваться или запирать человека. При отказе браузера покажите обычный адаптивный макет и сохраните задачу. Отказ является результатом совместимости, а не сведением об устройстве.
Обрабатывайте события без гонок
Объект ориентации предоставляет событие change. Обработчик читает текущее состояние, меняет только нужный компонент и терпит повторные уведомления. При зависимости от фактического места добавляйте resize или наблюдение визуальной области; это связанные, но разные изменения.
Избегайте дорогой синхронной работы. Планируйте ограниченное обновление, отменяйте устаревшую работу и сохраняйте отзывчивость ввода. Для медиа, карты или canvas сохраняйте смысловое содержимое, меняя размеры отображения. Ошибка перерисовки должна оставить рабочую альтернативу, а не пустую область.
Защищайте необязательное поведение проверкой возможностей, проверяйте нужный метод и перехватывайте отклонение lock(). CSS-медиазапросы и resize подходят для отката. Не начинайте скрытый сбор ориентации, угла, viewport и экрана при отсутствии API.
Сохраняйте доступность и контроль
Адаптивная перестройка должна сохранять семантические заголовки, области, подписи и порядок чтения. После поворота проверяйте клавиатуру и фокус, включая край визуальной области. Скринридеру нужен полезный статус, когда элементы действительно переместились, а не необработанный угол каждого поворота.
Учитывайте масштаб, увеличение текста, уменьшение движения, высокий контраст и принудительные цвета. Макет, работающий при обычном масштабе, может сломаться при увеличенном тексте или открытой клавиатуре. Сохраняйте размеры целей, контраст и сообщения ошибок. WCAG 2.2 помогает проверять результат; сама ориентация не определяет соответствие.
У режима, зависящего от ориентации, должен быть видимый выход, доступный с клавиатуры и не стирающий работу. Объясняйте, когда вращением управляет браузер или ОС, а приложение лишь просит предпочтение. Отказ не следует выдавать за ошибочную настройку пользователя.
Проверяйте поведение, а не типы устройств
Составьте матрицу для портретного и альбомного режима, узких и широких окон, увеличенного текста, виртуальной клавиатуры, клавиатурного и сенсорного ввода, уменьшения движения и браузера без API. Проверяйте чтение, основное действие, восстановление после ошибки и выход из заблокированного режима. Добавьте промежуточную ширину, где чаще всего ломается перенос.
Записывайте версию браузера, viewport, ориентацию и настройки как конфигурацию теста. Снимок экрана доказывает только эту конфигурацию, а не постоянное свойство человека. Используйте синтетические данные и не отправляйте историю ориентации в аналитику. При необходимости телеметрии выбирайте агрегированный результат, а не набор углов, размеров и времени.
Определите приватный адаптивный контракт
До чтения свойства запишите поддерживаемое решение, например размещение предпросмотра рядом с элементами управления при достаточной ширине компонента. Предпочитайте CSS и локальный matchMedia. Если сервису действительно нужен результат для улучшения продукта, укажите цель, срок хранения, доступ и выбор пользователя, удалив лишние поля.
Ориентация вместе с другими значениями может участвовать в отпечатке, но адаптивной верстке не нужен такой профиль. Не используйте портретный или альбомный результат как сигнал аккаунта, риска или права доступа. Общий компьютер, повёрнутый монитор, эмулятор и изменённое окно дадут одинаковое значение. Отсутствующее или грубое значение нормально.
Проверяйте визуальную область отдельно: панель браузера или клавиатура могут закрыть поле после поворота. Безопасные отступы и временные перекрытия относятся к рендеру, а не к постоянным свойствам устройства.
Для каждого состояния определите результат, например открытие и закрытие меню с сохранением фокуса или доступность субтитров и основной кнопки после изменения размера предпросмотра. Такие результаты лучше списка моделей и помогают пересматривать совместимость.
В аналитике и экспериментах измеряйте результат задачи, а не профиль из угла, размеров и времени. Назначение эксперимента должно быть независимо от запроса блокировки, чтобы отказ не лишал базового интерфейса.
При добавлении функции, зависящей от ориентации, пересмотрите контракт, удалите свойства без видимого решения и сохраните условные формулировки и доступный откат во всех переводах.
Доступный откат является частью функции: при отказе блокировки сохраняются заголовки, подписи и данные задачи, чтобы продолжить в портретном или изменённом окне.
Выбор ориентации должен быть обратимым. Храните явное предпочтение отдельно от наблюдений браузера и дайте сброс, не превращая выбор в вывод об устройстве.
Откат должен сохранить восстановление после ошибки и явно назвать следующий шаг.
Он также показывает состояние и следующий шаг, чтобы результат совместимости не оставлял человека без выхода.
Даже без ожидаемого соотношения стороны элементы компонента должны оставаться видимыми и рабочими.
Практический список
- Для обычной перестройки используйте CSS или container queries, а JavaScript оставляйте для ограниченного поведения.
- При повороте сохраняйте значения форм, фокус, порядок чтения и восстановление.
- Запрашивайте блокировку после действия пользователя и обрабатывайте отказ адаптивным откатом.
- Проверяйте масштаб, клавиатуру, специальные возможности и промежуточные ширины в обоих направлениях.
- Оставляйте измерения локальными, если нет документированного добровольного решения продукта.
Планируйте переходы и восстановление
Поворот может совпасть с навигацией, запросом или ошибкой проверки. Держите состояния раздельно и не отправляйте форму дважды. Медиа, canvas и встроенные компоненты должны сохранять содержимое, субтитры и фокус; при нехватке места нужна читаемая альтернатива. URL и история не должны меняться из-за ориентации. Серверный рендер может начать с консервативного макета, а клиент уточнить viewport без удаления текста. Для панелей и iframe используйте container queries. Анимации должны прерываться и уважать настройку уменьшения движения. Документируйте проверенные браузеры и откат, не обещая одинаковый порядок событий. При диагностике записывайте видимый результат и конфигурацию, а не постоянный список экрана.
Источники
Похожие статьи
Переведите BotBrowser из исследований в продакшн
Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.