ui-ux-mobile-css
Skill0 starsChanged 3 months agoApache-2.0View on GitHub
Generate, implement, or review stable mobile CSS behavior for smooth anchor navigation, modal scroll containment and locking, iOS form-control zoom prevention, tap feedback, visible focus, dynamic viewports, and real-device verification. Use whenever mobile or responsive interface CSS is created or changed.
In this repository46 other files it gives its agents.
- AGENTS.mdAGENTS.md
- academixSkill
- agent-browserSkill
- ai-engineering-platformSkill
- apocalypseSkill
- aria-apg-reviewSkill
- context-budgetSkill
- crawler-readiness-auditSkill
- data-protection-gateSkill
- decision-criticality-gateSkill
- fact-checkerSkill
- find-skillsSkill
- focus-friendly-outputSkill
- frontend-designSkill
- grill-meSkill
- grill-with-docsSkill
- humanizerSkill
- improve-codebase-architectureSkill
- microsoft-foundrySkill
- output-templatesSkill
- pre-launch-security-gateSkill
- prompt-preflightSkill
- quick-recapSkill
- rag-retrieval-qualitySkill
- rest-api-best-practicesSkill
- rigorous-responseSkill
- security-checklistSkill
- shepherdSkill
- skill-optimizerSkill
- sql-query-correctnessSkill
- system-design-scaleSkill
- tddSkill
- ui-ux-color-contrastSkill
- ui-ux-component-qualitySkill
- ui-ux-design-systemsSkill
- ui-ux-dropdownsSkill
- ui-ux-form-validationSkill
- ui-ux-generationSkill
- ui-ux-loading-statesSkill
- ui-ux-typographySkill
- ux-logic-loopSkill
- ux-pattern-reviewSkill
- vercel-react-best-practicesSkill
- visual-flow-storyboardSkill
- visual-pr-reviewSkill
- web-design-guidelinesSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. About 0 are common, 8 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
Use the platform's native behavior first, then add the smallest CSS needed to keep mobile interaction stable and intentional.
- Distinctive: line 54
Do not replace a working anchor with JavaScript only to animate it.
- Very specific: line 61
Do not treat overscroll-behavior alone as a complete background scroll lock, especially on iOS Safari.
- Distinctive: line 62
Keep close controls reachable, respect safe-area insets, and restore focus to the opener.
- Very specific: line 67
Never use user-scalable=no or a restrictive maximum-scale to suppress zoom.
- Distinctive: line 68
Avoid fixed-height form shells and focus animations that cause page jumps when the on-screen keyboard opens.
- Very specific: line 69
Use dynamic viewport units such as dvh or svh deliberately instead of assuming 100vh remains stable under mobile browser chrome.
- Distinctive: line 73
Keep the native tap highlight unless the visual system requires a custom replacement.
- Very specific: line 74
If removing -webkit-tap-highlight-color, scope the rule to interactive elements rather than * and provide a clearly visible :active state.
- Very specific: line 75
Use color, background, opacity, or shadow changes that do not shift layout.
- Very specific: line 79
Keep a visible :focus-visible indicator with sufficient contrast and separation from the control.
- Very specific: line 80
Never use outline: none or outline: 0 without an accessible replacement in the same rule set.
- Distinctive: line 81
Keep focus styling distinct from hover and active styling and visible in every supported theme.
- Distinctive: line 85
Leave one runnable regression check where the project has browser tests, then verify on representative real mobile viewports:
- Distinctive: line 93
Use actual mobile viewport sizes, including narrow widths, and test real iOS Safari for release-critical behavior.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
UI/UX Mobile CSS
Use the platform's native behavior first, then add the smallest CSS needed to keep mobile interaction stable and intentional.
Baseline
@media (prefers-reduced-motion: no-preference) {
html {
scroll-behavior: smooth;
}
}
input,
select,
textarea {
font-size: max(16px, 1rem);
}
.modal__scroll {
overflow: auto;
overscroll-behavior: contain;
}
:where(a, button, input, select, textarea, [role="button"]):focus-visible {
outline: 2px solid var(--focus-ring, currentColor);
outline-offset: 2px;
}Adapt selectors and tokens to the existing product. Do not add a parallel reset or token layer.
Required rules
1. Make anchor navigation smooth without forcing motion
- Preserve real fragment links and native browser history.
- Enable smooth scrolling only inside
prefers-reduced-motion: no-preference; reduced-motion users must get immediate navigation. - Give anchor targets
scroll-margin-block-startwhen sticky headers would cover them. - Do not replace a working anchor with JavaScript only to animate it.
2. Stop modal scroll leakage
- Reuse the existing modal or dialog primitive's scroll lock when available.
- Lock the actual page scroll root while the modal is open and restore its exact scroll position and prior styles when it closes.
- Make the modal's content region independently scrollable and apply
overscroll-behavior: containthere. - Do not treat
overscroll-behavioralone as a complete background scroll lock, especially on iOS Safari. - Keep close controls reachable, respect safe-area insets, and restore focus to the opener.
3. Prevent focus zoom without disabling user zoom
- Render
input,select, andtextareatext at no less than16pxon mobile. - Never use
user-scalable=noor a restrictivemaximum-scaleto suppress zoom. - Avoid fixed-height form shells and focus animations that cause page jumps when the on-screen keyboard opens.
- Use dynamic viewport units such as
dvhorsvhdeliberately instead of assuming100vhremains stable under mobile browser chrome.
4. Preserve touch feedback
- Keep the native tap highlight unless the visual system requires a custom replacement.
- If removing
-webkit-tap-highlight-color, scope the rule to interactive elements rather than*and provide a clearly visible:activestate. - Use color, background, opacity, or shadow changes that do not shift layout. Preserve a minimum
44pxtouch target where the product has no stricter rule.
5. Preserve keyboard focus
- Keep a visible
:focus-visibleindicator with sufficient contrast and separation from the control. - Never use
outline: noneoroutline: 0without an accessible replacement in the same rule set. - Keep focus styling distinct from hover and active styling and visible in every supported theme.
Verification
Leave one runnable regression check where the project has browser tests, then verify on representative real mobile viewports:
- Activate fragment links with normal and reduced-motion preferences and confirm the target is not hidden by sticky UI.
- Open a long modal, scroll its content to both edges, and confirm the page behind it never moves.
- Focus every form-control type in iOS Safari and confirm no automatic page zoom, horizontal jump, or unstable layout occurs.
- Confirm every removed tap highlight has visible pressed feedback and every interactive element retains visible keyboard focus.
- Exercise portrait, landscape, dynamic browser chrome, the on-screen keyboard, safe areas, and pinch zoom.
Use actual mobile viewport sizes, including narrow widths, and test real iOS Safari for release-critical behavior. A desktop responsive preview does not prove touch, virtual-keyboard, or Safari scroll-lock behavior. State any unavailable device checks explicitly.
Output
Return the CSS or implementation changes first, then the tested viewport/browser matrix and any unverified device behavior.
Shared output profile
Compose the execution profile from output-templates.
Preserve the mobile interaction rules above, omit empty components, and never present desktop emulation as real-device verification.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

