Свойства экрана и viewport для адаптивного дизайна
Как свойства экрана, viewport и devicePixelRatio помогают создавать адаптивную верстку, тестировать ее и соблюдать границы приватности.
Нужна структурированная документация по теме Отпечатки?
Эта статья относится к редакционной библиотеке. Для пошаговой настройки, справки и постоянных обновлений переходите сразу в соответствующий раздел docs.
Адаптивный дизайн должен реагировать на доступное странице пространство, а не угадывать, кто ею пользуется. Viewport - область, в которой раскладывается документ; свойства экрана описывают внешний для страницы контекст отображения. devicePixelRatio связывает CSS-пиксели с физическими и может меняться из-за масштаба или настроек дисплея. Эти значения помогают выбрать читаемую компоновку, но не являются надежным идентификатором устройства.
Viewport и экран отвечают на разные вопросы
window.innerWidth и window.innerHeight описывают viewport компоновки в CSS-пикселях. Спецификация CSSOM View также определяет объекты экрана и геометрию окна, но каждое значение нужно применять по назначению. Решения о компоновке обычно относятся к CSS-медиазапросам и viewport; значение экрана может описывать большую область, частично скрытую интерфейсом браузера или другими окнами.
Визуальный viewport может отличаться от viewport компоновки при масштабировании страницы или появлении экранной клавиатуры. Считайте такие изменения обычными событиями компоновки. Широкий экран не означает широкий доступный viewport, а одинаковые viewport не доказывают, что они получены с одного дисплея.
О связанной конфигурации дисплея рассказывают руководство по экрану и окну и политика device pixel ratio. Те материалы описывают границы конфигурации браузера; эта статья посвящена пользовательской компоновке.
Используйте свойства для устойчивой компоновки
Сначала сделайте содержимое и элементы управления полезными в узком viewport, затем добавляйте колонки, крупные медиа или более плотную навигацию, когда места достаточно. CSS container queries и медиазапросы выражают такие решения без списка моделей устройств. Гибкие сетки, внутренние размеры, адаптивные изображения и переносимый текст надежнее фиксированных координат.
JavaScript может наблюдать конкретную потребность приложения, например изменить размер графика или переместить диалог, с помощью ResizeObserver или проверки медиазапроса. Связывайте реакцию с видимым результатом. Компоновке, которой нужна область шириной 640 пикселей, не требуется сохранять все размеры экрана. Руководство по эмуляции устройств помогает проверять типичные viewport, не превращая их в утверждения об идентичности.
Если значение недоступно, приходит с задержкой или меняется после масштабирования, сохраняйте основную задачу. Меню может стать кнопкой, таблица может прокручиваться, а изображение может использовать источник меньшего размера. Не оставляйте пустую область и не блокируйте чтение только из-за отсутствия предпочтительного измерения.
Учитывайте масштаб и ориентацию
MDN указывает, что devicePixelRatio может меняться при масштабе страницы или изменении дисплея; это не постоянная метка устройства. Масштаб меняет соотношение CSS- и физических пикселей, даже если человек остается за тем же компьютером. Для компоновки используйте CSS-пиксели и проверяйте уровни масштаба, которые обещает поддерживать продукт.
Смена ориентации изменяет viewport и может отдельно изменить визуальный viewport. Перестраивайте заголовки, элементы управления и медиа, а не предполагайте фиксированные размеры для портретного и альбомного режима. Сохраняйте фокус и состояние формы и не делайте жест для одной ориентации единственным способом завершить действие.
Если снимок экрана или визуальный регрессионный тест использует коэффициент масштаба, запишите его рядом с viewport и версией браузера. Другой коэффициент может изменить размеры растрового изображения, не меняя ожидаемую CSS-компоновку. Сравнивайте видимый результат и храните отдельные эталоны, если тест намеренно проверяет разные настройки дисплея.
Проверяйте доступный результат, а не категории устройств
Проверяйте ширины viewport, уровни масштаба, смену ориентации, ввод с клавиатуры и предпочтение уменьшенного движения. На каждом шаге проверяйте читаемость текста, видимость фокуса, удобство целей нажатия, достаточный контраст и понятный порядок. Используйте реальные длины текста, а не только заглушки: локализация и пользовательский текст выявляют ошибки переноса.
Основные действия по возможности оставляйте в семантическом HTML. Canvas или визуальное улучшение могут адаптироваться, но навигация, состояния, подписи и элементы восстановления должны оставаться доступными вспомогательным технологиям. Если места мало для предпочтительного представления, дайте эквивалентный список, таблицу или упрощенный элемент управления, а не сообщение только о нехватке пространства.
Свойства экрана и viewport могут стать частью отпечатка браузера при широком сборе, но адаптивной компоновке такой сбор не нужен. Запрашивайте только измерение, требуемое текущим представлением, храните его в памяти, если постоянное хранение не нужно, и объясняйте любое сохранение или передачу. Не классифицируйте человека или устройство по конкретной ширине, соотношению или ориентации.
Выбирайте точки перелома по содержанию
Геометрия viewport описывает текущую презентацию, а не каталог устройств. Интерфейс браузера и масштабирование системы также меняют эти условия.
Сервер может отдать осторожную начальную компоновку, а клиент обновить ее без потери данных, фокуса и навигации.
DevicePixelRatio меняется при масштабировании, поэтому зависимое от масштаба отображение нужно пересчитывать после изменения.
Изображения разной плотности должны сохранять смысл и элементы управления. Выбор ресурса не является причиной удалять действие.
Гибкая компоновка и медиазапросы уменьшают число переломов и необходимость отправлять размеры.
Перед передачей измерения объясните цель, срок хранения, доступ и поведение без передачи.
Проверки с увеличенным текстом должны проверять фокус, кнопки и таблицы, а не только ширину окна.
Смена ориентации должна сохранять полезную прокрутку и доступно сообщать важные состояния.
Компоненты, зависящие от локального пространства, должны реагировать на контейнер и работать в панелях и iframe.
Визуальный эталон описывает тестовую конфигурацию, а не личность того, кто выполняет тест.
После изменения функции удаляйте свойства, которые больше не меняют решение пользователя, и документируйте остальные.
Так компоновка остается объяснимой в новых браузерах и при новых размерах окна.
Учитывайте безопасные области и временный интерфейс
Безопасные области, клавиатура и панели браузера могут временно уменьшить видимое пространство. Считайте их ограничениями отображения.
Сохраняйте семантические элементы и путь восстановления при появлении или исчезновении такого интерфейса.
Явно фиксируйте решения об измерениях и приватности
Перед чтением свойства запишите решение пользователя, которое оно поддерживает. Краткий локальный расчет и хранение всех размеров являются разными практиками.
Ограничивайте сбор полями, которые действительно меняют требуемое представление.
Документируйте практическую матрицу тестов
Записывайте состояние содержимого, диапазон viewport, масштаб, ориентацию, ввод и ожидаемый доступный результат.
Описывайте задачи, которые может выполнить человек, а не только размеры.
Итог
Используйте viewport компоновки для адаптации содержимого, контекст экрана для документированной цели, а devicePixelRatio считайте переменным значением.
Сохраняйте семантические элементы и минимизируйте данные, чтобы поведение оставалось понятным.
Окно может измениться во время задачи, поэтому интерфейс должен оставаться рабочим в переходе.
Значения экрана нельзя использовать вместо явно заданной потребности доступности.
Гибкая компоновка обычно долговечнее списка точных моделей.
Тесты должны использовать реальные длины текста и несколько языков.
Состояния загрузки и ошибки должны оставаться читаемыми при изменении viewport.
Основные действия оставляйте в семантическом HTML даже при включенном визуальном улучшении.
Полезно то измерение, которое приводит к видимому и проверяемому решению.
Источники
Похожие статьи
Переведите BotBrowser из исследований в продакшн
Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.