HIF / Documentation / Adaptation

Responsive and Adaptive Design

Status: normative design and engineering reference

Version: 0.1

This document defines how HIF interfaces respond to changing space, capabilities, preferences and context. The target is not a catalogue of devices. The target is a continuous, stateful interface that remains understandable and operable in every supported environment.

1. Terminology

Responsive behaviour changes continuously with available conditions: flexible flow, tracks, measures, media and type.
Adaptive behaviour selects a materially different composition or interaction pattern at a justified threshold.
Intrinsic design lets content and layout constraints participate in sizing before introducing explicit thresholds.
Layout mode is a named arrangement with defined regions, navigation and state mapping; it is not a device name.
Breakpoint is the condition at which the current composition ceases to satisfy a documented content, task or operability constraint.
Viewport/window is the space currently available to the interface, which may be smaller than a physical display and may change while the interface is active.

“Mobile”, “tablet” and “desktop” MAY describe research contexts but MUST NOT be the sole runtime model. Device identity does not reliably establish window size, posture, input, distance, zoom, accessibility settings or user intent.

2. Invariants and transformations

2.1. Invariants

Across every supported mode, the interface MUST preserve:

object identity and current task;
information and function required for that task;
meaningful reading and focus order;
command meaning and consequence;
accessible name, role, value and state;
entered data, selection, undo and recovery;
permission, privacy and safety boundaries;
status, errors and progress;
access to an equivalent input method;
user preferences and system settings.

Visual position, navigation container, number of panes, representation and density MAY change. Semantics MUST NOT.

2.2. Transformation vocabulary

Use explicit transformations:

Transformation	Meaning	Example
Reflow	same content takes a new line or track arrangement	cards wrap from four columns to one
Resize	a region changes continuously within bounds	reading column grows to its maximum measure
Reposition	an element moves while retaining role and order	actions move below a form
Substitute	one pattern is replaced by an equivalent pattern	navigation rail becomes bottom navigation
Disclose	secondary content remains available on demand	supporting pane becomes a detail route
Prioritise	representation of lower-priority content is reduced	optional metadata moves into an expander
Add	extra space enables simultaneous context	list and selected detail appear together
Remove decoration	non-functional form is reduced	illustration is omitted in constrained space

Content or capability required for the task MUST NOT simply disappear. Substitution MUST include an equivalence and state-transfer contract.

3. Content and task priority

Responsive design begins with priority, not a narrow frame. For each region, record:

task contribution
information value
frequency
urgency
error consequence
dependency
minimum useful representation
alternative access path
simultaneous-context need

Priority is contextual. A secondary panel may become primary during comparison, monitoring, recovery or expert work. Business value MUST NOT automatically override user task priority.

Use this sequence when space contracts:

preserve critical state, task controls and recovery;
preserve content identity and essential context;
reflow and resize flexible content;
substitute an equivalent navigation or component pattern;
move supporting content behind explicit, persistent disclosure;
remove decoration and redundant representation;
reject the layout mode if the task can no longer be completed safely.

Truncation MUST NOT conceal a unique identifier, consequence, error or distinguishing value. Any truncated content requires an accessible path to the whole value that does not depend only on hover.

4. Intrinsic layout

Prefer constraints that express content needs:

normal document flow;
flexible tracks and wrapping;
min-content, max-content, fit-content() and minmax();
bounded fluid sizes using min(), max() and clamp();
logical properties;
aspect ratio where the media has a genuine ratio;
container-relative behaviour for reusable components.

Fixed dimensions MAY be used for known controls, assets or safety bounds, but MUST NOT freeze variable text or content into a presumed frame.

An intrinsic component specification declares:

minimum usable inline and block size;
preferred and maximum measure;
wrapping and overflow policy;
long-word and unbroken-data policy;
child priority and substitution;
container-query thresholds, if any;
behaviour with missing, loading and error content.

Do not add a breakpoint to repair a component whose own sizing contract is undefined.

5. Web layout mechanisms

5.1. Grid and Flexbox

Use CSS Grid for two-dimensional track relationships, aligned regions and layout with explicit rows and columns. Use Flexbox for one-dimensional distribution, wrapping and alignment. Neither mechanism determines semantics.

Visual reordering properties such as order and arbitrary grid placement MUST NOT create a meaningful order that differs from source and focus order. The DOM SHOULD express the smallest meaningful mode first unless another source order is demonstrably more robust.

5.2. Container queries

Use a size container query when a component must respond to the space allocated by its parent rather than the whole viewport. This supports the same component in a main region, sidebar, dialog or embedded surface.

Each query threshold MUST be derived from a failure or opportunity:

below condition
current failure or lost opportunity
new representation
semantic equivalence
supported range

Container query units and style queries MAY be used when support and fallback are defined. Components MUST remain usable when containment or a query feature is unavailable.

5.3. Media queries

Media queries apply to the environment or viewport. Use them for:

viewport range and orientation where content requires it;
input characteristics;
colour scheme, contrast and forced colours;
reduced motion, transparency or data where supported;
print and other media;
display segmentation where supported.

A media query MUST NOT be treated as reliable device detection.

5.4. Capability detection

Use feature queries and runtime capability checks instead of browser or device names. Progressive enhancement MUST begin with a complete core task. Enhanced layout MUST NOT make the fallback semantically incomplete.

6. Breakpoints

Breakpoints are discovered by resizing real content until a documented constraint fails or a materially better task arrangement becomes possible. Relevant signals include:

reading measure exceeds its tested range;
controls collide, wrap ambiguously or fall below target requirements;
labels separate from values;
comparison needs an additional simultaneous pane;
a navigation pattern becomes inefficient or occludes content;
localisation or text enlargement no longer fits;
a safe area, keyboard, hinge or system surface conflicts;
an expert task benefits measurably from more visible data.

Breakpoints SHOULD use relative units where their relationship to text or component size matters. A Product Profile MAY adopt platform window-size classes, but the product MUST still test content between and beyond those thresholds.

Avoid a large set of device-specific breakpoints. Every threshold creates a maintenance boundary and MUST have an owner, rationale and test.

7. Reflow, zoom and magnification

Web content within WCAG scope MUST satisfy the adopted conformance target, including text resize and reflow. At the WCAG 2.2 AA threshold, content is expected to reflow without loss of information or functionality and without two-dimensional scrolling at an equivalent width of 320 CSS pixels, except where two-dimensional layout is essential to usage or meaning.

The exception is narrow: maps, complex diagrams, video, data tables and editing canvases may need two dimensions. The surrounding page, controls, labels and instructions SHOULD still reflow. An essential region MUST be independently operable and clearly bounded.

Test:

browser page zoom, not only simulated viewport width;
text-only enlargement where supported;
operating-system magnification;
custom text spacing;
minimum viewport height as well as width;
focus visibility and scroll-to-focus;
fixed, sticky and modal content for occlusion.

Do not disable zoom through viewport configuration. A responsive layout MUST cooperate with user-agent scaling rather than assume one CSS pixel density.

8. Input and interaction capability

8.1. Concurrent input

People may switch between keyboard, touch, mouse, trackpad, pen, switch, screen-reader gestures and voice without changing devices. The interface MUST NOT lock to the input assumed from form factor.

8.2. Pointer and hover

The pointer, any-pointer, hover and any-hover media features describe capability, not identity. Use them to enhance target spacing or hover affordance while preserving:

keyboard access;
a visible or discoverable non-hover route;
touch and stylus operation;
WCAG target-size and pointer-cancellation requirements;
equivalent information on focus and activation.

Primary commands MUST NOT exist only on hover. Simulated hover on touch MUST NOT be required for task completion.

8.3. Orientation and posture

Do not lock orientation unless essential to the task. Portrait and landscape are insufficient to describe posture: a foldable may be tabletop, book-like, partially folded or flat. Design against available regions and hinge/occlusion information supplied by the platform.

9. Viewports, windows and system surfaces

The available application window can change because of:

resizing and multi-window use;
browser chrome, tabs and developer tools;
virtual keyboard or handwriting panel;
picture-in-picture and overlays;
system bars, notches, rounded corners and home indicators;
fold, hinge or segmented displays;
external display, remote session or casting;
accessibility magnification and text settings.

Use platform safe-area and window-inset APIs. Essential controls and content MUST remain inside visible, operable regions. Decorative backgrounds MAY extend outside the safe area when contrast and clipping remain safe.

On the web, env(safe-area-inset-*) and supported viewport-segment environment variables MAY inform layout. Fallback values and non-segmented behaviour MUST be defined. Do not infer a hinge from viewport width alone.

Height-constrained layouts require explicit testing. A wide but short window may not support the same multi-pane composition as a tall expanded window.

10. Foldables and multi-pane modes

Treat display features as spatial constraints or opportunities:

separating hinge/fold: do not place text, controls or one continuous object across the occlusion;
non-separating fold: avoid precision targets on an unstable crease;
dual region: assign coherent panes rather than splitting arbitrary content;
tabletop: place viewing and control regions according to ergonomics and platform convention;
multi-window: use the application window, never the physical screen, as the layout input.

A list–detail transformation MUST define which pane owns navigation history, focus and selection. When two panes collapse to one, keep the currently engaged pane visible and preserve the list position. When space expands, avoid opening an arbitrary item that the person did not select.

11. Responsive media

11.1. Images

Select an image based on its rendered purpose:

use vector graphics for suitable resolution-independent forms;
use responsive image candidates (srcset, sizes or platform equivalents) to avoid oversized transfers;
use art direction (picture or platform equivalents) only when composition changes materially;
preserve intrinsic dimensions or aspect ratio to prevent layout shift;
crop only within declared focal and safe-content regions;
define alternative text from meaning, not file identity;
respect reduced-data and performance budgets where supported.

Do not load a large asset merely to downscale it. Asset selection MUST account for device pixel density without confusing density with layout size.

11.2. Video, canvas and diagrams

Media controls MUST remain operable after scaling. Provide a full-screen or focused view where detail cannot reflow. Canvas and diagram content require textual or structured alternatives appropriate to the task, not merely a smaller bitmap.

12. Responsive typography

Type MAY vary continuously within Product Profile bounds, but:

body size MUST remain user-scalable;
line height MUST adapt to the face, script and measure;
hierarchy MUST remain distinguishable at every size;
fluid type MUST have tested minimum and maximum values;
viewport units SHOULD be combined with a relative unit so browser zoom and text preferences remain effective;
headings and labels MUST wrap without clipping;
variable font axes MUST use real supported instances and fallbacks.

Do not reduce type simply to preserve a multi-column composition. Change the composition first. Responsive typography MUST be tested with supported scripts, not only Latin sample text.

13. Density adaptation

Layout size and interaction density are related but not identical. A large touch display may require generous targets; a small high-resolution desktop window may use precise input; a distant display needs large type despite ample pixels.

Density MAY respond to an explicit user preference, task profile and known input capability. Automatic changes MUST NOT surprise the user during a task. If input changes, existing controls SHOULD remain stable unless a safe transition is defined.

Density changes MUST NOT:

remove commands or labels;
reduce targets below the supported requirement;
reset scroll, selection or entered data;
alter command consequence;
use raw physical pixels as the human-size model.

14. Localisation and bidirectionality

Responsive design MUST be verified with:

expansion and contraction of translated strings;
languages without spaces and long unbroken identifiers;
right-to-left interface direction;
bidirectional values embedded in labels;
vertical writing where supported;
alternative numeral systems, dates, names and addresses;
input-method editors and composition text.

Use logical properties, directional icons and locale-aware ordering. Mirroring is selective: reading flow and directional navigation may mirror, while physical-world, media-control, brand and data semantics may not.

Do not maintain an independent “RTL layout” that silently diverges. Direction is a supported mode of the same semantic layout contract.

15. State continuity

Layout transitions MUST be state transformations, not remounts that happen to look similar. Preserve:

active object and route;
focus or a documented successor;
selection, cursor and text composition;
scroll position within the continuing region;
expanded/collapsed and disclosure state where still applicable;
draft data, validation and upload progress;
media position;
undo history and pending operation;
announcements of material changes.

If a region moves into a disclosure surface, focus SHOULD follow only when the current interaction requires it; otherwise focus remains stable. Resize events MUST NOT trigger destructive auto-submission, navigation or repeated announcements.

Hydration and client/server rendering MUST produce compatible initial layout. Content SHOULD NOT jump between modes because the server guessed a device.

16. Responsive specification matrix

Every responsive surface SHOULD maintain a matrix:

Dimension	Representative states	Required decision
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 and presentation alternatives
Content state	short, long, empty, loading, error, partial, live	stability and priority
Connectivity/performance	fast, slow, offline, memory constrained	asset choice, progressive enhancement

Not every Cartesian combination needs a separate manual case. Risk analysis selects pairwise and high-risk combinations, while automated tests cover stable invariants.

17. Implementation algorithm

Model the task, content and state independently of viewport.
Define invariants and the minimum complete representation.
Build semantic source order and intrinsic flow.
Add flexible tracks, measures and media sizing.
Resize with real content and identify evidence-based failure/opportunity points.
Define named modes and explicit transformations at those points.
Add container queries for component context and media queries for environment context.
Map state, focus, navigation and scroll between modes.
Add safe-area, keyboard, window-topology and input capability adaptations.
Verify localisation, accessibility preferences and performance fallbacks.
Populate the test matrix and automate invariants.
Evaluate representative tasks while resizing and switching input.

18. Acceptance and QA

18.1. Continuous resize

Drag through every supported width and height, not only named breakpoints.
No content flickers repeatedly between adjacent modes.
No transient width creates overlap, clipping, unreachable controls or an unexplained scrollbar.
The active object, focus, selection and draft survive every mode transition.

18.2. Accessibility

Meaningful order agrees across visual, source, accessibility and focus modes.
Reflow and resize satisfy the adopted WCAG target.
Zoomed focus is not obscured by sticky, fixed or modal regions.
All hover content is available by keyboard and non-hover input.
System font, contrast, motion and data preferences are respected.

18.3. Platform and content

Tests cover actual minimum/maximum resizable windows, split screen, virtual keyboard, safe areas and supported display postures.
Images are no larger than needed for their rendered role and do not cause avoidable layout shift.
Long translation, mixed direction, empty, failed and live-updating content do not corrupt the composition.
Performance is measured in constrained conditions; enhanced layout does not block the core task.

18.4. Task evidence

Representative people MUST be able to begin in one mode and complete in another without losing work or re-learning the interface. Record errors, orientation loss, hidden-function discovery, unintended activation and time spent recovering—not only screenshots at standard widths.