/* -------------------------------------------------------------------------- Responsive. The desktop/compact switch is a media query near the design's 760 px intent — never a JavaScript width check (finding F20). -------------------------------------------------------------------------- */ @media (max-width: 760px) { .inn-body { padding: 0; } .inn-shell { width: 100%; border: 0; border-radius: 0; box-shadow: none; } .inn-shell #orgH1 { flex-basis: 100%; font-size: 1.3rem; } /* The prototype hides the badge below this breakpoint (`sc-if erDesktop`) because there it is decorative repetition — its

carries the tenant name too. Here the

is the static form title, so the badge is the tenant's ONLY identity whenever there is no logo. Hiding it would leave a narrow viewport with no tenant identity at all, so it stays and is allowed to take its own row instead; `.form-header` already wraps. This is a deliberate, recorded divergence from the prototype, forced by keeping a real page title in the heading. */ .inn-shell .inn-tenant-badge { max-width: 100%; } .inn-shell .form-logo { max-height: 48px; } /* The prototype's own split: below this width five step labels cannot sit side by side, so the horizontal track is replaced by the progressbar rather than compressed. This is what actually fixes the residual 375 px label overlap from finding F28 — the shell-level width shim could only stop the wrapper collapsing, not make the labels fit. */ .inn-shell .inn-steps { display: none; } .inn-shell .inn-steps-mobile { display: block; } /* `sticky`, deliberately not `fixed` — plan.md rev 3 §5. The prototype uses `position: fixed` here plus 96 px of reserved space below the footer. Two reasons this does not: 1. On iOS Safari a fixed bottom bar is positioned against the layout viewport, not the visual one, so when the virtual keyboard opens it can sit under the keyboard or float over the field being typed into. This flow's Person step has about twelve fields. 2. Phase 2 acceptance criterion 5 — the action area never covers a focused control or the validation summary — is currently met *because* the bar is in normal flow, and the risk `fixed` introduces lives in a browser the automated checks here cannot reach (D12 requires iOS Safari; this repo's checks run headless Chrome). `sticky` keeps the reachability the design is after with a bounded failure mode: it stays in flow, so it reserves its own space (no 96 px compensation needed) and is bounded by `.inn-shell`, releasing above the footer on its own. Worst case it simply scrolls with the content — which is today's behaviour. It also adapts without a condition: on a short page such as Start it sits inline instead of floating over nothing. */ .inn-shell .fixed-bottom-navigation { position: sticky; bottom: 0; } /* The prototype's `navFixed` control sizing, restored at exactly the width where the bar becomes sticky. See the long note at the base rules: the design specifies a taller, wider-reaching pair of buttons for the pinned bar than for the in-flow one, and a full-width primary is the whole point of a bar a thumb reaches for. */ .inn-shell .inn-action { min-height: 52px; padding: 0 20px; } .inn-shell .inn-action--primary { flex: 1; margin-left: 0; padding: 0 20px; } /* Load-bearing, and the reason the sticky rule above is allowed to exist at all. Measured without it: focusing a field near the bottom left it **under** the bar — `Address` hidden by 76 px, `Fylkeslag` and `MobPh` by 30 px each — because the browser scrolls a focused element to the edge of the layout viewport and knows nothing about a sticky overlay. That violates Phase 2 acceptance criterion 5 outright. `scroll-padding-bottom` is the property built for exactly this: it reserves space at the bottom of every scroll-into-view, including the implicit one on focus. With it, zero focused fields are covered at 320 px or 375 px. 90 px is the 77 px bar plus breathing room, kept a literal rather than a calc() because the bar's height depends on its content and a slightly generous constant is safer than a clever exact one. */ html { scroll-padding-bottom: 90px; } /* The confirm step is the exception. `Send inn` is irreversible, and a sticky send button invites submitting before the visitor has scrolled through the review summary. The prototype has the same instinct — it excludes `kvittering` from `navFixed` — so this extends an idea already in the design rather than inventing one. */ .inn-shell .fixed-bottom-navigation.inn-actions--confirm { position: static; } .inn-shell .footer .footer-container { justify-content: flex-start; } /* --- consent step, Phase 5C ------------------------------------------------------------------ These two live here rather than in consent.css because this file is where the shell keeps ONE 760 px block, and three contract tests read "the 760 px media query" as a single match. A second block earlier in the cascade makes them assert against the wrong rules. The consent rows themselves need no query: the fieldset wraps, so the pills drop to their own row on their own. */ .inn-shell .inn-consent-heading, .inn-shell .inn-receipt-title, .inn-shell .inn-regerror-title { /* The design's own mobile heading size (Innmelding.dc.html:1794 — `erM ? "22px" : "26px"`). The receipt and error titles are the same `h2Str` variable in the prototype, so they belong in the same rule rather than in a second 760px block — see the note at the foot of receipt.css. */ font-size: 1.375rem; } /* Once the pills have wrapped, a right-aligned pair reads as detached from the text it answers. */ .inn-shell .inn-consent-choices { flex: 1 1 100%; } } @media (min-width: 1440px) { .inn-shell #orgH1 { font-size: 1.8rem; } }