Design Guidelines

Responsive Design Guidelines

For designers and engineers: let users still read content, complete tasks, and continue from where they just were, as the window, container, orientation, and input environment change.

6 principles · 24 rules · MUST 19 · SHOULD 5

Contents

For designers and engineers: let users still read content, complete tasks, and continue from where they just were, as the window, container, orientation, and input environment change.

Responsive design requires defining product behavior when space changes: which content stays continuously visible, which content may collapse, when the layout reflows, and how task state and action entries continue after the change.

These guidelines consist of six principles, 24 rules, layout examples, and an acceptance checklist. The companion files are Design Token and Reference Sources and Evidence Boundaries. The breakpoints, spacing, and layout examples in this document are suggested starting configurations that have not yet been through user research or browser testing for a specific product.

1. Scope and how to read

1.1 Scope

Primarily applicable to web sites, business systems, workbenches, and Agent interfaces, covering viewport scaling, browser split-screen, resizable panels, portrait/landscape, text scaling, soft keyboards, and mixed-input scenarios. Native apps MAY reference the behavioral principles, but size units and platform interactions need separate mapping; CSS px is not directly equivalent to device physical pixels, iOS pt, or Android dp.

These guidelines govern the expression and continuity of the same interface across different amounts of available space. Layout adjustments MUST NOT change the object being operated on, the meaning of submission, or saved work state. Printing, embedded pages, vertical text, and foldable screens enter the acceptance scope only when the product declares support for them; no interface needs to be added for capability that is not provided.

1.2 Normative terms

MUST / MUST NOT: necessary requirements for conformance with these guidelines.
SHOULD / SHOULD NOT: follow by default; when deviating, record the specific reason, alternative, and verification result.
MAY: optional implementation, not a capability every product needs to add.

Judgments take the independent obligation clauses in the main text as their unit: a declarative sentence without a normative term carries the strength of its rule heading; a clause with an explicit normative term is judged at its own strength — a MUST/MUST NOT/forbidden clause inside a SHOULD rule remains a hard requirement, and strength annotations on rule headings do not replace clause-level binding force. Prohibited behavior is always expressed with "MUST NOT"; "cannot" is used only for statements of fact or capability, never for obligations. Examples, design applications, and counterexamples reveal requirements and failure paths; they add no obligations.

Principles explain the design direction and are not independent judgment items. The applicability and boundaries within a rule qualify the main-text requirement; the examples in Chapter 4 and the counterexamples in Chapter 5 add no further obligations. Each rule states applicability, requirements, and verification. Examples help explain requirements and do not designate a sole component or engineering framework. Source numbers link to reference.md; project rules derived from sources do not impersonate the source's original text. Satisfying this document alone does not prove conformance with the full WCAG 2.2.

2. The six principles

Principle	Governed object	Design direction	Rules
R1 The core task stays continuously reachable	Trade-offs between content and actions	Adjust the presentation hierarchy as space changes, retaining the information and entries needed to complete the task	R1-1～R1-4
R2 Layout is based on actual space	Measurement range and structural switching	Decide layout changes based on the actual carrying capacity of the viewport or container	R2-1～R2-4
R3 Content stays readable	Typography, scaling, and overflow	Natural flow, reasonable width constraints, special handling for two-dimensional content	R3-1～R3-4
R4 Operation stays continuous through change	User input, focus, and position	After a layout switch, the user can continue from where they just were	R4-1～R4-4
R5 Interaction adapts to input and preference	Input capability, hit targets, and motion	Handle space, input method, density, and user preference separately	R5-1～R5-4
R6 Design decisions are implementable and verifiable	Delivery, tokens, and acceptance	Write down the change conditions, the source of values, and the pass conditions clearly	R6-1～R6-4

Each rule belongs to one principle by its direct object of constraint; the same scenario can trigger several rules at once. For example, the entry point after a panel collapses belongs to R1, how focus returns to that entry belongs to R4, and the entry's touch target belongs to R5. This is a division of responsibility for ease of maintenance, and does not claim to have passed empirical testing for completeness or mutual exclusivity.

3. Rules in detail

R1 The core task stays continuously reachable

R1-1Clarify content and action priorityMUST

Applies tothe same page needing to present different information density in different amounts of space.

Requirement: MUST distinguish, by user task, the current primary content, primary action, information needed for judgment, and auxiliary content. When the layout narrows, the path to completing the current task MUST be retained; submission, cancellation, error correction, or necessary explanation MUST NOT be removed merely for lack of width.

VerificationComplete the same task separately in a narrow window and a wide window. Check whether the user can obtain the same necessary information and usable result, rather than merely comparing whether a same-named button exists in screenshots.

R1-2Collapsed content retains a clear entry pointMUST

Applies tonavigation, toolbars, filters, or auxiliary panels that collapse.

Requirement: Collapsed content MUST have a discoverable, operable entry point, and the entry's name or context MUST be able to explain its purpose. When existing filters, selected items, or pending matters affect the current result, the corresponding indication MUST be retained. MUST NOT rely on hover alone to find functionality after it collapses.

VerificationHave the user modify an already-enabled filter while the panel is collapsed; check whether they can understand why the current result is filtered and find where to change it.

R1-3Layout does not change the semantics of an actionMUST

Applies tothe same action changing position, appearance, or carrying component across different layouts.

Requirement: The object, permission, submission timing, and consequences of the same action MUST remain consistent. Switching a popup for a full-screen page MUST NOT, in passing, turn "preview" into "publish," or interpret closing the interface as consenting to the action. When a business difference genuinely exists, the difference MUST be explained before the action.

VerificationCompare the state changes and business requests of the same action under wide and narrow layouts, rather than only checking the copy.

R1-4Agent state and control entries stay continuously reachableMUST

Applies tointerfaces presenting Agent execution, requests pending confirmation, or results.

Requirement: After the execution area collapses, the current state and an entry back to execution detail MUST be retained. When a task supports stopping, the stop entry MUST remain reachable; matters pending confirmation MUST have a discoverable indicator and be able to open complete information sufficient to judge the consequences. Window changes MUST NOT re-initiate execution, auto-confirm a request, or treat a hidden panel as equivalent to stopping the task.

VerificationNarrow the window during execution, then test stopping, opening pending-confirmation items, and viewing results in sequence. Check that the task identifier and execution count remain consistent.

R2 Layout is based on actual space

R2-1Use a clearly defined measurement scope for spaceMUST

Applies toany layout change triggered by size.

Requirement: MUST make clear whether the rule measures the page viewport or a designated container. Device model or physical screen resolution MUST NOT substitute for available layout space. Pages SHOULD adjust overall structure based on the viewport; reusable components SHOULD adjust internal arrangement based on the container they are in.

Measurement boundary: MUST declare whether it is physical width or logical inline size, and keep the query axis, tokens, and acceptance records consistent. A container query MUST specify the ancestor container responsible for measurement; size changes a component causes in itself through style changes MUST NOT cause repeated toggling.

VerificationIn the same wide window, place the same component into the main area and a narrow side panel respectively, and check whether each adapts. Technical reference S03

R2-2Breakpoints are calibrated by content-carrying capacitySHOULD

Applies toestablishing page or component breakpoints.

Requirement: SHOULD first determine the minimum usable width, spacing, and content constraints of the primary area, then determine the structural-switch threshold. SHOULD calibrate breakpoints using long text, enlarged text, and real content. A default preset MAY use 640 / 1024 CSS px, but this MUST NOT be stated as a universal standard breakpoint for all products.

VerificationRecord the specific problem that appears before the switch, such as "primary content cannot fit the necessary fields," rather than merely writing "entered tablet size."

R2-3Define scaling first, then define structural switchingSHOULD

Applies tocard collections, forms, toolbars, and multi-column content.

Requirement: SHOULD prioritize natural wrapping, flexible space, minimum width, and maximum width; switch structure only when these methods can no longer sustain usability. Each structural state SHOULD state its arrangement, scroll area, and the position of the primary action. Content-carrying problems MUST NOT be masked by shrinking the whole interface.

Capability fallback: If the layout depends on container queries, script measurement, or deferred layout configuration, a baseline arrangement for when the capability is unavailable MUST be predefined. The switch from the first-screen layout to the enhanced layout MUST NOT clear input or re-present focusable controls.

VerificationDrag the window continuously and check whether widths between fixed screenshots remain usable, and whether unnecessary layout jumps occur; after disabling the enhancement mechanism, verify that the basic task can still be completed. Design reference S01, S02

R2-4Height, orientation, and keyboard entry into space judgmentMUST

Applies tolandscape orientation, low-height windows, fixed action bars, input fields, and soft-keyboard scenarios.

Requirement: MUST ensure the current input, necessary context, and the next action can be accessed. When space is insufficient, MAY scroll, collapse auxiliary areas, or cancel fixed positioning. The height of a fixed area MUST NOT be decided by width alone. Except where a specific orientation is essential to the nature of the function, use MUST NOT be restricted to landscape-only or portrait-only.

BoundaryThe layout viewport, the visual viewport, and container size MUST be identified separately. A soft keyboard may shrink only the visual viewport; neither 100dvh nor the safe-area inset MUST be treated as a cross-browser universal guarantee of keyboard avoidance. Fixed-area implementations MUST have a fallback to become scrollable or return to document flow; system occlusion and author-content occlusion are recorded separately. Mechanism S16

VerificationComplete a long form and error correction in landscape orientation and while the soft keyboard is open; check whether fixed areas and the safe area occlude input or submission. For orientation requirements see S09; keyboard handling is a design requirement of these guidelines.

R3 Content stays readable

R3-1Regular content supports reflowMUST

Applies toregular reading content, forms, and page control areas on the Web.

Requirement: Vertically scrolling content MUST be presentable at an equivalent 320 CSS px width without losing information or function, and without requiring two-dimensional scrolling; horizontally scrolling content corresponds to an equivalent 256 CSS px height. Areas that genuinely require a two-dimensional layout because of their purpose or meaning are handled separately under R3-4.

VerificationCheck the page, headings, search box, pagination, and prompt content, not only the body. On desktop, a 1280 CSS px viewport with 400% page zoom can construct a roughly 320 CSS px test condition; the actually measured viewport governs. WCAG 1.4.10, S06

R3-2Text allows scaling up and natural growthMUST

Applies tobody text, headings, labels, prompts, and text controls.

Requirement: Except for the captions and images-of-text exceptions in WCAG 1.4.4, text MUST be scalable to 200% through means supported by the user agent, without losing content or function. Breakpoint rules MUST NOT be used to cancel out reaching the required scale.

Scope of the line-wrapping obligation: Ordinary text containers carrying body text, headings, labels, and prompts SHOULD be able to wrap and grow naturally; controls that genuinely require single-line display or truncated summaries (single-line inputs, table column headers, tab names, etc.) are not forced to wrap by this rule, but MUST provide a discoverable and operable way to obtain the full content (expansion on focus or activation, a detail page; hover can only be a supplement). Forced wrapping MUST NOT be used to break a control's purpose, nor may "there is a full-text entry" be used as a reason to truncate ordinary body text across the board.

User override of text spacing: The author's default line height and the user's spacing override are two different things. For content that supports the corresponding text styling, when the user sets line height to 1.5 times the font size, spacing after paragraphs to 2 times, letter spacing to 0.12 times, and word spacing to 0.16 times, without changing any other style, content or function MUST NOT be lost. Where a language or writing system does not use a given property, handle it as an exception under WCAG 1.4.12 and record the reason. This set of test values is the acceptance condition after the override, not the floor for the default token — a heading's default line height of 1.25 is not a violation because of this.

VerificationTest intermediate states from 100% to 200%, long Chinese headings, longer translated text, and continuous strings; check whether buttons, inputs, and error messages are clipped. Fluid font size cannot be verified with the default scale alone.

Scale factor must be recorded by actual ratio, not by menu step: Record three items — initial font size, current font size, and actual visual scale factor — and confirm there exists a supported way to reach 200% scaling relative to the initial text. The actual scale factor at the same step differs across breakpoints — for example, in a 1440 CSS px window with an initial heading of 40px, after 200% page zoom the layout width becomes about 720 CSS px and the heading becomes 32px, for a visual factor of about 1.6; the same design can reach about 2.1 at the 300% step. Therefore conformance or violation MUST NOT be judged directly from the factor at one particular step; the criterion is "a supported way to reach 200% exists." If a product makes the additional, stronger commitment that "200% at the menu equals 200% of text," verify that commitment separately.

Text-spacing override: Apply the applicable-property override separately for Chinese, Latin script, and the target language, in a narrow window, on both sides of the actual breakpoint, and in the form error state; keep the default font size, and check button labels, card summaries, menus, and error prompts. Record, item by item, which properties do not apply and why. WCAG 1.4.4, S07; 1.4.12, S14

R3-3Content width and information density are controlled separatelySHOULD

Applies toreading pages, forms, data workbenches, and ultra-wide windows.

Requirement: SHOULD set width constraints by content type. Reading content SHOULD retain white space once it reaches a suitable line length; a workbench MAY put extra space to use for side-by-side comparison or auxiliary content. Text lines MUST NOT be stretched indefinitely, controls enlarged, or unnecessary information added merely to fill the window. Density SHOULD be decided by task and input needs, not automatically vary with screen width.

Language and direction: A declared-supported language MUST be verified with real, long content. Logical direction SHOULD be used to express margins and arrangement; visual reversal MUST NOT be used to break reading meaning. When RTL text is mixed with numbers and identifiers, the correspondence between labels and objects MUST be maintained. ch measures the advance width of the "0" glyph, and ic depends on the font's ideographic-character metric; neither can guarantee a fixed character count. Mechanism S18

VerificationComplete reading and comparison tasks in an ultra-wide window; check whether the extra space has an actual use. Chinese and Latin-script line length SHOULD be checked separately; do not treat ch as a universal unit for counting Chinese characters.

R3-4Overflow of two-dimensional content has a boundaryMUST

Applies todata tables, maps, charts, code, and editing canvases.

Requirement: Content that genuinely requires a two-dimensional layout MUST have a clearly defined operable area and retain the necessary row/column relationships, coordinates, or comparison relationships. Ordinary tables SHOULD prioritize confining horizontal scrolling within the table container; the exception MUST NOT extend to unrelated page titles, search, or pagination. Individual cells still need to be checked against reflow requirements based on their own content.

Featured columns with detail views, localized horizontal scrolling, or a zoomable canvas MAY be adopted by task; tables MUST NOT be converted to cards across the board in a way that breaks comparison tasks. Ordinary code text does not automatically gain the two-dimensional-layout exception merely by "being code" — wrapping or another access method SHOULD be evaluated first.

VerificationIn a narrow viewport, look up fields in the same row, compare two records, and access the scroll area by keyboard; check whether the whole page is stretched wide by unrelated content. Exception boundary S06

R4 Operation stays continuous through change

R4-1Input and business state do not reset with layoutMUST

Applies toscenarios where a window change reflows, replaces, or remounts the interface.

Requirement: Content already entered, selections, filter conditions, and the current task state MUST be retained. A structural switch MUST NOT cause repeated submission, task re-creation, or overwrite edits the user has not yet submitted. A change to a component's visual instance MUST NOT be used as grounds for resetting business state.

VerificationEnter unsubmitted content, repeatedly resize the window near the breakpoint, then continue editing and submit; check that the content is intact and the business action happens only once.

R4-2Focus and reading order have continuityMUST

Applies toreflow, panel collapse, drawer, or dialog form switches.

Requirement: During a layout switch, the criterion is whether the focused object's identity, order, and visibility continue to hold, not "the control is still there and still clickable":

When the equivalent object holding focus still exists and is usable, focus MUST remain on that object — a control being clickable while activeElement has already returned to body or the document root counts as a failure.
When an object is going to be hidden or replaced, the component design record MUST give a determinate successor target and recovery rule; it MUST NOT merely say "hand off to a reasonable object."
When there is no focus within the changing area, reflow MUST NOT actively grab focus.
Visual ordering MUST NOT be used to produce a keyboard or assistive-technology reading order that breaks meaning or operation.

VerificationPlace focus in three positions — the save button, inside a drawer, and outside the changing area — respectively, then switch across a breakpoint; for each case check the focused object, where the next Tab lands, and the return path after closing. On the user side, the user MUST be able to state where they currently are and continue operating; on the implementation side, record activeElement, the equivalent-object identifier, hidden state, and the containing scroll container. When a modal becomes a persistent panel, check whether the original focus constraint has been released. Focus order reference S10; the cross-layout succession approach is derived by these guidelines and does not require a specific DOM architecture.

R4-3Retain the semantic reading position and a return pathSHOULD

Applies tolist–detail, long-form text, chat, and multi-step forms.

Requirement: SHOULD prioritize retaining the current reading object, selected record, or current step, rather than mechanically retaining the same scroll pixel position. When two columns become one, a comprehensible return path SHOULD be provided, and context SHOULD be restored after returning. A width adjustment MUST NOT automatically navigate to the home page or the top of the list.

Media and asynchronous content: Images and video carrying task information MUST define a scaling, cropping, or image-swap strategy; information necessary to complete the task MUST NOT be cropped out without providing a way to access the full content. When media, fonts, or asynchronous content are loading, space SHOULD be reserved or a semantic anchor maintained, to avoid the current reading object and action target abruptly shifting. Image mechanism S17

VerificationSwitch layout after reading the detail of an item in the middle of a list, then return to the list, and check whether the selected item and neighboring content are easy to find; add retries with deferred-loading images and font-load-failure scenarios.

R4-4Fixed areas and dynamic content do not seize controlMUST

Applies tofixed navigation, bottom action bars, streaming output, and auto-scroll.

Requirement: Fixed areas MUST NOT make key content and actions inaccessible. When a component receives keyboard focus, it MUST NOT be completely obscured by an author-created fixed area; the applicable exceptions (content the user has moved themselves, content the user has actively opened) are judged under WCAG 2.4.11. It SHOULD make the focused object fully visible wherever possible — "not obscured at all" is a higher goal, not the pass floor for this rule; "visible after a bit of scrolling" does not constitute "focus is currently visible." While the user is reading historical content or editing, a layout change or new content arriving MUST NOT unconditionally grab focus, reset the selection, or scroll to the bottom. When an update needs to be signaled, an entry point to the new content MAY be provided.

VerificationRead old messages in a narrow window while new messages arrive, the keyboard opens, and panels switch; check whether position stays controllable. Fixed areas and reflow S06; Focus occlusion S15

R5 Interaction adapts to input and preference

R5-1Input capability is not inferred from widthMUST

Applies tomouse, touch, stylus, keyboard, and mixed input.

Requirement: A wide window MUST NOT be equated with a precise pointer, nor a narrow window with touch. Hover MAY provide enhanced feedback, but key actions and necessary explanations MUST have a click, focus, or other usable entry. A change of input method MUST NOT cause an existing task to lose its path to completion.

VerificationComplete the task using touch in a wide window, and using the keyboard in a narrow window. Capability queries MAY assist style selection, but cannot substitute for actual task verification. S12

R5-2Hit target and visible size are defined separatelyMUST

Applies tolinks, buttons, icon actions, and interactive chart elements.

Requirement: Visible icon size, control size, and the actual hit area MUST be distinguished. Web pointer targets MUST satisfy the WCAG 2.5.8 24×24 CSS px requirement or its explicit exceptions. Important touch actions SHOULD take at least 44×44 CSS px as this project's initial design target, then verify spacing and actual operating performance; this recommendation MUST NOT be written up as a uniform WCAG AA value.

VerificationCheck the actual hit area and adjacent targets to avoid overlap after enlarging hit areas; enlarging the icon alone does not mean the hit area already meets the requirement. S08

R5-3Density is an independent design dimensionSHOULD

Applies toproviding compact/comfortable density, or a high-information-volume workbench.

Requirement: Density SHOULD be chosen based on task, input method, or an explicit preference, and SHOULD NOT be locked to viewport state. When density is increased, reading, operation, and zoom requirements must still be met. The space state compact and the density dense MUST be distinguished in naming and values.

VerificationCheck whether both "narrow window + comfortable density" and "wide window + compact density" are usable. Products with no density need do not need to add a settings entry.

R5-4Layout motion respects the reduced-motion preferenceMUST

Applies tolayout switches with translation, scaling, or continuous animation.

Requirement: When a reduced-motion preference is detected, non-essential translation, scaling, and continuous motion MUST be canceled or significantly reduced; state changes must still be expressed through static information or a suitable substitute. Business results MUST NOT depend on a transition-completion callback for submission, so that the flow cannot complete once animation is turned off.

VerificationEnable the reduced-motion preference and switch through every layout state; check that the task can still be completed and the state is still understandable. Mechanism reference S13

R6 Design decisions are implementable and verifiable

R6-1Deliver change rules and intermediate statesMUST

Applies tonew pages, components, and responsive redesigns.

Requirement: The trigger scope, layout behavior, continuously reachable content, overflow strategy, and state-succession approach MUST be delivered; Web pages MUST preserve the user's ability to zoom. Design mockups MUST cover the primary structural states and explain the scaling behavior between states. Three device-size screenshots alone MUST NOT stand in for the complete specification.

VerificationHave someone not involved in the design explain, from the record, the behavior at an arbitrary intermediate width; wherever the explanation is inconsistent, the rule MUST be filled in.

R6-2Numeric tokens establish a correspondence with behavior rulesMUST

Applies todesign systems that use Design Tokens.

Requirement: Reused spacing, font size, and dimension values MUST have a clear source; semantic tokens SHOULD reference base tokens, and component-specific tokens are established according to actual reuse needs. Delivery MUST include the source value, the context-selection rule, and the resolved effective value together, so that the same input yields the same result; aliases are resolved after valid overrides are complete, and a component's local value is not written back into the global scope. Tokens are responsible for values and references; rules are responsible for behavior such as when to collapse and how to return. The current window width, the focused object, and task state MUST NOT be stored in a token.

VerificationModify one semantic token and check whether the affected components behave as expected; check that behavior rules are not silently bypassed by the value change; verify resolution behavior with counterexamples such as missing references, reference cycles, and type conflicts, rather than substituting default-size screenshots. Format reference S04, S05

R6-3Continuous sizes and real content are accepted togetherMUST

Applies todelivery of responsive changes.

Requirement: MUST test both sides of the breakpoint and intermediate widths, text scaling, long content, empty states, and input scenarios. Platforms declared as supported MUST be verified on the corresponding browser or device. The result MUST fall into one of four states, and "not verified" and "not applicable" MUST NOT be conflated:

Result	Meaning	Must record
Pass	Verified and meets the pass condition	Environment and evidence
Fail	Verified and does not meet it	The specific rule, trigger condition, reproduction steps
Not verified	Should apply but not yet tested	The missing evidence and the party responsible going forward
Not applicable	The applicability condition does not hold	The reason the condition does not hold

Token validity or a complete design mockup MUST NOT substitute for runtime verification, and "not tested" MUST NOT be recorded as "not applicable."

VerificationUse the Chapter 5 checklist to record pass/fail/not verified/not applicable and the reason; after a failure is fixed, re-check the affected paths. Review consistency can be calibrated with two samples: an untested soft-keyboard scenario should get "not verified," and an item for a product with no Agent function should get "not applicable."

R6-4Defaults and exceptions are traceableMUST

Applies toadding a breakpoint, overriding a token, or adopting a different layout strategy for a particular page.

Requirement: MUST indicate whether a value comes from an external standard, a system default, or actual product testing. An override SHOULD be scoped, with the reason, associated rule, and affected scenario recorded. A local component need MUST NOT be used to modify the site-wide breakpoint without basis.

VerificationCheck whether an exception can be traced back to a specific content constraint and verification result, without needing to set up a separate approval process.

4. Layout and component application examples

4.1 Default space states

The following are Web starting presets, in CSS px units; ranges are closed on the left and open on the right, and width allows decimals. 640 and 1024 are project-suggested values, not a uniform stipulation of Material, Carbon, or WCAG.

State	Viewport width	Typical strategy
`compact` narrow space	`w < 640`	Prioritize the current primary content; auxiliary areas open on demand
`regular` normal space	`640 ≤ w < 1024`	Decide whether to place side by side based on the content's minimum width, not forcing two columns
`wide` ample space	`w ≥ 1024`	Show auxiliary areas when space allows; reading content continues to have a width limit

Page state does not directly determine component state. A component located in a narrow side panel MAY still use its own stacked layout even while the page is in the wide state. No new breakpoint needs to be added for ultra-wide screens unless there is genuinely new structural behavior.

4.2 Component behavior matrix

Object	Ample space	Insufficient space	Retained items and constraints
Primary navigation	Visible navigation or side panel	Drawer, menu, or a suitable navigation component	Current location and frequently used entries; choose a navigation approach that fits the product hierarchy
List–detail	Two columns side by side	Shown step by step, with a return provided	Selected item, filters, and semantic position
Auxiliary panel	Presented side by side	Drawer or standalone page	Clear entry point, pending indicator, and input state
Toolbar	Frequent actions expanded	Secondary actions moved into a "more" menu	Primary action and its object
Form	Related fields may sit side by side	Arranged row by row in reading order	Labels, error prompts, and submission path
Card collection	Auto-arranged by the card's minimum width	Column count reduced progressively	Order, complete content, and operability
Table	Full comparison layout	Featured columns with detail, or local horizontal scrolling	The comparison task decides the approach; not converted to cards across the board
Dialog	Width-limited overlay	Full screen when necessary	Title, close, submit, focus, and unsubmitted state
Agent workspace	Task and evidence side by side	Primary task prioritized, evidence opened on demand	State, stop, confirmation, and result entry

4.3 Web viewport and media content

The following examples explain how viewport configuration, media adaptation, and loading stability are put into practice; they add no new principle.

Layout viewport: For example, adopt <meta name="viewport" content="width=device-width, initial-scale=1">, without adding settings that disable zoom or cap the maximum scale. A misconfigured viewport makes breakpoints fail to trigger as expected — verify the layout viewport on the actually declared-supported mobile browsers, not only by resizing a desktop window.

Media carrying task information: Product detail images MAY scale proportionally, decorative images MAY be cropped, and a narrow-column promotional image MAY switch composition. Provide a full view or an equivalent explanation, and verify that the detail needed for the task is still obtainable; whether alt text is sufficient depends on the task, and a single image caption does not substitute for all detail.

Deferred loading: Reserve space using the resource's width/height or an aspect-ratio matching the composition; handle different composition ratios separately. Critical above-the-fold media is not mechanically subjected to deferred loading; when an image fails, retain the necessary explanation and an entry to continue the task.

Resource candidates MAY be implemented with srcset/sizes/picture; these guidelines do not require every image to adopt multiple candidate resources, nor do they infer network speed from window width — network transport and the performance budget are decided separately by the project.

4.4 Deriving layout from task: a record list and detail

The following is a reusable design-record example; the values are project assumptions with no product testing evidence yet. The page is responsible for outer margins; the workspace container is responsible for internal structure.

Decision	Example choice and rationale
User task	Open a record from a filtered list, edit and save it, then return to the original position to keep working
Minimum content need	List 280px, detail 400px, gap 24px; all computed against the panel's outer frame, including internal padding
Measurement	The workspace content box's logical inline size C; the example uses horizontal text
Structural threshold	Side by side when C ≥ 280 + 24 + 400 = 704px; single area when C < 704px; re-verify this assumption after long translated text or text scaling
Ample space	List keeps 280px, detail takes the remaining space; detail shows a selection prompt when nothing is selected
Insufficient space	Retain the current operating area, chosen per the succession table below; the detail form provides "back to list," and does not auto-open an item because of narrowing
Invariants	Current record ID, filters, selected item, edit draft, validation errors, submission state, and reading anchor
Overflow	Detail text grows naturally; attachments have a width limit; tables needing comparison scroll horizontally in a localized way, while search and pagination continue to reflow
Value consumption	`breakpoint.container.recordPanel.inline`, `component.recordPanel.list.minInlineSize`, `component.recordPanel.detail.minInlineSize`, `component.recordPanel.gap`; enable as needed in the token dictionary
Capability failure	Without container queries, use the single-area flow, still able to open detail, save, and return; do not depend on script measurement to show primary content

Cross-layout succession table: Focus is transferred only when the original object is about to lose visibility or operability; "which area is shown" and "which object focus lands on" are decided separately.

Trigger and original position	Visible area and focus succession	State and return result
Side by side → single area; focus in the detail input field	Retain detail; the same field keeps focus, selection, and IME composition	Draft, errors, and submission state unchanged
Side by side → single area; focus on a list item or filter	Retain list; the same object keeps focus	Detail draft is still saved in working state, restored when reopened
Side by side → single area; focus outside the workspace	Do not move focus; show whichever area was last actively used, showing the list when there is no record	No automatic navigation, no save triggered
Single-area detail → side by side; focus in a detail field	Show list and detail; keep focus on the same field	List locates the original record, does not jump to the top
Single-area detail → side by side; focus on the about-to-disappear back button	Hand focus to the detail heading; the heading can be programmatically focused, not added to the normal Tab sequence	Next Tab goes to the detail area's first operable element
User actively returns to the list	Focus returns to the original record's opening entry	Restore filters and semantic position; not equivalent to discarding the draft
The original record has been removed or filtered by the time of return	Focus is handed to the list heading, explaining the record is not in the current results	Filters are retained, with an entry to clear filters or keep browsing provided

If adopting "modal drawer ↔ persistent panel," write bidirectional rules separately: when switching to persistent, release the background's inert, scroll lock, and focus constraint; when switching to modal, ensure focus does not remain on the disabled background. Do not merely switch the appearance while retaining the wrong modal semantics. When no focus is within that area and the user has not actively opened it, prefer collapsing to an entry point, avoiding a size change forcibly opening a modal interface.

Paired verification: On one hand, cross 704px in both directions while editing, during Chinese IME composition, when a save has not yet returned, and while the list is loading, checking state, focus, and request count; on the other hand, while typing outside the workspace, with no record selected, and during continuous width change, confirm that focus is not grabbed, no confirmation pops up, no record is auto-selected, and no repeated collapsing occurs. A pass result MUST have evidence of both "the user can continue" and "implementation state was not reset."

4.5 How to choose an adaptation approach

First walk through the real task and list the content, actions, and judgment basis that must be visible at the same time.
Stress-test the minimum content space using long copy, error prompts, and enlarged text, then choose natural wrapping, side-by-side, collapsing, or step-by-step presentation.
Write the succession table in both the "space narrows" and "space widens" directions, covering separately the cases where focus is inside the area, outside it, and on an object about to be hidden.
Finally, extract repeatedly used sizes into tokens; a one-off local behavior is written directly into the component record, without adding a site-wide mode or user setting.

5. Acceptance checklist

The following is a project acceptance recommendation, not a new set of screen breakpoints. It is enough to record the result and the environment; there is no need to create a separate document for each item.

Dimension	Minimum check set	Pass condition
Width	320, 375, 640, 768, 1024, 1440, 1920 CSS px; the actual breakpoint b−0.5, b, b+0.5, and intermediate values	Content and actions stay continuously reachable, with no unrelated page overflow
Container	The same component placed in a narrow panel and a wide primary area; continuously dragging the divider	Adjusts based on its own space, not misled by page state
Height and orientation	Low-height window, portrait/landscape, soft keyboard, and safe area	Current input, necessary context, and next step are accessible
Scaling	Text reaches 200%; reflow checked at an equivalent 320 CSS px	Necessary content is not clipped, and user zoom is not canceled out
Content	Empty, sparse, abundant, long headings, long translated text, error, and loading	Does not depend on ideal placeholder copy to hold
Input	Keyboard, touch, mouse; mixed input actually supported by the target platform	No hover-exclusive function, no lost focus, no overlapping hit areas
Continuity	While editing, selecting, executing, confirming, across a breakpoint	No lost draft, no repeated action, no change in business consequence
Language and direction	Long translated text in the target language, RTL mixing; check the axis mapping when vertical text is declared supported	Labels, objects, reading, and focus order are consistent, with no truncation of key meaning
Capability fallback	Container query unavailable, configuration failure, script not ready, media and font failure	The basic task can be completed, no repeated focusable controls, no reset of an operation already started
Preference	Reduced motion; if a density mode exists, check each combination	State is understandable, task can be completed
Special areas	Tables, code, canvas, and streaming output	Scroll range is clear, reading and comparison relationships are usable
Text spacing	Applicable properties overridden per the four WCAG 1.4.12 values, default font size retained	Button labels, card summaries, menus, error prompts do not lose content or function; inapplicable properties are recorded
Focus continuity	Focus placed inside/outside the changing area and inside a drawer, switching across a breakpoint	The focused object and the next Tab's landing point are predictable; a component that has received focus is not completely obscured by a fixed area
Web viewport and media	Layout viewport actually tested on declared-supported mobile browsers; a content image with its subject near the edge placed in a narrow container; deferred-loading media returns	Breakpoints trigger as expected and user zoom is not disabled; cropping does not cut off access to a necessary subject or text; the reading position and action target do not jump after media returns

A responsive acceptance failure SHOULD be traced to a specific rule, trigger condition, and reproduction steps. A screenshot can prove the appearance of a given state, but cannot by itself prove state succession and task completion.

5.1 Counterexamples on both sides

Every key rule has two ways to fail: under-delivery (falling short of the requirement) and over-delivery ("meeting" the requirement by adding burden). Both sides need to be checked; whether something is noncompliant is decided by the specific main-text obligation, not overturned by aesthetic preference alone.

Rule	Under-delivery	Over-delivery
R1-2 Collapse entry	The filter panel disappears and the entry cannot be found	Even the primary action gets buried in multi-level menus, making the task path harder to discover
R2-2 Content decides the breakpoint	Breakpoints applied by device name, so long translated text overflows before switching	A new site-wide breakpoint added for every extra character, with no content-constraint basis
R3-1 Regular content supports reflow	At a narrow width the user must drag left and right to read one line of body text	To avoid horizontal scrolling, every data table is converted to cards across the board, making the comparison task impossible
R3-2 Text scaling and spacing	After the user zooms to 200%, button text is clipped	Single-line inputs and table column headers are forced to wrap, and the control loses its purpose
R4-2 Focus continuity	After the drawer collapses, focus returns to the document root and the user does not know where they are	Every reflow actively grabs focus to the "primary action," interrupting what the user is doing
R4-4 Fixed areas do not seize control	An input field that has received focus is completely covered by a fixed bottom bar	A confirmation dialog pops up asking whether to scroll every time new content arrives, repeatedly interrupting reading
R5-2 Hit area	An icon looks large, but the actual clickable area is insufficient	The transparent hit area is expanded without limit, covering adjacent actions
R6-3 Continuous-size acceptance	Passing is declared after screenshotting only three breakpoints	To run through a large number of sizes, the page is reset at every size, missing the continuous switch while editing

What the rules require is that the promise holds, not that prompts, confirmations, or toggles are piled on to the maximum — over-design is also a failure.

5.2 Evidence and acceptance conclusion

Evidence layer	What it answers	Minimum record
Documentation	Whether behavior at an arbitrary size can be explained	Rule, measurement object, threshold basis, succession table, token source
Implementation	Whether the mechanism takes effect at the moment of change	Browser and system environment, viewport and container size, scale, input method, before/after focused object, draft and request count
User task	Whether the person can find the entry and continue to completion	Task steps, whether a return/correction path was found, whether the collapsed state was misunderstood, failure location

Adopted record format: Scenario / Rule / Environment and content / Initial state / Action / Expected / Actual / Pass, fail, not verified, or not applicable / Evidence and responsible party. Browser device emulation cannot substitute for verification in the target environment for soft keyboard, mixed input, and assistive technology.

Acceptance threshold: A failure of an applicable MUST item means non-conformance; an average score cannot offset a lost draft, repeated submission, an unreachable primary action, or lost focus. Not-verified items remain pending acceptance; not-applicable items note the condition. A deviation on a SHOULD item needs a stated reason, an alternative, and evidence under the same task. Screenshots, JSON static checks, and actual task operation are recorded separately and cannot substitute for one another.

After modifying a breakpoint, font, minimum content width, fixed area, or DOM structure, re-check the affected combinations of size, language, focus, and state; adjusting even a single value alone can also change layout behavior. There is no need to exhaustively cover every theme each time; prioritize covering combinations that write into the same token together or share a space constraint.

6. Terminology

Term	Meaning in this document
CSS px	The reference pixel used for layout; different from physical screen pixels, breakpoints are not converted by DPR
Layout viewport	The spatial basis for page layout and viewport media queries
Visual viewport	The currently actually visible page area, which can change due to pinch-zoom or a soft keyboard
Container content box	The container space after removing border and padding; MUST NOT be conflated with the panel's outer-frame size
inline / block	The inline axis and block axis determined by the writing mode; in horizontal writing these usually correspond to width and height
Semantic reading position	The current record, paragraph, or step and its neighboring context, not a fixed scroll pixel
Layout state	The expression chosen based on space, not equivalent to device category, information density, or business state

Implementation acceptance scenarios

The following scenarios turn existing clauses into re-checkable acceptance inputs, without setting an additional general-purpose performance threshold. Select by the product's applicable capability, and supplement with real devices, users, input sequences, and evidence; record the reason when not applicable, and an unexecuted item MUST NOT be recorded as a pass.

Clause	Test input and anomaly	Expected behavior and failure criterion
R2-1	Place the component into a narrow container within a wide viewport, and progressively resize the container.	The component reflows along the agreed container axis, and is not forced side by side by the page's wide state.
R4-1	Trigger a breakpoint, text scaling, and the soft keyboard while typing.	Input, focus, and the primary action stay reachable, without remounting focusable controls repeatedly.
R6-2	Override the base value, resolve its semantic alias, then inject a reference cycle.	A valid override yields the new effective value; the reference cycle is rejected and the already-verified base layout is retained.

Each scenario checks the configuration's effective value, the execution record, and the user-comprehensible result separately. Retain the version, target, event timestamp, failure scope, and recovery result; an unknown external result is not filled in as pass or fail.

Turn reusable sizes and spacing into design values that are semantic, mappable, and verifiable, so layouts use the same design language across different spaces.

Used together with Responsive Design Guidelines; for sources and value boundaries see reference.md. This document gives the token layering, starter dictionary, context mapping, and engineering-delivery examples; it does not include a published token package or component implementation.

1. Applicability boundaries

This dictionary mainly manages Web breakpoints, spacing, container constraints, typography, and interaction sizes. Behaviors such as collapsing into a drawer, how list-detail returns, and how focus continues follow the design guidelines; value tokens and behavior rules together make up responsive design.

Object	Example	Where it lives
Reusable design value	Page margin, card minimum width, dialog maximum width	Token
Layout and interaction rules	Switch to a drawer when the panel can't fit, preserving drafts and the entry point	Component specification and implementation
Resolution context	Currently using `compact` or `wide` layout values	Build-time or runtime resolution input
Operational state	Measured container width, current focus, task ID, selected records	Application state; must not be written into tokens

The responsive dictionary can reuse a project's existing visual base tokens; do not duplicate color, corner radius, shadow, or other values that have no spatial variance just for responsive design. Tokens cannot substitute for focus management, draft saving, scroll restoration, or task-execution mechanisms.

1.1 Adoption scope and decision responsibility

"Basic required" means a resolvable value is needed when adopting this document's presets; it may inherit the default and does not require the user to fill it in. "Conditionally enabled" means it is completed when the related component or capability is used; optional fields that are not used may be omitted.

Field group	Adoption condition	Decision and effect
Page space, margins, body and heading	Basic required when page presets are adopted	Maintained by default in the design system; the product overrides after content validation, taking effect when the measurement condition is met
Collection minimum width	Enabled when using an auto-arranging collection	The component owner decides based on real card content, taking effect locally within the collection
Controls, hit areas, icons	Enabled when using the related interactive component	The component owner verifies the visible and hit areas; hit areas are not automatically shrunk with a narrower window
Dialog width	Enabled when using a width-constrained overlay	Consumed by the overlay state; the full-screen state adopts its own sizing rules
Record-panel threshold and the three spatial constraints	Enabled as a group when using the side-by-side / single-region example	The component owner derives the threshold, taking effect in the designated workspace container
Density, theme, motion context	Enabled when the product actually provides or consumes them	Override only the declared fields; the system's reduced-motion preference must not be canceled by a local default override

Every override states why that value was chosen, who maintains it, its scope, when it takes effect, and what it depends on. The field table is not a user settings page; the runtime applies a complete, validated configuration rather than refreshing field-by-field into an intermediate, contradictory layout.

2. Layering and naming

2.1 Three-layer structure

Layer	Example	How values are taken
Base value	`space.4 = 16px`, `font.size.400 = 16px`	Provides a finite scale; the same base value does not change with layout state
Semantic value	`layout.page.padding.inline`, `type.body.fontSize`	Named by purpose; different contexts reference different base values
Component value, created as needed	`component.dialog.maxWidth`	References semantic values; added only for decisions a component needs to manage independently

Example reference chain: component.dialog.maxWidth → layout.overlay.maxWidth → size.overlay.default. When there is no component-specific need, consume the semantic token directly — there is no need to build a third layer for every CSS property.

2.2 Naming conventions

Documentation uses dot paths, e.g. layout.page.padding.inline; DTCG JSON represents the hierarchy with nested objects rather than using the full dotted path as a single token name.
Numeric scales live in the base layer; purpose names live in the semantic layer. Avoid names like pagePadding24 that bake a number into a purpose name.
Use logical directions such as inline, block to describe margins; the concrete physical direction is determined by the writing mode.
The same semantic name stays unchanged across contexts, avoiding separately created page.padding.mobile, page.padding.tablet, page.padding.desktop.
A token can express one layout parameter, but the existence of layout.grid.columns does not require every component to follow the same column count.

The layering and naming above are this project's convention; DTCG specifies the exchange format, types, and referencing method, and does not mandate this naming. Source S04

3. Context and resolution

3.1 Spatial states

Context	Measured range	Default interval	Purpose
`viewport.compact`	Page layout viewport width	`w < 640px`	Page-level compact spatial values
`viewport.regular`	Page layout viewport width	`640px ≤ w < 1024px`	Page-level regular spatial values
`viewport.wide`	Page layout viewport width	`w ≥ 1024px`	Page-level wide spatial values
Component local state	Content-box width of the given container	Determined by the component's minimum usable space	Internal component rearrangement; does not inherit page state as the sole basis

The default spatial measurement w is the physical width, using the viewport width media query; the component example's C is the logical inline size, using the container inline-size query. The two are directly comparable only in a horizontal writing mode.

The 640 / 1024 CSS px here are suggested starting points, not an external standard. Intervals are closed on the left and open on the right, compared directly against continuous values; do not use 639px as the upper bound of the previous tier and thereby miss fractional widths.

The layout viewport is suitable for tiering the page structure; the soft keyboard, safe area, and visible height still need to be handled separately in the layout implementation and cannot be solved by these two width tokens.

3.2 Independent dimensions

Dimension	Example	Resolution scope
Viewport space	compact / regular / wide	Page margins, region spacing, page title
Container space	stacked / inline and other component local states	Internal component layout and local spacing
Density, if the product provides it	comfortable / dense	Values allowed to vary, such as control padding, line height
Theme, if the product provides it	light / dark	The existing color and effects system
Motion preference	default / reduced	The existing motion system and layout transitions

compact indicates the available space is tight; dense indicates the information density is higher; the two must not be merged into the same dimension. There is no need to add a density or theme setting just to adopt this dictionary.

This document's presets merge in the determinate order in §3.3, then resolve aliases, and finally validate per §5.1.1. Dimensions preferentially modify different fields; overrides of the same path must be declared in an allow-list, not prioritized by ad hoc guessing based on device name.

DTCG Resolver provides multi-context organization mechanisms such as sets, modifiers, and contexts; this document's dimension table is a project design, not a configuration file that can be submitted directly to the Resolver. Selecting the viewport measurement, container measurement, and preference detection for the context is still up to the engineering implementation. Source S05

3.3 The determinate contract for merging, aliases, and conflicts

This section is the project's consumption contract; it does not claim to be a generic DTCG Resolver configuration.

Load the base dictionary and the compact default semantics, then apply the product's default overrides.
Based on the measured viewport, select one and only one page state: compact adds no extra overrides; regular or wide use their respective complete override sets. Theme, density, and motion apply in this order, but each may write only to its own approved fields.
Within a component's scope, apply container state and component overrides; a component must not reverse-modify site-wide tokens through local configuration. Page margins are controlled only by the page spatial dimension; component local spacing is controlled only by the corresponding component.
Groups merge recursively by path; a token node at the same path is replaced wholesale — object members within $value are not deep-merged. An overriding node MUST explicitly retain the matching $type and supply a complete $value. An undeclared cross-dimension override of the same path is an error; silently taking the last one is prohibited.
Resolve aliases against the merged result within the final scope. Detect missing targets, cycles, type mismatches, and domain-illegal values; only output CSS or platform values after passing. Do not resolve default aliases first and then override the base value.
If any required item fails, reject the entire candidate configuration; keep the last valid configuration. Cold start uses a base single-region layout that has been pre-delivered and task-validated. If that base layout itself is unvalidated, acceptance cannot be declared passed.

Worked example: the product overrides space.6 to 28px; after selecting regular, layout.page.padding.inline = {space.6}, so the final page margin is 28px. If the alias were resolved to 24px first and then merged, the result would be wrong. The base default with no override source remains 24px.

Scope example: at a 1440px viewport with a 500px workspace, the page adopts the wide margin of 32px while the record panel still uses the single-region layout; the two do not override each other. A page breakpoint cannot directly trigger the panel's side-by-side layout.

3.4 The output contract for units and axes

Input category	Output method	Verification points
This dictionary's breakpoints, layout sizes, and spacing	Keep CSS px; the unit of the DTCG dimension object is `px`	Do not convert by DPR, physical screen pixels, or the current root font size
Font-size base values	Examples are converted to rem at a design baseline of 16px: 16→1, 28→1.75, 32→2, 40→2.5	The baseline is only for building the conversion; do not hard-code the browser root font size, and do not re-divide by the user's root font size at runtime
Font-size overrides already explicitly defined in rem	Output rem directly, without dividing by 16 again	Can still grow after the user's root font size changes
Line height	Output the unitless number as-is	Must not be converted to a fixed px line height that caps text growth
Logical sizes	This document's `maxWidth`, `minWidth` names are for the horizontal-writing preset; CSS outputs to `max-inline-size`, `min-inline-size`	If vertical writing is supported, the mapping must be recorded explicitly; new components adopt explicit names such as `minInlineSize`
Formulas and environment variables	`clamp()`, `min()`, `env()` stay at the consumption layer, composed from legal tokens and the runtime environment	Do not disguise formula strings, `ch`, `ic`, `vh`, or percentages as a DTCG dimension

DTCG dimension supports px, rem; this document further restricting fields such as breakpoints to px is a project constraint. Reading line length may use ch/ic in component CSS, or an independent field with a unit mapping may be defined when reuse is explicitly needed, but it is not stuffed directly into this document's dimension dictionary. Custom expression extensions must be marked as a tool-private protocol. S04, S18

4. Base value dictionary

The following are all starter values pending product validation. If the project already has a compatible base scale, reuse it and establish a mapping rather than maintaining two copies of the same numbers in parallel.

Token	DTCG type	Default value	Description
`space.0`	dimension	0px	No spacing
`space.1`	dimension	4px	Micro spacing
`space.2`	dimension	8px	Spacing between immediately adjacent elements
`space.3`	dimension	12px	Spacing within a small group
`space.4`	dimension	16px	Basic padding
`space.6`	dimension	24px	Standard region spacing
`space.8`	dimension	32px	Large region spacing
`space.12`	dimension	48px	Section spacing
`font.size.400`	dimension	16px	Example body scale
`font.size.700`	dimension	28px	Example heading scale
`font.size.800`	dimension	32px	Example heading scale
`font.size.900`	dimension	40px	Example heading scale
`font.lineHeight.body`	number	1.5	Unitless multiplier; the font and language used must be validated
`font.lineHeight.heading`	number	1.25	Unitless multiplier; wrapped headings must be validated
`size.content.default`	dimension	1200px	Default content-width cap
`size.overlay.default`	dimension	560px	Default dialog width cap
`size.card.minimum`	dimension	240px	Example card's preferred minimum width; falling back is allowed when narrower than the available space
`size.control.default`	dimension	40px	Starting point for a standard control's minimum height
`size.target.touch`	dimension	44px	The project's hit-area target for important touch actions
`size.icon.default`	dimension	20px	Visible icon size; does not represent the hit area

Numbers such as in font.size.400 are this project's scale identifiers and do not represent font weight. A standard control's 40px height and a touch hit area's 44px are different objects; icon controls also need their width checked at the same time. Controls should be able to grow as text is enlarged; these minimums must not all be output as fixed heights. The 1.25 of font.lineHeight.heading is an author default value, and it is not the same thing as WCAG 1.4.12's user-override test value (line height 1.5× etc.) — the latter is an acceptance condition after override, and does not constitute the floor of this table (see guideline R3-2).

5. Semantic values and responsive mapping

5.1 Page and typography

The reference paths in the table are token aliases; parentheses show the default resolved value.

Token	compact	regular	wide	Related rule
`layout.page.padding.inline`	`space.4` (16px)	`space.6` (24px)	`space.8` (32px)	R2-3, R6-2
`layout.grid.gutter`	`space.4` (16px)	`space.6` (24px)	`space.6` (24px)	R2-3
`layout.section.gap`	`space.6` (24px)	`space.8` (32px)	`space.12` (48px)	R3-3
`layout.content.maxWidth`	`size.content.default` (1200px)	same as left	same as left	R3-3
`layout.overlay.maxWidth`	`size.overlay.default` (560px)	same as left	same as left	R2-4
`type.body.fontSize`	`font.size.400` (16px)	same as left	same as left	R3-2
`type.body.lineHeight`	`font.lineHeight.body` (1.5)	same as left	same as left	R3-2
`type.heading.page.fontSize`	`font.size.700` (28px)	`font.size.800` (32px)	`font.size.900` (40px)	R3-2
`type.heading.page.lineHeight`	`font.lineHeight.heading` (1.25)	same as left	same as left	R3-2

A maximum width is always only a cap; the actual width still must not exceed the available space. Whether a dialog goes full-screen is component behavior: once the full-screen form is chosen, that form's styling determines filling the available area, and it must not continue to be constrained to a narrow strip by the 560px.

Keeping the body text at the same font size across all three tiers is a deliberate design choice. Headings may be tiered or use a validated fluid font size, but responsive shrink rules must not cancel out the user's enlargement.

5.1.1 Domain-legal values and the resolution-failure contract

Being correctly formatted does not mean this topic's semantics hold: regular=1100px, wide=900px are both legal dimensions, yet they make the interval table's actual order inconsistent with the two min-width queries; fontSize=0px, maxWidth=0px also pass a "non-negative" check, yet cannot serve as usable defaults.

Domain-legal values

Category	Constraint
Viewport breakpoints	Finite positive CSS px values, and `breakpoint.viewport.regular` < `breakpoint.viewport.wide`; inverted or equal is illegal
Margins and spacing	Finite non-negative values, 0 allowed; this document does not allow negative spacing
Font size, line height, effective content-width cap, control/icon/hit-area sizes	MUST be finite positive values; 0, negative, NaN, and infinite values are illegal
Units	This preset's breakpoints, layout, spacing, controls, hit areas, and icons use px; font size may use px or rem, output per §3.4; line height is unitless. MUST NOT be silently overridden with other units

Missing and illegal are handled separately

Default context: resolved per the declared default value; this is the normal path.
Unknown context name, unresolved alias, circular reference, type mismatch, inverted breakpoint: none of these may silently take effect; a predictable error MUST be output, or the case must fall to a defined fallback.

Interface behavior on resolution failure

When a running interface encounters a configuration-update failure, keep the last configuration that passed validation, without losing task state or clearing drafts.
When there is no valid configuration from the very first run, adopt a predefined, validated base layout, without guessing a value ad hoc.

Default values, fallback values, and the last valid configuration are configuration-management information and are recorded together with the configuration's source; measured window width, the focused object, and task state MUST NOT be written into tokens.

Counterexamples (for accepting this contract): inverted breakpoints, equal breakpoints, font.size of 0, an unknown viewport.tablet, a missing space.6, a differently-typed override at the same path, a circular reference — each should produce a predictable error or an explicit fallback. Defaults compact / regular / wide resolve to page margins of 16 / 24 / 32px respectively. This can be verified by working through the table; there is no need to build an automated executor first.

5.2 Breakpoints, components, and interaction sizes

Token	Type	Default reference or value	Usage boundary
`breakpoint.viewport.regular`	dimension	640px	Lower bound of the page state; compiled into a query condition
`breakpoint.viewport.wide`	dimension	1024px	Lower bound of the page state; compiled into a query condition
`layout.collection.item.minWidth`	dimension	`size.card.minimum`	Auto-arranged collection; allowed to shrink to the available width in an extremely narrow container
`control.minHeight`	dimension	`size.control.default`	Minimum height; does not limit content growth
`interaction.target.touch.minSize`	dimension	`size.target.touch`	Initial target for important touch targets; not bound to page state
`icon.default.size`	dimension	`size.icon.default`	Visible icon size
`component.dialog.maxWidth`	dimension	`layout.overlay.maxWidth`	Optional; created when the dialog needs to be maintained independently

A component breakpoint is added only when the component genuinely needs a structural switch, e.g. breakpoint.container.recordPanel.inline; its value MUST be derived from that component's minimum space constraints — this document does not preset site-wide generic component thresholds.

Reading body-text width, navigation-bar width, workspace three-column constraints, and the like are added according to product content. Tokens that will not be used do not need to be pre-established.

5.2.1 Conditional fields for the record panel

The following four items are enabled together only when adopting the record-panel example from the guidelines; the example's content constraints still need product validation. The panel's minimum size is computed from its outer-box requirements; the parent workspace is measured by its content box.

Token	Type and default value	Legal range and consumption method	Rule
`component.recordPanel.list.minInlineSize`	dimension, 280px	Finite positive px; the preferred minimum footprint when the list is side-by-side	R2-2, R3-3
`component.recordPanel.detail.minInlineSize`	dimension, 400px	Finite positive px; the minimum content requirement when the detail is side-by-side	R2-2, R3-2
`component.recordPanel.gap`	dimension, `{space.6}`, 24px	Finite non-negative px; not automatically rewritten by page state	R2-3
`breakpoint.container.recordPanel.inline`	dimension, 704px	Finite positive px, and not less than the sum of the two minimum footprints above plus the gap; outputs a logical-axis query	R2-1, R2-2

After modifying the three constraints, the build validation MUST re-check the threshold. For example, if the gap changes from 24 to 28, 704px is no longer sufficient — at least 708px is needed; it is not acceptable for only the gap to take effect while an illegal threshold remains. The threshold may be computed by build-time derivation, but it must be output as a standard dimension value with the derivation basis retained, not output as a mathematical-expression alias.

Do not build size tokens for "currently editing" or "return to list"; whether the detail is open and focus continuity are still managed by component state.

5.3 Fixed requirements and adjustable values

Nature	Content	Can it be lowered by theme or breakpoint
Standard requirement	WCAG 2.5.8's 24×24 CSS px and its explicit exceptions	An override token cannot be treated as an exemption; exceptions must be judged per the standard
Project target	Initial target of at least 44×44 CSS px for important touch hit areas	May be adjusted with a specific reason and validation results, still meeting applicable standards
Adjustable default	640 / 1024 breakpoints, 16 / 24 / 32 margins, 1200 content cap	May be adjusted per content and measurement
Behavioral requirement	Key entries reachable, drafts not lost, focus continuable	Cannot be overridden or canceled by a numeric value

The hit area also involves spacing, shape, and adjacent targets; passing WCAG cannot be declared just by comparing a single minSize number. Source S08

6. DTCG exchange-format examples

The following is a complete default-file example for the small subset of tokens covering the page's horizontal margin. dimension uses a numeric object with a unit; an alias references the entire token value. The rest of the full dictionary's values are exported the same way; these examples are not the complete set of product tokens.

{
  "space": {
    "4": { "$type": "dimension", "$value": { "value": 16, "unit": "px" } },
    "6": { "$type": "dimension", "$value": { "value": 24, "unit": "px" } },
    "8": { "$type": "dimension", "$value": { "value": 32, "unit": "px" } }
  },
  "layout": {
    "page": {
      "padding": {
        "inline": {
          "$type": "dimension",
          "$value": "{space.4}",
          "$description": "Page horizontal padding, default for the compact spatial state"
        }
      }
    }
  }
}

Example override file for the regular context:

{
  "layout": {
    "page": {
      "padding": {
        "inline": { "$type": "dimension", "$value": "{space.6}" }
      }
    }
  }
}

Example override file for the wide context:

{
  "layout": {
    "page": {
      "padding": {
        "inline": { "$type": "dimension", "$value": "{space.8}" }
      }
    }
  }
}

Override files depend on the base values provided by the default file and cannot be used as an independent, fully-referenced token set. Build tooling executes per the loading order in §3.3, with node replacement, merging, and then alias resolution; the DTCG Format itself does not automatically infer viewport state from the file name.

If DTCG Resolver is adopted, context configuration conforming to the Resolver Schema should be output separately and validated. Do not label an arbitrary custom modes object or a string-typed clamp(...) as a standard dimension value. S04, S05

7. Web output examples

Below is a CSS output illustration corresponding to the default dictionary, not a complete page or a measured component. Font sizes are output as rem at the design conversion baseline of 16px, not fixed to the user's root font size. Breakpoints keep CSS px, each representing a viewport measurement threshold.

:root {
  --space-4: 16px;
  --space-6: 24px;
  --space-8: 32px;
  --space-12: 48px;
  --layout-page-padding-inline: var(--space-4);
  --layout-grid-gutter: var(--space-4);
  --layout-section-gap: var(--space-6);
  --layout-content-max-width: 1200px;
  --layout-collection-item-min-width: 240px;
  --type-body-font-size: 1rem;
  --type-body-line-height: 1.5;
  --type-heading-page-font-size: 1.75rem;
  --type-heading-page-line-height: 1.25;
}

/* Compiled from breakpoint.viewport.regular into a concrete query condition. */
@media (min-width: 640px) {
  :root {
    --layout-page-padding-inline: var(--space-6);
    --layout-grid-gutter: var(--space-6);
    --layout-section-gap: var(--space-8);
    --type-heading-page-font-size: 2rem;
  }
}

/* Compiled from breakpoint.viewport.wide into a concrete query condition. */
@media (min-width: 1024px) {
  :root {
    --layout-page-padding-inline: var(--space-8);
    --layout-section-gap: var(--space-12);
    --type-heading-page-font-size: 2.5rem;
  }
}

.page {
  box-sizing: border-box;
  inline-size: 100%;
  padding-inline: var(--layout-page-padding-inline);
  font-size: var(--type-body-font-size);
  line-height: var(--type-body-line-height);
}

.page__content {
  inline-size: 100%;
  max-inline-size: var(--layout-content-max-width);
  margin-inline: auto;
  min-inline-size: 0;
}

.page__title {
  font-size: var(--type-heading-page-font-size);
  line-height: var(--type-heading-page-line-height);
  overflow-wrap: anywhere;
}

.collection {
  display: grid;
  gap: var(--layout-grid-gutter);
  grid-template-columns: repeat(
    auto-fit,
    minmax(min(100%, var(--layout-collection-item-min-width)), 1fr)
  );
}

.collection > * {
  min-inline-size: 0;
  overflow-wrap: anywhere;
}

min(100%, ...) lets a card fall back in a container narrower than the preferred minimum width, avoiding a fixed minimum width that stretches the page; images, tables, and the like within a card still need their own constraint handling. Component structural switching may use container queries; a page breakpoint cannot substitute for that layer of judgment. S03

Native CSS sizing query conditions cannot use var() directly: do not output @media (min-width: var(--breakpoint)) or similar container-size conditions. Concrete values are output by the build tooling, with the source mapping retained. This is a different mechanism from container style queries querying custom properties. S11

7.1 Container-size consumption and the base fallback

Below is consistent with the record panel's four fields; 704px is build output, and var() is not used in the CSS query. The container itself does not switch its grid — its descendant .record-panel is what consumes the query.

.record-workspace {
  container: record-workspace / inline-size;
  min-inline-size: 0;
}
.record-panel {
  --record-list-min: 280px;
  --record-detail-min: 400px;
  --record-gap: 24px;
  display: grid;
  grid-template-columns: minmax(0, 1fr);
  gap: var(--record-gap);
}
.record-panel > * {
  min-inline-size: 0;
  box-sizing: border-box;
}
/* data-active comes from the user's current working state, not a token. */
.record-panel[data-active="list"] > .record-detail,
.record-panel[data-active="detail"] > .record-list {
  display: none;
}
@container record-workspace (inline-size >= 704px) {
  .record-panel {
    grid-template-columns: var(--record-list-min) minmax(var(--record-detail-min), 1fr);
  }
  .record-panel[data-active] > .record-list,
  .record-panel[data-active] > .record-detail {
    display: block;
  }
}

The component maintains only one effective list instance and one detail instance; if a multi-instance implementation is adopted, hidden instances must not be focusable, must not be redundantly exposed to assistive technology, or produce duplicate IDs. The CSS above only illustrates the arrangement; before crossing the threshold, the component determines data-active and where focus goes per the continuity table, and the back button, input-method state, and modal semantics require a behavioral implementation. display: none alone cannot prove state continuity.

When container queries are unavailable, the rules above stay in the single-region form; the basic open-detail and return interactions are still provided by the component. Do not display two submittable forms at once for the sake of compatibility. S03

7.2 Safe area, visible height, and hit area

/* Environment values are a runtime input, not a persisted token. The safe area uses physical directions. */
.page {
  padding-left: max(var(--layout-page-padding-inline), env(safe-area-inset-left, 0px));
  padding-right: max(var(--layout-page-padding-inline), env(safe-area-inset-right, 0px));
}
.dialog__scroll {
  max-block-size: 100vh; /* Base fallback */
  max-block-size: 100dvh;
  overflow: auto;
  padding-bottom: max(16px, env(safe-area-inset-bottom, 0px));
  box-sizing: border-box;
}
.touch-action {
  min-inline-size: 44px;
  min-block-size: 44px;
  padding: 8px;
  font: inherit;
  white-space: normal;
}
.touch-action__icon {
  inline-size: 20px;
  block-size: 20px;
}

The safe-area example takes "the greater of the base padding and the safe distance," not an additive sum; if the design requires extra padding beyond the safe area, declare a separate calc() strategy and test it. Evaluate viewport-fit=cover only when the product adopts an edge-to-edge layout — it cannot be assumed that insets are always non-zero. The dialog example above is a horizontal-writing, independently scrollable region; a real overlay still needs to subtract margins and other fixed regions, and reachability after the keyboard opens must be tested on the target device. dvh does not guarantee avoiding the soft keyboard, and env(safe-area-inset-bottom) is not equal to the keyboard height either. S16

The control hit-area example outputs the project's 44px target and 20px icon, allowing text to grow, and does not set the minimum height as a fixed height. Density modes must not shrink to the point of violating applicable requirements; hit-area overlap must be judged by an actual hit test.

8. Design and engineering delivery

Design source: Maintain base values, semantic references, and the enabled contexts; state in the component record which container is responsible for local adaptation.
Design-tool mapping: Manage base values and semantic values separately; when the tool supports modes, page spatial states may be mapped. A mode in the design tool is not equivalent to the browser runtime automatically detecting width — engineering mapping is still required.
Export: Output DTCG token data, plus the context or build configuration needed by the tools the project uses. CSS, platform constants, and the like are all generated from the same source.
Resolution: Validate per §5.1.1's domain-legal values and resolution-failure contract — unknown context, missing base value, circular reference, type error, override conflict, and inverted breakpoint are each handled separately; the default context MUST be explicit.
Runtime verification: Check the real interface per Chapter 5 of the Design Guidelines. JSON being parsable, tokens being resolvable, and the interface being usable are different verification layers.
Impact review: Record the reason for each value's choice, its related rules, and its consumption scope; after overriding breakpoints, font size, width, or fixed padding, re-check the affected tasks and language combinations.

Suggested record template:

Token / context	Resolved value	Reason	Page or component affected	Validation result
Example: component local breakpoint	Filled in by the product	Long translated text made the layout unable to fit	Record detail panel	Product fills in browser, content, width, and result

This document only establishes documentation and examples; it has not undergone toolchain integration, browser execution, design-tool import, or device validation.

9. Configuration acceptance samples

The following are document-level input/expectation contracts; they do not represent an actually run browser or design tool.

Input or change	Expectation
Default viewport widths 639.5 / 640 / 1023.5 / 1024px	compact / regular / regular / wide; page margins 16 / 24 / 24 / 32px
wide page + 500px workspace	Page margin 32px, record panel single-region, local spacing 24px
Workspace 703.5 / 704 / 704.5px	single-region / side-by-side / side-by-side; focus and drafts maintained per the continuity table
Product `space.6=28px` + regular	Page margin resolves to 28px; when the record panel is enabled, the threshold needs to be at least 708px
Equal breakpoints, inverted, negative spacing, zero font size, infinite size	Reject the configuration, output the field path and error reason
Missing alias target, cycle, dimension referencing a number	Reject the configuration; must not output stray braces or `undefined` CSS
No context provided vs. explicit unknown `viewport.tablet`	The former defaults to compact; the latter errors — the two must not both be treated as defaulting
Density overriding page margin, component overriding a site-wide breakpoint	Not within the allowed scope, error; does not depend on incidental file-load order
User root font size 20px, body source value 16px	Build output is still 1rem; the computed font size is 20px; the thresholds are still 640/1024 CSS px
No valid configuration on first run / an illegal configuration received while running	The former uses the validated base layout; the latter keeps the last valid configuration; neither resets the task

Acceptance has three steps: JSON structure and types → references, scope, and value dependencies across all enabled contexts → tasks, zoom, focus, and input in the actual interface. Passing the first two steps does not substitute for the third.

Configuration delivery and validation

The examples use standard dimension px/rem to express values; dp, pt, or a physical meter value must not be written directly as the same exchange type. The example is only one resolved page padding value; viewport, container, and density selection are still carried by the actual layout contract — a set of breakpoints cannot be presumed adapted on this basis alone.

The accompanying executable sample covers only layout.page.padding.inline; the remaining fields are validated item by item per this dictionary; not being covered does not mean not applicable or already passed. The sample is a positive/negative format example for the selected field, not a product preset that directly enables all capabilities. A complete product delivery additionally includes applicability, dependencies, evidence, execution mapping, and the effect boundaries of in-progress operations.

When a field's name, type, or meaning changes, update the consumers and the acceptance sample; when only the description changes without changing legal behavior, keep the existing field name. The caller reads the resolved effective configuration; permissions, measurements, or completion facts are not reverse-inferred from UI controls, animation, or model text. See the corresponding scenarios.

References

This document accompanies the Responsive Design Guidelines and the Design Token. Sources are primarily standards bodies, official design-system documentation, and technical documentation, distinguishing external requirements, implementation mechanisms, and this project's design judgments.

The search found reference material for responsive layout, accessible reflow, and token exchange, but they solve different problems. This topic combines this material into six principles and 24 rules for Web products; it does not claim that this classification, these breakpoints, or this token naming is a unified industry standard.

1. Source Types and Verification Status

Type or Status	Meaning and Boundaries
W3C Recommendation	WCAG 2.2 is a formal Recommendation and should be used within its applicable scope and conformance level.
Understanding documents	Explanatory material published by W3C that helps interpret success criteria and exceptions; the explanatory documents themselves are not additional normative requirements.
DTCG Community Group Report	Format and Resolver are stable Community Group Reports, not W3C Recommendations.
Official design-system practice	Design decisions from Material and Carbon can be referenced, but cannot automatically become values that all products must adopt.
Technical documentation	MDN explains CSS capabilities and limitations; the existence of an implementation mechanism does not mean this project has already run verification tests.
Verified relevant content	The content or sections of the original page used for judgment have been read; this does not indicate a full-text review, running the examples, or testing all browsers.
Official search snippet	Only the body-text snippet of the official page returned by the search tool was read; this is not marked as a verified complete page.

The links below locate the original material adopted; identifiers for external standards and fixed source URLs are used to precisely locate evidence, and do not represent this project's own publication numbers. Verification covers only the relevant content, and does not represent compatibility or product runtime testing.

2. Layout and Component Adaptation

S01 Material Design 3 — Canonical layout examples

Source: Official page.
Status: Official search snippet. The snippet includes the classification of feed, list-detail, and supporting-pane layouts and cross-breakpoint adaptation notes; opening the page directly returned only a JavaScript notice, so the full text of the interactive examples was not verified.
What it supports: Organizing layout examples by common task structures, as a reference for R2-3 and the component behavior matrix.
What it does not support: This cannot be used to claim that all products must adopt a two-column layout, side panel, or bottom navigation at a given width. This project's 640 / 1024 breakpoints do not come from this page.

S02 IBM Carbon — 2x Grid

Source: Overview.
Status: Verified content related to the base unit, fixed/fluid/hybrid grids, breakpoints, and size scale.
What it supports: Using a limited size scale to establish order, and distinguishing between increasing the number of visible items and increasing the content space of each item; supports R2-2, R2-3, R3-3, and the organizing approach for base tokens.
Numeric boundaries: The breakpoints listed on the Carbon page are 320, 672, 1056, 1312, 1584px; these are Carbon's own configuration. This project does not splice these together with other design systems' breakpoints into a so-called universal standard, nor did it copy its column count, margins, or panel behavior.

S03 MDN — CSS container queries

Source: Official documentation.
Status: Verified content on container size queries, container establishment, and component-adaptation examples.
What it supports: Size container queries adjust descendant element styles based on a designated container; supports the separate adaptation of pages and components in R2-1, and the local-state material in the Token documentation.
What it does not support: Does not define this project's component breakpoints; cannot be used to conclude that all container-query sub-features are available on all target browsers. Specific adopted size queries, style queries, etc. need to be verified individually.

3. Design Token Format and Context

S04 Design Tokens Format Module

Source: Original report.
Maturity: DTCG Final Community Group Report; not a W3C Standard.
Status: Verified content related to document status, grouping, types, and dimension and alias examples.
What it supports: Using $type, $value, and references to express design values; dimension is represented as an object with a numeric value and a unit. Supports R6-2 and the JSON examples in the Token documentation.
What it does not support: Does not mandate the three-layer "base—semantic—component" naming, nor does it specify this project's breakpoints, 44px targets, or page maximum widths. Conforming to the format does not mean the interface meets accessibility requirements.

S05 Design Tokens Resolver Module

Source: Original report.
Maturity: DTCG Final Community Group Report; not a W3C Recommendation.
Status: Verified content related to multiple contexts, sets, modifiers, contexts, and resolution organization.
What it supports: The same set of design values can be resolved differently in different contexts, reducing duplicate maintenance. Supports the engineering direction of organizing dimensions such as space, density, and theme separately.
What it does not support: The Resolver does not measure the current window on the application's behalf, nor does it guarantee that design tools switch modes automatically. This project's context tables and override-file examples are not equivalent to a complete, schema-validated Resolver configuration.

4. Readability, Input, and Accessibility

The normative basis for these entries is the formal WCAG 2.2 text. The Understanding links below are used to interpret the requirements and their applicable boundaries. The formal text was opened; this judgment covers only the relevant success criteria listed below, and no full conformance review was conducted.

S06 WCAG 1.4.10 — Reflow, AA

Source: Understanding Reflow.
Status: Verified content related to the success criterion, the two-dimensional layout exception, tables, zoom, and fixed regions.
What it supports: The requirement that vertically scrolling content reflow at an equivalent 320 CSS px width and horizontally scrolling content at an equivalent 256 CSS px height; content that truly requires two-dimensional layout has an exception. Supports R3-1, R3-4, and the fixed-region check.
Boundaries: The exception for tables does not automatically extend to page titles, search, and pagination; cells must be checked separately by content. 320 CSS px is a reflow test condition; it does not require the product to add a new visual mode for "320px devices."

S07 WCAG 1.4.4 — Resize Text, AA

Source: Understanding Resize Text.
Status: Verified the success criterion and the explanation of responsive font size and zoom.
What it supports: Except for specified exceptions, text can be resized up to 200% without loss of content or functionality; supports R3-2.
Boundaries: Using rem for font size or having a fluid font-size formula cannot be used to directly determine a pass; controls and the actual zoom result must still be checked. 200% text resizing and equivalent 320 CSS px reflow are different checks and cannot substitute for each other.

S08 WCAG 2.5.8 — Target Size (Minimum), AA

Source: Understanding Target Size (Minimum).
Status: Verified the size, spacing, and exception explanations.
What it supports: Pointer targets are at least 24×24 CSS px, or meet explicit exceptions such as spacing, equivalent target, inline, user-agent controlled, or essential; supports R5-2.
Boundaries: The 44×44 CSS px important touch target recommended by this project is a design starting point, and cannot be labeled as AA's uniform minimum. Circular or irregular shapes, hit-area spacing, and overlap need specific checks; a single width variable cannot be checked alone.

S09 WCAG 1.3.4 — Orientation, AA

Source: Understanding Orientation.
Status: Verified the success criterion and the exception for orientation restriction.
What it supports: Except where a specific orientation is essential, display is not restricted to a single orientation only; supports R2-4.
Boundaries: Usability in both landscape and portrait does not mean the soft keyboard, visible height, and safe area have already been handled correctly; these are verification scenarios raised separately by this topic.

S10 WCAG 2.4.3 — Focus Order, A

Source: Understanding Focus Order.
Status: Verified the relationship between focus order and meaning and operability.
What it supports: Sequential navigation needs to preserve meaning and operability; supports R4-2.
Boundaries: This does not require visual position and DOM order to match pixel-for-pixel in every layout; how to preserve object focus and semantic reading position across layouts is a product behavior further proposed by this specification.

5. Engineering Implementation and User Preferences

S11 MDN — Using CSS custom properties

Source: Official documentation.
Status: Verified the explanation of var()'s scope of use returned by the official search, but the full text was not reviewed.
What it supports: var() cannot directly substitute for media-query or container-size-query thresholds; supports the recommendation that breakpoints output concrete values at build time.
Boundaries: This limitation must not be misstated as "container queries cannot involve custom properties"; container style queries are a different mechanism. This project does not designate a single build tool or plugin.

S12 MDN — hover media feature

Source: Official documentation.
Status: Verified the explanation of the hover capability of the primary input mechanism.
What it supports: Input capability can be used as a query condition, supporting R5-1's separate handling of hover and window width.
Boundaries: A query on the primary input mechanism does not represent all input on the device, nor does it prove that the user is currently using only one type of input. Critical actions still need an actually reachable path.

S13 MDN — prefers-reduced-motion

Source: Official documentation.
Status: Verified the explanation of detecting and applying the reduced-motion preference.
What it supports: System preference can participate in motion-style selection, supporting R5-4 and an independent motion context.
Boundaries: Detecting the preference does not mean an alternative design has already been completed. Status indication and business continuity after motion is turned off are implemented by the product; MDN does not directly specify all of this document's behavioral requirements.

6. Supplementary Technical and Acceptance Basis

The following were opened and the relevant body text was checked; the page examples were not run. S03, S04, S05, S06, and S07 were also re-checked for mechanisms and boundaries relevant to this addition; the other entries retain their original reading scope, and this is not extended to claim a full re-review of all of them.

S14 WCAG 1.4.12 — Text Spacing, AA

Source: W3C Understanding Text Spacing.
What it supports: Content and functionality are not lost after the user overrides line height, paragraph spacing, letter spacing, and word spacing; language and writing systems have applicable property boundaries. Used for R3-2 and text-spacing acceptance.
What it does not support: Does not require the default heading line height to reach 1.5, nor does it convert the four test values into minimum values for all tokens.

S15 WCAG 2.4.11 — Focus Not Obscured (Minimum), AA

Source: W3C Understanding Focus Not Obscured.
What it supports: The keyboard-focused component is not entirely hidden by author-created content; cases where the user can move or actively open content are handled per the criterion's notes. Used for R4-4.
What it does not support: The AA minimum requirement does not mean every focused object is always fully visible; nor can it be used to prove that system soft-keyboard avoidance has passed.

S16 Visual Viewport, Viewport Units, and Environment Variables

Source: MDN VisualViewport, CSS length, env().
What it supports: The layout viewport and the visual viewport can differ; a soft keyboard may shrink the latter without changing the former. Small, large, and dynamic viewport units describe different viewport sizes; env() provides environment values and fallbacks. Used for R2-4 and the safe-area consumption example.
Project judgment: Does not treat dvh or the safe area as a guarantee of keyboard height; acceptance is based on the actual input, scrolling, and submission tasks on the target browsers. Whether to take the larger value or add them together for spacing is decided by design intent, not a single formula mandated by the documentation.
Boundaries: Keyboard behavior has not been verified across all browsers, embedded WebViews, and devices; an available API does not mean the component has already correctly handled zoom, offset, and scrolling.

S17 HTML — Responsive Images

Source: WHATWG HTML Images.
What it supports: Using srcset/sizes to express resource candidates and display size, and picture to select composition conditionally; image dimension information supports reserving layout space. Used for R4-3 and the media case.
Boundaries: The introductory section read is explanatory material; it does not prescribe this project's crop ratios or performance budget. Whether the full view of different images and their alternative descriptions are sufficient still needs to be judged by the specific task; network quality is not inferred from window width.

S18 CSS Logical Axes and Text Metrics

Source: MDN Logical properties: Basic concepts, CSS length.
What it supports: inline/block are determined by the writing mode; ch and ic are based on different glyph metrics and cannot be used as a fixed character count. Used for R2-1, R3-3, and the unit-mapping contract.
Project judgment: Pages query physical width by default, while component examples query the logical inline size; when vertical writing is supported, the axis mapping is explicitly verified rather than automatically interpreting all width names as the same dimension.

7. This Project's Design Judgments

The following are solutions derived from task requirements and the source material; they are not unified provisions from the original source texts.

Project Decision	Rationale	Verification and Adjustment Method
Six principles and 24 rules	Manage task reachability, spatial judgment, readability, continuity, input, and delivery responsibility separately	Test for omissions and attribution disputes using real scenarios
640 / 1024 CSS px default breakpoints	Provide a small number of clear spatial states	Recalibrate based on the content's minimum usable width and long text
16 / 24 / 32px page margins	Establish a simple rhythm for narrow, regular, and wide spaces	Verify using target pages, languages, and content density
1200px content cap, 560px overlay cap	Provide initial constraints for ordinary content pages and dialogs	Adjust separately for reading, workbench, and canvas; not forced to be uniform
Body text's three tiers held at 16px	Maintain baseline readability, adapting mainly through structure and spacing	Verify with actual fonts, user zoom, and multiple languages
44px important touch targets	Adopt a project starting point more generous than the AA size baseline	Check hit-area shape, adjacent targets, and actual operation
Three token layers and context separation	Reduce duplication of synonymous values and limit override scope	Check references, override combinations, and change impact
704px record-panel threshold	Example derivation of 280px list + 24px gap + 400px detail	Calibrate after actual content, long translations, enlarged text, and bidirectional switching; not a standard breakpoint
Merged resolution, scope allow-lists, and whole-file rejection of invalid configuration	Ensure the same input produces an explainable output and avoid a half-applied configuration taking effect	Verify override combinations, circular references, types, and component spatial dependencies; part of this project's consumption contract
Agent entry point and status remain continuously reachable	Layout changes should not break execution control or the information needed for judgment	Across breakpoints during execution, stopping, confirmation, and result viewing

8. Search Leads Not Adopted as Factual Basis

Material's window size class page: Direct access failed this time; third-party reposted class values were not used as a source for this project.
Adobe Spectrum Design tokens page: Opening it directly this time did not yield body text usable for verification, so it was not used to substantiate specific token layering or parameters. Headers and Spacing snippets found in earlier searches also do not carry normative weight for this topic.
Third-party breakpoint roundups, forum discussions, and tutorials: Usable for follow-up searches, but this round's specific technical conclusions return to official documentation, and these materials are not cited to prove industry consensus.

9. Scope of Work and Verification Boundaries

Completed	Not Yet Completed
Searched official layout, token, and accessibility material, verified within the scope above	Systematic literature review and comparison of all design systems
Organized principles, rules, default values, reference examples, and acceptance methods	User task research and numeric calibration for specific businesses
Provided Web CSS and DTCG JSON documentation examples	CSS browser runtime testing, design-tool import, and full Resolver schema validation
Distinguished external requirements from project defaults	Real devices, assistive technology, and full WCAG conformance testing

During implementation, prioritize filling in the target product's content width, container constraints, browser support, and input scenarios; the actual implementation should record verification evidence, and documentation examples should not be treated as default answers that have already passed product verification.

Responsive Design Guidelines

1. Scope and how to read¶

1.1 Scope¶

1.2 Normative terms¶

2. The six principles¶

3. Rules in detail¶

R1 The core task stays continuously reachable¶

R1-1Clarify content and action priorityMUST¶

R1-2Collapsed content retains a clear entry pointMUST¶

R1-3Layout does not change the semantics of an actionMUST¶

R1-4Agent state and control entries stay continuously reachableMUST¶

R2 Layout is based on actual space¶

R2-1Use a clearly defined measurement scope for spaceMUST¶

R2-2Breakpoints are calibrated by content-carrying capacitySHOULD¶

R2-3Define scaling first, then define structural switchingSHOULD¶

R2-4Height, orientation, and keyboard entry into space judgmentMUST¶

R3 Content stays readable¶

R3-1Regular content supports reflowMUST¶

R3-2Text allows scaling up and natural growthMUST¶

R3-3Content width and information density are controlled separatelySHOULD¶

R3-4Overflow of two-dimensional content has a boundaryMUST¶

R4 Operation stays continuous through change¶

R4-1Input and business state do not reset with layoutMUST¶

R4-2Focus and reading order have continuityMUST¶

R4-3Retain the semantic reading position and a return pathSHOULD¶

R4-4Fixed areas and dynamic content do not seize controlMUST¶

R5 Interaction adapts to input and preference¶

R5-1Input capability is not inferred from widthMUST¶

R5-2Hit target and visible size are defined separatelyMUST¶

R5-3Density is an independent design dimensionSHOULD¶

R5-4Layout motion respects the reduced-motion preferenceMUST¶

R6 Design decisions are implementable and verifiable¶

R6-1Deliver change rules and intermediate statesMUST¶

R6-2Numeric tokens establish a correspondence with behavior rulesMUST¶

R6-3Continuous sizes and real content are accepted togetherMUST¶

R6-4Defaults and exceptions are traceableMUST¶

4. Layout and component application examples¶

4.1 Default space states¶

4.2 Component behavior matrix¶

4.3 Web viewport and media content¶

4.4 Deriving layout from task: a record list and detail¶

4.5 How to choose an adaptation approach¶

5. Acceptance checklist¶

5.1 Counterexamples on both sides¶

5.2 Evidence and acceptance conclusion¶

6. Terminology¶

Implementation acceptance scenarios¶

1. Applicability boundaries¶

1.1 Adoption scope and decision responsibility¶

2. Layering and naming¶

2.1 Three-layer structure¶

2.2 Naming conventions¶

3. Context and resolution¶

3.1 Spatial states¶

3.2 Independent dimensions¶

3.3 The determinate contract for merging, aliases, and conflicts¶

3.4 The output contract for units and axes¶

4. Base value dictionary¶

5. Semantic values and responsive mapping¶

5.1 Page and typography¶

5.1.1 Domain-legal values and the resolution-failure contract¶

5.2 Breakpoints, components, and interaction sizes¶

5.2.1 Conditional fields for the record panel¶

5.3 Fixed requirements and adjustable values¶

6. DTCG exchange-format examples¶

7. Web output examples¶

7.1 Container-size consumption and the base fallback¶

7.2 Safe area, visible height, and hit area¶

8. Design and engineering delivery¶

9. Configuration acceptance samples¶

Configuration delivery and validation¶

1. Source Types and Verification Status¶

2. Layout and Component Adaptation¶

S01 Material Design 3 — Canonical layout examples¶

S02 IBM Carbon — 2x Grid¶

S03 MDN — CSS container queries¶

3. Design Token Format and Context¶

S04 Design Tokens Format Module¶

S05 Design Tokens Resolver Module¶

4. Readability, Input, and Accessibility¶