23. Responsive approach and cross-viewport behaviour
Answer as submitted
“My approach separates three concerns: layout adaptation, behavioural adaptation and performance per viewport.”
Expanded answer
The approach separates three concerns so that a change in one does not fight the other two. Layout: mobile-first CSS with a named breakpoint scale, fluid grids and space tokens, container queries for anything reusable, and progressive enhancement so the smallest viewport receives the simplest correct structure. Behaviour: what CSS cannot express — navigation pattern, table versus card rendering, virtual scrolling and chart density — is driven by one observed viewport source (BreakpointObserver or matchMedia) exposed as a signal, so every component reads the same decision. Performance: responsive images with srcset/sizes, lazy loading below the fold, and per-viewport budgets for Core Web Vitals. Accessibility is verified at every breakpoint, not only on desktop: tap targets, focus order, 200% zoom and an accessibility tree that keeps its shape.
| Concern | How it is handled | Why it is done this way |
|---|---|---|
| Layout | mobile-first layers, named breakpoints, fluid tokens | The constrained case is the default, so it cannot be forgotten. |
| Fluidity vs steps | clamp() and flexible grids; discrete changes only when behaviour changes | Removes most breakpoints entirely and reduces override debt. |
| Reusable components | container queries | A component adapts to its slot, so one card serves sidebar, modal and panel. |
| Behaviour | one observed viewport signal (BreakpointObserver/matchMedia) | Structural decisions are testable and identical across components. |
| Assets | srcset/sizes, art direction, lazy loading | Mobile transports a fraction of the bytes without shrinking a desktop image. |
| Accessibility | 44 px targets, zoom to 200%, identical a11y tree at every breakpoint | A layout change must never remove access for someone. |
| Verification | device matrix in CI with vitals budgets | Regressions are caught by the pipeline, not by a customer. |
Live responsive-strategy workflow proof
The running component below changes its decision/result view through real event binding. Select a step to see the approach, the reasoning behind it, and the measurement that shows it working.
Choose a strategy step
Select a step to inspect the approach, the reasoning and the measured result.
$ @include from('tablet') { … } — the base layer is the smallest layout
The smallest layout is the default and complexity is added upwards, so the constrained case is the one that cannot be forgotten and fewer properties get overridden.
media-query overrides per component: 6 → 2 320 px renders fully with no media query at all
Where the line is drawn
Source files
Select a file to inspect the proof with syntax highlighting and line numbers. The first file is the code running the component above; the other two are the production shapes of the same approach.
Acceptance criteria
- Separates layout, behaviour and per-viewport performance explicitly.
- Starts from the smallest layout and adds complexity upwards.
- Shows an interactive proof of choosing a strategy step and reading its measurement.
- Keeps structural decisions in one observable, testable viewport signal.
- Defers design-system governance, native mobile design and layout experimentation to a later topic.