HIF / Документация / Адаптация

Отзывчивый и адаптивный дизайн

Статус: нормативный справочник по дизайну и разработке

Версия: 0.1

Этот документ определяет, как интерфейсы HIF реагируют на меняющиеся пространство, capabilities, preferences и context. Цель — не каталог устройств, а непрерывный stateful interface, остающийся понятным и operable в каждой поддерживаемой среде.

1. Терминология

Responsive behaviour непрерывно меняется с доступными условиями: flexible flow, tracks, measures, media и type.
Adaptive behaviour выбирает существенно другую composition или interaction pattern на обоснованном threshold.
Intrinsic design позволяет content и layout constraints участвовать в sizing до введения явных thresholds.
Layout mode — именованное расположение с определёнными regions, navigation и state mapping; это не название устройства.
Breakpoint — условие, в котором текущая composition перестаёт удовлетворять документированному content, task или operability constraint.
Viewport/window — пространство, доступное интерфейсу сейчас; оно может быть меньше физического display и меняться во время активности интерфейса.

«Mobile», «tablet» и «desktop» MAY описывать research contexts, но MUST NOT быть единственной моделью выполнения. Идентичность устройства не определяет надёжно размер окна, положение, способ ввода, расстояние, масштаб, настройки доступности или намерение пользователя.

2. Инварианты и трансформации

2.1. Инварианты

Во всех поддерживаемых modes интерфейс MUST сохранять:

object identity и current task;
информацию и функции, необходимые для этой задачи;
meaningful reading и focus order;
значение и последствия command;
accessible name, role, value и state;
введённые data, selection, undo и recovery;
permission, privacy и safety boundaries;
status, errors и progress;
доступ к равнозначному input method;
user preferences и system settings.

Visual position, navigation container, количество panes, representation и density MAY меняться. Semantics MUST NOT.

2.2. Словарь трансформаций

Используются явные transformations:

Трансформация	Значение	Пример
Reflow	то же content получает новое расположение строк или tracks	cards переносятся с четырёх columns в одну
Resize	region непрерывно меняется в заданных bounds	reading column растёт до maximum measure
Reposition	element перемещается, сохраняя role и order	actions перемещаются под form
Substitute	одна pattern заменяется равнозначной	navigation rail становится bottom navigation
Disclose	secondary content остаётся доступным по запросу	supporting pane становится detail route
Prioritise	представление lower-priority content сокращается	optional metadata перемещаются в expander
Add	дополнительное пространство позволяет одновременный context	list и selected detail показываются вместе
Remove decoration	нефункциональная форма сокращается	illustration исключается в constrained space

Необходимые задаче content или capability MUST NOT просто исчезать. Substitution MUST включать equivalence и state-transfer contract.

3. Приоритет содержания и задачи

Responsive design начинается с priority, а не с узкого frame. Для каждой region фиксируются:

вклад в задачу
информационная ценность
частота
срочность
последствие ошибки
зависимость
минимальное полезное представление
альтернативный путь доступа
необходимость одновременного контекста

Priority контекстуален. Secondary panel может стать primary при comparison, monitoring, recovery или expert work. Business value MUST NOT автоматически переопределять user task priority.

При сжатии пространства применяется последовательность:

сохранить critical state, task controls и recovery;
сохранить content identity и essential context;
выполнить reflow и resize гибкого content;
заменить navigation или component pattern равнозначной;
переместить supporting content за явный постоянный disclosure;
убрать decoration и redundant representation;
отклонить layout mode, если задача больше не выполняется безопасно.

Truncation MUST NOT скрывать unique identifier, consequence, error или distinguishing value. Для любого truncated content нужен accessible path к полному value, не зависящий только от hover.

4. Intrinsic layout

Предпочтительны constraints, выражающие потребности content:

normal document flow;
flexible tracks и wrapping;
min-content, max-content, fit-content() и minmax();
bounded fluid sizes через min(), max() и clamp();
logical properties;
aspect ratio, когда media имеет подлинное соотношение;
container-relative behaviour для reusable components.

Fixed dimensions MAY использоваться для известных controls, assets или safety bounds, но MUST NOT замораживать variable text или content в предполагаемом frame.

Specification intrinsic component объявляет:

minimum usable inline и block size;
preferred и maximum measure;
wrapping и overflow policy;
long-word и unbroken-data policy;
child priority и substitution;
container-query thresholds, если есть;
behaviour с missing, loading и error content.

Breakpoint не добавляется для исправления component с неопределённым собственным sizing contract.

5. Механизмы web layout

5.1. Grid и Flexbox

CSS Grid используется для двумерных track relationships, aligned regions и layout с явными rows и columns. Flexbox используется для одномерных distribution, wrapping и alignment. Ни один механизм не определяет semantics.

Visual reordering properties вроде order и произвольный grid placement MUST NOT создавать meaningful order, отличающийся от source и focus order. DOM SHOULD выражать наименьший meaningful mode первым, если другой source order не является доказанно более устойчивым.

5.2. Container queries

Size container query используется, когда component должен реагировать на пространство, выделенное parent, а не на весь viewport. Это поддерживает один component в main region, sidebar, dialog или embedded surface.

Каждый query threshold MUST выводиться из failure или opportunity:

условие ниже порога
текущий отказ или упущенная возможность
новое представление
семантическая эквивалентность
поддерживаемый диапазон

Единицы контейнерных запросов и запросы стиля MAY использоваться, когда определены поддержка и резервный вариант. Компоненты MUST оставаться пригодными, если ограничение контейнера или возможность запроса недоступны.

5.3. Медиазапросы

Media queries относятся к environment или viewport. Они используются для:

viewport range и orientation, где этого требует content;
input characteristics;
colour scheme, contrast и forced colours;
reduced motion, transparency или data, где поддерживается;
print и других media;
display segmentation, где поддерживается.

Media query MUST NOT считаться надёжным device detection.

5.4. Обнаружение возможностей

Feature queries и runtime capability checks используются вместо browser или названий устройств. Прогрессивное улучшение MUST начинаться с полной основной задачи. Улучшенная компоновка MUST NOT делать резервный вариант семантически неполным.

6. Breakpoints

Breakpoints обнаруживаются изменением размера реального content до момента, когда нарушается документированный constraint или становится возможным существенно лучшее task arrangement. Значимые сигналы:

reading measure выходит из проверенного range;
controls сталкиваются, переносятся неоднозначно или становятся меньше target requirements;
labels отделяются от values;
comparison требует дополнительного simultaneous pane;
navigation pattern становится неэффективной или закрывает content;
localisation или text enlargement больше не помещается;
safe area, keyboard, hinge или system surface конфликтует;
expert task получает измеримую пользу от большего объёма visible data.

Breakpoints SHOULD использовать relative units, когда важна связь с text или component size. Product Profile MAY принять platform window-size classes, но product всё равно MUST тестировать content между thresholds и за их пределами.

Следует избегать большого набора точек перелома для конкретных устройств. Каждый порог создаёт границу сопровождения и MUST иметь ответственного, обоснование и проверку.

7. Reflow, zoom и magnification

Веб-содержание в области WCAG MUST соответствовать принятому целевому уровню соответствия, включая увеличение текста и перекомпоновку. На уровне AA WCAG 2.2 содержание должно перестраиваться без потери информации или функций и без двумерной scrolling при эквивалентной ширине 320 CSS pixels, кроме случаев, когда двумерная layout существенна для использования или смысла.

Исключение узко: maps, complex diagrams, video, data tables и editing canvases могут требовать два измерения. Окружающие page, controls, labels и instructions SHOULD всё равно перестраиваться. Essential region MUST быть независимо operable и ясно ограниченной.

Проверяются:

browser page zoom, а не только simulated viewport width;
text-only enlargement, где поддерживается;
operating-system magnification;
custom text spacing;
minimum viewport height наряду с width;
focus visibility и scroll-to-focus;
fixed, sticky и modal content на occlusion.

Zoom не отключается через viewport configuration. Responsive layout MUST сотрудничать с user-agent scaling, а не предполагать одну CSS pixel density.

8. Возможности ввода и взаимодействия

8.1. Одновременный ввод

Люди могут переключаться между клавиатурой, сенсорным вводом, мышью, трекпадом, пером, переключателем, жестами программы экранного доступа и голосом без смены устройства. Интерфейс MUST NOT фиксироваться на способе ввода, предполагаемом из форм-фактора.

8.2. Указатель и наведение

Media features pointer, any-pointer, hover и any-hover описывают capability, а не identity. Они используются для улучшения target spacing или hover affordance с сохранением:

keyboard access;
видимого или discoverable non-hover route;
touch и stylus operation;
WCAG target-size и pointer-cancellation requirements;
равнозначной информации при focus и activation.

Primary commands MUST NOT существовать только на hover. Simulated hover на touch MUST NOT быть необходимым для завершения задачи.

8.3. Orientation и posture

Orientation не блокируется, если это не существенно для задачи. Portrait и landscape недостаточно описывают posture: foldable может быть tabletop, book-like, partially folded или flat. Design строится по доступным regions и hinge/occlusion information, предоставленным platform.

9. Viewports, окна и системные поверхности

Доступное application window может меняться из-за:

resizing и multi-window use;
browser chrome, tabs и developer tools;
virtual keyboard или handwriting panel;
picture-in-picture и overlays;
system bars, notches, rounded corners и home indicators;
fold, hinge или segmented displays;
external display, remote session или casting;
настройки экранного увеличения и текста.

Используются platform safe-area и window-inset APIs. Essential controls и content MUST оставаться внутри видимых operable regions. Decorative backgrounds MAY выходить за safe area, если contrast и clipping остаются безопасными.

В вебе env(safe-area-inset-*) и поддерживаемые переменные сегментов области просмотра MAY влиять на компоновку. Резервные значения и поведение без сегментов MUST быть определены. Наличие сгиба нельзя выводить только из ширины области просмотра.

Height-constrained layouts требуют явного тестирования. Широкое, но низкое window может не поддерживать ту же multi-pane composition, что высокое expanded window.

10. Foldables и multi-pane modes

Display features рассматриваются как spatial constraints или opportunities:

separating hinge/fold: text, controls или единый continuous object не помещаются через occlusion;
non-separating fold: precision targets не размещаются на нестабильной crease;
dual region: назначаются coherent panes, а не разрезается произвольный content;
tabletop: viewing и control regions располагаются согласно ergonomics и platform convention;
multi-window: layout input — application window, а не physical screen.

List–detail transformation MUST определять, какой pane владеет navigation history, focus и selection. При сворачивании двух panes в один текущий engaged pane остаётся видимым, а list position сохраняется. При расширении пространства не открывается произвольный item, который человек не выбирал.

11. Responsive media

11.1. Изображения

Изображение выбирается по его rendered purpose:

vector graphics используются для подходящих resolution-independent forms;
responsive image candidates (srcset, sizes или platform equivalents) предотвращают oversized transfers;
art direction (picture или platform equivalents) используется, только когда composition существенно меняется;
intrinsic dimensions или aspect ratio сохраняются для предотвращения layout shift;
crop выполняется только в объявленных focal и safe-content regions;
alternative text определяется смыслом, а не file identity;
учитываются reduced-data и performance budgets, где поддерживается.

Большой asset не загружается только ради downscale. Asset selection MUST учитывать device pixel density, не смешивая density с layout size.

11.2. Video, canvas и diagrams

Media controls MUST оставаться operable после scaling. Предоставляется full-screen или focused view, где detail не может reflow. Canvas и diagram content требуют текстовых или структурированных alternatives, соответствующих задаче, а не только уменьшенного bitmap.

12. Responsive typography

Type MAY непрерывно меняться в bounds Product Profile, но:

body size MUST оставаться user-scalable;
line height MUST адаптироваться к face, script и measure;
hierarchy MUST оставаться различимой при любом size;
fluid type MUST иметь проверенные minimum и maximum values;
viewport units SHOULD сочетаться с relative unit, чтобы browser zoom и text preferences оставались эффективными;
headings и labels MUST переноситься без clipping;
variable font axes MUST использовать реальные supported instances и fallbacks.

Type не уменьшается только ради сохранения multi-column composition. Сначала меняется composition. Responsive typography MUST тестироваться на поддерживаемых scripts, а не только на Latin sample text.

13. Адаптация плотности

Layout size и interaction density связаны, но не тождественны. Большой touch display может требовать generous targets; маленькое high-resolution desktop window может использовать precise input; distant display требует крупного type при большом числе pixels.

Density MAY реагировать на явную user preference, task profile и известную input capability. Automatic changes MUST NOT удивлять пользователя во время задачи. Если input меняется, существующие controls SHOULD оставаться стабильными, если не определён safe transition.

Изменения density MUST NOT:

удалять commands или labels;
уменьшать targets ниже поддерживаемого requirement;
сбрасывать scroll, selection или введённые data;
изменять command consequence;
использовать raw physical pixels как human-size model.

14. Localisation и bidirectionality

Responsive design MUST проверяться с:

expansion и contraction переведённых строк;
языками без spaces и long unbroken identifiers;
right-to-left interface direction;
bidirectional values внутри labels;
vertical writing, где поддерживается;
альтернативными numeral systems, dates, names и addresses;
input-method editors и composition text.

Используются logical properties, directional icons и locale-aware ordering. Mirroring выборочен: reading flow и directional navigation могут отражаться, а physical-world, media-control, brand и data semantics — нет.

Отдельная «RTL layout», способная незаметно расходиться, не поддерживается. Direction — поддерживаемый mode того же semantic layout contract.

15. Непрерывность состояния

Layout transitions MUST быть state transformations, а не remounts, которые только выглядят сходно. Сохраняются:

active object и route;
focus или документированный successor;
selection, cursor и text composition;
scroll position внутри продолжающейся region;
expanded/collapsed и disclosure state, где ещё применимо;
draft data, validation и upload progress;
media position;
undo history и pending operation;
announcements существенных changes.

Если region перемещается в disclosure surface, focus SHOULD следовать только тогда, когда этого требует текущий interaction; иначе focus остаётся стабильным. Resize events MUST NOT вызывать destructive auto-submission, navigation или повторяющиеся announcements.

Hydration и client/server rendering MUST создавать совместимую initial layout. Content SHOULD NOT прыгать между modes из-за того, что server угадал device.

16. Матрица responsive specification

Каждая responsive surface SHOULD поддерживать matrix:

Измерение	Репрезентативные состояния	Обязательное решение
Inline size	minimum, constrained, intermediate, expanded, maximum	modes, tracks, measure, overflow
Block size	short, typical, tall	sticky regions, virtual keyboard, pane viability
Zoom/text	default, 200% text, 400% page zoom, custom spacing	reflow, focus, occlusion
Input	keyboard, coarse pointer, fine pointer, pen, AT	targets, hover alternatives, order
Direction/script	LTR, RTL, longest translation, mixed bidi	logical flow, icons, wrapping
Window topology	single, multi-window, segmented, folded	safe regions, panes, continuity
Preference	contrast, forced colours, reduced motion/data	media и presentation alternatives
Content state	short, long, empty, loading, error, partial, live	stability и priority
Connectivity/performance	fast, slow, offline, memory constrained	asset choice, progressive enhancement

Не каждой Cartesian combination нужен отдельный manual case. Risk analysis выбирает pairwise и high-risk combinations, а automated tests покрывают стабильные invariants.

17. Алгоритм реализации

Смоделировать task, content и state независимо от viewport.
Определить invariants и minimum complete representation.
Построить semantic source order и intrinsic flow.
Добавить гибкие направляющие, размеры и масштабирование медиа.
Изменять размер с реальным содержанием и найти подтверждённые доказательствами точки отказа или улучшения.
Определить named modes и явные transformations в этих points.
Добавить container queries для component context и media queries для environment context.
Сопоставить state, focus, navigation и scroll между modes.
Добавить safe-area, keyboard, window-topology и input capability adaptations.
Проверить локализацию, настройки доступности и резервные варианты производительности.
Заполнить матрицу проверок и автоматизировать инварианты.
Оценить репрезентативные задачи при resize и смене input.

18. Приёмка и QA

18.1. Непрерывный resize

Выполняется drag через каждую поддерживаемую width и height, а не только именованные breakpoints.
Content не мерцает многократно между соседними modes.
Ни одна transient width не создаёт overlap, clipping, недоступные controls или необъяснимый scrollbar.
Active object, focus, selection и draft переживают каждый mode transition.

18.2. Доступность

Смысловой порядок совпадает в визуальном представлении, исходном коде, доступности и фокусе.
Перекомпоновка и изменение размера соответствуют принятой цели WCAG.
Zoomed focus не закрывается sticky, fixed или modal regions.
Всё hover content доступно через keyboard и non-hover input.
System font, contrast, motion и data preferences соблюдаются.

18.3. Платформа и содержание

Тесты покрывают реальные minimum/maximum resizable windows, split screen, virtual keyboard, safe areas и поддерживаемые display postures.
Images не крупнее необходимого для rendered role и не вызывают предотвратимый layout shift.
Long translation, mixed direction, empty, failed и live-updating content не разрушают composition.
Performance измеряется в constrained conditions; enhanced layout не блокирует core task.

18.4. Свидетельства по задачам

Репрезентативные люди MUST иметь возможность начать в одном mode и завершить в другом без потери работы или повторного изучения интерфейса. Фиксируются errors, orientation loss, обнаружение hidden-function, unintended activation и время recovery, а не только screenshots на стандартных widths.