# slop-impeccable.md Дизайн-скилл для генерации лендинга в чате: impeccable. Источники: anthropics/skills (frontend-design, Apache-2.0), pbakaus/impeccable (Apache-2.0), Leonxlnx/taste-skill (MIT), LottieFiles/motion-design-skill (MIT). Ссылки на скрипты и файлы внутри скиллов относятся к их исходным репозиториям; в чате они недоступны. --- name: impeccable description: Use when the user wants to design, redesign, shape, critique, audit, polish, clarify, distill, harden, optimize, adapt, animate, colorize, extract, or otherwise improve a frontend interface. Covers websites, landing pages, dashboards, product UI, app shells, components, forms, settings, onboarding, and empty states. Handles UX review, visual hierarchy, information architecture, cognitive load, accessibility, performance, responsive behavior, theming, anti-patterns, typography, fonts, spacing, layout, alignment, color, motion, micro-interactions, UX copy, error states, edge cases, i18n, and reusable design systems or tokens. Also use for bland designs that need to become bolder or more delightful, loud designs that should become quieter, live browser iteration on UI elements, or ambitious visual effects that should feel technically extraordinary. Not for backend-only or non-UI tasks. version: 4.5.2 user-invocable: true argument-hint: "[shape · audit|critique · animate|bolder|colorize|delight|layout|overdrive|quieter|typeset · adapt|clarify|distill · harden|onboard|optimize|polish · init|document|extract|live|generate] [target]" license: Apache 2.0 --- This skill gives you the tools and permission to create design that earns to be called out-of-distribution craft: Whereas before, your design work would have been safe, timid and measured, you now approach every design task as an award-winning design director with impeccable understanding for what makes exceptional design work: production-grade code, peak creativity, a clear POV, deep understanding of the needs of the client and users, and exceptional craft. Core principles: - Go all out. No hedging, no shortcuts. The deliverable must be complete (except assets the user must provide). - Dream big and bold. Distinct, beautiful, outstanding and highly inspiring work. - Verify in bounded passes, not a loop, and the ceiling covers the whole cycle: screenshots, defect scans, micro-edits, and rebuilds alike. Build fully, inspect once with a batched round (desktop and mobile together on the web; the shipped device classes on a native platform), fix everything it shows in one batch, confirm with at most one more round, and stop polishing. Open-ended self-QA burns the user's money doing worse what the finish handoffs do better. ## Setup 1. Run `/scripts/impeccable context` once per session, where `` is the directory that contains this SKILL.md (the skill folder, not a plugin root two levels above it); keep cwd at the user's project. That base directory resolves every `.claude/skills/impeccable/scripts/impeccable ` command in this skill and its references, and `.claude/skills/impeccable/scripts` is the fallback only when the runtime reports no base directory. On a Windows shell without `sh`, call `.claude/skills/impeccable/scripts/impeccable.cmd` instead. The launcher runs a self-contained binary that ships next to it or is downloaded once on first run; no Node or other runtime is required. Pass a named source file or route as `--target `. It loads PRODUCT.md, DESIGN.md, the matching surface brief, and native-platform guidance when applicable; follow its directives and do not rerun it. 2. Load the request's playbook: its Commands-table reference for an explicit/implied sub-command, or [reference/new-work.md](reference/new-work.md) for a new surface or replacement visual world. Inspect target and incumbent visual truth before editing. When the app cannot run, start with committed visual-regression goldens or screenshot fixtures; verify target and freshness against current tokens, CSS, components, or assets, resolve conflicts, and compare theme/variant captures. 3. After resolving analysis and direction, read [reference/craft-floor.md](reference/craft-floor.md) immediately before any UI edit, including small refinements. It carries the quality floor, the absolute bans, and the reflexes no detector catches. Do not load it for planning-only work. **Launcher unavailable:** On refusal or failure, send a separate message **before the next tool call**: “Context loading did not run; I’ll read the existing project context directly.” Then read existing PRODUCT.md and DESIGN.md without inventing missing context, follow applicable steps 2–3, and continue through permitted tools. This applies to planning and editing; launcher failure alone does not block either. ## How to design - **The brief wins.** Honor pinned aesthetics, eras, materials, fonts, and palettes even when they conflict with a saturated-pattern warning. Redirecting a clear brief toward your taste is failure. - **Refinement preserves; redesign replaces.** Refinement keeps the incumbent identity, behavior, copy, and everything outside scope. Ask before replacing factual copy or adding claims. Redesign keeps product truth, content, function, native affordances, and constraints, but treats the old look as evidence and anti-reference; choose a replacement world in new-work and replace DESIGN.md. Never split the difference into polish on the discarded look. - **Loaded symbols stay out of the decoration.** A subject's world does not license emblems tied to militarism, supremacy, or hate movements as motifs, badges, or ornament, such as the Rising Sun flag's rays, the Confederate battle flag, or Nazi-era insignia and their stylised variants; reach for that world's neutral forms instead. Content that documents such a symbol as fact stays as it is. - **Visual authority is evidence, not a filename.** Missing DESIGN.md alone does not make a project greenfield; new-work decides whether to preserve, expand, or replace the incumbent world. ## Modes The mode names what the visitor's success looks like on this surface. - **Persuade:** the visitor decides and acts; design is the product. Landing pages, marketing, campaigns, pricing. Earn attention and action. Ship real imagery when the brief needs it; follow the committed world, not category habit. - **Operate:** the visitor completes a task. App UI, dashboards, editors, admin, settings, tools. Scanability, consistency, native expectations, and the real usage scene outrank expression. Brand lives in precise details. - **Read:** the visitor understands something. Docs, articles, guides, help, changelogs. Structure for comprehension, then make the reading experience worth staying in. - **Experience:** the visitor is inside the work itself. Portfolios, galleries, showcases. Let the artifact lead from the first viewport; the interface recedes. Choose the mode from the requested surface, not the product, and persist it only in that surface brief. A tool's landing page is still Persuade; a fashion house's documentation is still Read; a docs index is Read, not Persuade. See [new-work.md](reference/new-work.md) for new surfaces and [operate.md](reference/operate.md) for deeper Operate/Read guidance. ## Commands | Command | Category | Description | Reference | |---|---|---|---| | `craft [feature]` | Build | Deprecated alias for an ordinary new-work request | [reference/craft.md](reference/craft.md) | | `shape [feature]` | Build | Plan UX/UI before writing code | [reference/shape.md](reference/shape.md) | | `init` | Build | Capture durable product context in PRODUCT.md | [reference/init.md](reference/init.md) | | `document` | Build | Generate DESIGN.md from existing project code | [reference/document.md](reference/document.md) | | `extract [target]` | Build | Pull reusable tokens and components into design system | [reference/extract.md](reference/extract.md) | | `critique [target]` | Evaluate | UX design review with heuristic scoring | [reference/critique.md](reference/critique.md) | | `audit [target]` | Evaluate | Technical quality checks (a11y, perf, responsive) | [reference/audit.md](reference/audit.md) · native: [reference/audit.native.md](reference/audit.native.md) | | `polish [target]` | Refine | Final quality pass before shipping | [reference/polish.md](reference/polish.md) | | `bolder [target]` | Refine | Amplify safe or bland designs | [reference/bolder.md](reference/bolder.md) | | `quieter [target]` | Refine | Tone down aggressive or overstimulating designs | [reference/quieter.md](reference/quieter.md) | | `distill [target]` | Refine | Strip to essence, remove complexity | [reference/distill.md](reference/distill.md) | | `harden [target]` | Refine | Production-ready: errors, i18n, edge cases | [reference/harden.md](reference/harden.md) | | `onboard [target]` | Refine | Design first-run flows, empty states, activation | [reference/onboard.md](reference/onboard.md) | | `animate [target]` | Enhance | Add purposeful animations and motion | [reference/animate.md](reference/animate.md) | | `colorize [target]` | Enhance | Add strategic color to monochromatic UIs | [reference/colorize.md](reference/colorize.md) | | `typeset [target]` | Enhance | Improve typography hierarchy and fonts | [reference/typeset.md](reference/typeset.md) | | `layout [target]` | Enhance | Fix spacing, rhythm, and visual hierarchy | [reference/layout.md](reference/layout.md) | | `delight [target]` | Enhance | Add personality and memorable touches | [reference/delight.md](reference/delight.md) | | `overdrive [target]` | Enhance | Push past conventional limits | [reference/overdrive.md](reference/overdrive.md) | | `clarify [target]` | Fix | Improve UX copy, labels, and error messages | [reference/clarify.md](reference/clarify.md) | | `adapt [target]` | Fix | Adapt for different devices and screen sizes | [reference/adapt.md](reference/adapt.md) · native: [reference/adapt.native.md](reference/adapt.native.md) | | `optimize [target]` | Fix | Diagnose and fix UI performance | [reference/optimize.md](reference/optimize.md) | | `live` | Iterate | Visual variant mode: pick elements in the browser, iterate on alternatives | [reference/live.md](reference/live.md) | | `generate [n] [action] [element]` | Iterate | Variants, versions, or alternatives of a named element to choose from in the live browser; no manual picking | [reference/generate.md](reference/generate.md) | Routing: - **No argument:** read [routing.md](reference/routing.md) and present its context-aware menu; never auto-run a command. - **Explicit or clearly implied request to run a command:** load its reference (native variant on native platforms) and follow it. Ask once if two commands fit. - **Workflow or command-selection question:** read [Workflow questions](reference/routing.md#workflow-questions). - **Otherwise:** treat the request as general design work. Missing PRODUCT.md routes a new surface or replacement world through init, then new-work; a narrow refinement of existing code proceeds on the incumbent implementation as `impeccable context` directs, offering init afterward rather than blocking on it. - `teach` aliases `init`. `craft` is a deprecated alias for ordinary new-work and adds nothing. `shape` owns task discovery, then enters new-work only for visual-world and surface-concept decisions. After init writes PRODUCT.md, resume without rerunning `impeccable context`; init loads the native platform reference itself when the platform it recorded is `ios`, `android`, or `adaptive`. **Pin / Unpin:** `.claude/skills/impeccable/scripts/impeccable pin ` creates or removes a standalone `/` shortcut. Report the script's result concisely; relay stderr verbatim on error. **Hooks:** `/impeccable hooks ` manages the design detector hook for this project (auto-runs the detector after UI file edits and surfaces findings). Load [reference/hooks.md](reference/hooks.md) when the user invokes it with any argument. **Doctor:** `/impeccable doctor` reports and repairs drift between this project's Impeccable artifacts (PRODUCT.md, DESIGN.md and its sidecar, config, surface briefs, the hook) and what this version reads. Load [reference/doctor.md](reference/doctor.md) when the user invokes it, or when they ask what is out of date, stale, or needs refreshing. A `CONTEXT_STALE` directive in Setup's output is the cheap subset of the same report; act on it there per its own instructions rather than running doctor unasked. **Never repair drift as a side effect of a design task.** A `CONTEXT_STALE` finding is reported, not acted on, unless the user asks. The one exception is a finding marked `auto`, which the next write to that file performs anyway. # Craft floor Load this after the direction is settled, and build without announcing the checklist. A pinned brief or the committed visual world overrides anything here; your own habit does not. When the design hook is active it already enforces the mechanical checks below as you edit: act on its findings instead of re-auditing each rule. ## Verify Each of these is a check on the built result, not an intention. Run them together in the batched inspection rounds, not as separate screenshot trips; the checks share one render. - **Contrast:** body and placeholder text ≥4.5:1, large text ≥3:1. On colored surfaces tint secondary text from that hue or the foreground; never gray. - **Depth:** shadows carry an offset and a soft blur. A zero-offset colored halo is decoration. - **Spacing:** tight groups, generous separation, more space above a heading than below it. Read the computed values. - **Type:** body measure 65–75ch, display max 6rem, tracking floor -0.04em, balanced headings, obvious scale and weight steps. Run the real copy at every breakpoint and fix what overflows. - **Motion:** one authored moment, not scattered effects and not one identical entrance on every section. Exponential ease-out from an already-visible default. Reach past transform and opacity: blur, backdrop-filter, clip-path, mask, and shadow belong to the palette when they stay smooth. - **States:** hover, disabled, loading, error, empty. Plus real content, working controls, responsive composition, keyboard focus. - **Browser surfaces:** the parts you did not draw still carry the design. Text selection, the caret, custom scrollbars, focus rings, underline offset, and the numerals in tabular data all ship with browser defaults that belong to no design system. Theme them from the palette. This is the cheapest signal that a page was built rather than assembled, and the one models skip most reliably. - **Copy:** the product's own language. Controls name their action; errors name the problem and the recovery. - **Coverage:** every brief requirement present and findable within seconds. ## Refuse These are the category's defaults, not bans: the brief's own words can earn any of them. Reaching for one when the axis is free means you were not deciding; recognizing that means rewriting the element, not softening it. Page scaffolds: - Same-size cards of icon plus heading plus text as the page structure. Cards are the lazy container; nested cards are always wrong. - The hero-metric template: big number, small label, supporting stats, accent. - A kicker or eyebrow above a heading. This one is a ban, not a default: no brief earns it back. The heading carries its own weight; delete the label and let the heading speak. - Section numbers (01 / 02 / 03) unless the sequence itself carries information the reader needs. - A modal for a task that needs neither interruption nor protected focus. Surface habits: - Gradient text. Emphasis comes from weight or size. - Glass and blur as decoration rather than as a specific effect. - A colored `border-left` or `border-right` above 1px on cards, list items, callouts, or alerts. - Hard offset shadows (`box-shadow: 4px 4px 0`) outside a world that is actually neobrutalist. The zero-blur block shadow is a costume, not a depth system; a world that did not choose it never earns it as a default. - Sparklines, progress rings, and soft-shadowed rounded rectangles standing in for content. - Monospace as a costume for "technical" rather than for code, data, or measurement. - A system display face (Impact, Arial Black, the platform sans) as the display voice of an own-world page. Source and self-host a face whose character matches the approved lettering; the closest installed font is a failure, not a fallback. - Unicode glyphs or emoji standing in for an icon system. Icons are drawn, from a real library or authored SVG, in one consistent stroke and weight. - Geometric masks standing in for organic contours. A circle, polygon, or radial-gradient cutout approximating a photographic subject's edge is the cheap version of the effect and reads worse than omitting it. Derive an alpha matte from the actual image, or produce a cut-out asset. - Light or dark picked by category. Pick it from the use scene: who, where, under what ambient light. The floor holds the mechanics; it never picks the direction. With every check green, spend the page on the committed world, and when torn between refined and committed, commit. # Persuade and Experience `impeccable concept-seed --mode persuade` (or `experience`) prints the two sections below as its MODE RULES block. On these surfaces the design is what the visitor judges, so the world may own and structure the page. ## Directions When a catalog world's source is itself an interface language, the surface may carry its native grammar across navigation, content, controls, and states, within the platform conventions a native app keeps. For **Persuade**, the opening must make the offer intelligible and desirable, expose a clear action, and demonstrate something only this product can prove. The action is the one the category's visitors came to take, in its working form: an airline's route-and-dates search, a clinic's open appointment slots, a store's add to cart. A decorative link pointing at it elsewhere does not count. Conversion lives inside the form's own vocabulary: a hook that lands in one line, a visible primary action, a legible reading order. A committed form that hides the offer or the action has not finished translating. For **Experience**, the work itself leads from the first viewport. ## Comps The world may be the carrier of the page, never a picture of it: a facade, a shutter or a book can be what the page is built on, while a viewport painted whole as a facade, a book cover or a travel poster, with no working parts in it, is a picture of the world, not its website. Material coverage is wanted: the world's material is the ground and the major surfaces, its type sets the headlines, and a world reduced to an accent on a neutral template is the category default with a sticker on it. Coverage is not performance: how many regions act out the concept is limited by the depth rule in visualize.md, and the rest stay in the world's material without performing it. Both ends erase the direction: the painted poster, and the generic product page (a headline over subcopy and a button, a row of equal cards below). The dealt composition sets the skeleton, and the compositions you write for comps two and three answer to the same test: a split hero (copy on one side, the product on the other, a badge row under it) or a centred headline over a row of cards is the template whatever world paints it. The world carries the page's parts and never absorbs them, so wherever it puts one, the page still works as a page: navigation set into a facade reads as links, copy on a shutter as set text a visitor reads, an action on a door plaque as plainly clickable, text reads against whatever sits behind it, the sections keep a steady vertical rhythm, the primary action is unmistakable, and the section below starts as a section rather than more painting. Fix a poster by making its parts work where the world put them, never by moving them into a standard layout on the world's colour: a cover that becomes copy beside a device on marigold has lost the cover. When the world is an object, the page is that one object seen once, at one scale and from one point of view, and the object keeps its real form: a book opens to two pages on one gutter, never a third panel, and a spine that carries the navigation belongs to the book on the page, never a second book beside it. More content goes on the object's own surfaces or on the next spread below, never on extra copies or impossible folds. Comps two and three each go further than the first, never cleaner: a bolder use of the same world, where the world's material carries more of the page's structure (still one dominant move, per the depth rule), a larger or stranger focal move, or a composition the category would not attempt. > **Additional context needed**: target platforms/devices and usage contexts. Adapt an existing design to a different context: another screen size, device, platform, or use case. The trap is treating adaptation as scaling. The job is rethinking the experience for the new context. **Web only** (mobile web included). Native platforms (`ios` / `android` / `adaptive`) route to [adapt.native.md](adapt.native.md) instead; if the project is native, switch to it now. --- ## Assess Adaptation Challenge Understand what needs adaptation and why: 1. **Identify the source context**: - What was it designed for originally? (Desktop web? Mobile app?) - What assumptions were made? (Large screen? Mouse input? Fast connection?) - What works well in current context? 2. **Understand target context**: - **Device**: Mobile, tablet, desktop, TV, watch, print? - **Input method**: Touch, mouse, keyboard, voice, gamepad? - **Screen constraints**: Size, resolution, orientation? - **Connection**: Fast wifi, slow 3G, offline? - **Usage context**: On-the-go vs desk, quick glance vs focused reading? - **User expectations**: What do users expect on this platform? 3. **Identify adaptation challenges**: - What won't fit? (Content, navigation, features) - What won't work? (Hover states on touch, tiny touch targets) - What's inappropriate? (Desktop patterns on mobile, mobile patterns on desktop) **CRITICAL**: Adaptation is rethinking the experience for the new context, not scaling pixels. ## Plan Adaptation Strategy Create context-appropriate strategy: ### Mobile Adaptation (Desktop → Mobile) **Layout Strategy**: - Single column instead of multi-column - Vertical stacking instead of side-by-side - Full-width components instead of fixed widths - Bottom navigation instead of top/side navigation **Interaction Strategy**: - Touch targets 44x44px minimum (not hover-dependent) - Swipe gestures where appropriate (lists, carousels) - Bottom sheets instead of dropdowns - Thumbs-first design (controls within thumb reach) - Larger tap areas with more spacing **Content Strategy**: - Progressive disclosure (don't show everything at once) - Prioritize primary content (secondary content in tabs/accordions) - Shorter text (more concise) - Larger text (16px minimum) **Navigation Strategy**: - Hamburger menu or bottom navigation - Reduce navigation complexity - Sticky headers for context - Back button in navigation flow ### Tablet Adaptation (Hybrid Approach) **Layout Strategy**: - Two-column layouts (not single or three-column) - Side panels for secondary content - Master-detail views (list + detail) - Adaptive based on orientation (portrait vs landscape) **Interaction Strategy**: - Support both touch and pointer - Touch targets 44x44px but allow denser layouts than phone - Side navigation drawers - Multi-column forms where appropriate ### Desktop Adaptation (Mobile → Desktop) **Layout Strategy**: - Multi-column layouts (use horizontal space) - Side navigation always visible - Multiple information panels simultaneously - Fixed widths with max-width constraints (don't stretch to 4K) **Interaction Strategy**: - Hover states for additional information - Keyboard shortcuts - Right-click context menus - Drag and drop where helpful - Multi-select with Shift/Cmd **Content Strategy**: - Show more information upfront (less progressive disclosure) - Data tables with many columns - Richer visualizations - More detailed descriptions ### Print Adaptation (Screen → Print) **Layout Strategy**: - Page breaks at logical points - Remove navigation, footer, interactive elements - Black and white (or limited color) - Proper margins for binding **Content Strategy**: - Expand shortened content (show full URLs, hidden sections) - Add page numbers, headers, footers - Include metadata (print date, page title) - Convert charts to print-friendly versions ### Email Adaptation (Web → Email) **Layout Strategy**: - Narrow width (600px max) - Single column only - Inline CSS (no external stylesheets) - Table-based layouts (for email client compatibility) **Interaction Strategy**: - Large, obvious CTAs (buttons not text links) - No hover states (not reliable) - Deep links to web app for complex interactions ## Implement Adaptations Apply changes systematically: ### Responsive Breakpoints Choose appropriate breakpoints: - Mobile: 320px-767px - Tablet: 768px-1023px - Desktop: 1024px+ - Or content-driven breakpoints (where design breaks) ### Layout Adaptation Techniques - **CSS Grid/Flexbox**: Reflow layouts automatically - **Container Queries**: Adapt based on container, not viewport - **`clamp()`**: Fluid sizing between min and max - **Media queries**: Different styles for different contexts - **Display properties**: Show/hide elements per context ### Touch Adaptation - Increase touch target sizes (44x44px minimum) - Add more spacing between interactive elements - Remove hover-dependent interactions - Add touch feedback (ripples, highlights) - Consider thumb zones (easier to reach bottom than top) ### Content Adaptation - Use `display: none` sparingly (still downloads) - Progressive enhancement (core content first, enhancements on larger screens) - Lazy loading for off-screen content - Responsive images (`srcset`, `picture` element) ### Navigation Adaptation - Transform complex nav to hamburger/drawer on mobile - Bottom nav bar for mobile apps - Persistent side navigation on desktop - Breadcrumbs on smaller screens for context **IMPORTANT**: Test on real devices. Device emulation in DevTools is helpful but not perfect. **NEVER**: - Hide core functionality on mobile (if it matters, make it work) - Assume desktop = powerful device (consider accessibility, older machines) - Use different information architecture across contexts (confusing) - Break user expectations for platform (mobile users expect mobile patterns) - Forget landscape orientation on mobile/tablet - Use generic breakpoints blindly (use content-driven breakpoints) - Ignore touch on desktop (many desktop devices have touch) ## Verify Adaptations Test thoroughly across contexts: - **Real devices**: Test on actual phones, tablets, desktops - **Different orientations**: Portrait and landscape - **Different browsers**: Safari, Chrome, Firefox, Edge - **Different OS**: iOS, Android, Windows, macOS - **Different input methods**: Touch, mouse, keyboard - **Edge cases**: Very small screens (320px), very large screens (4K) - **Slow connections**: Test on throttled network **Custom controls** (sliders, drag surfaces, scrollable control strips): a before/after slider can pass every width check above and still refuse to drag on iOS, so exercise each one in scope in the same batched round as the checks above: - **Primary gesture**: Tap it and confirm it responds as designed, then drag it with the target input method; the drag must complete, not just start - **Scroll across it**: A swipe along the page's scroll axis across the control scrolls the page or container without activating it; a drag that starts on the control along its axis moves the control, not the page. Neither failure throws an error, so try both - **Evidence**: Say what produced the evidence: an emulated viewport, synthesized touch input through a browser tool, which engine ran it (Chromium is not Safari), or a physical device. Screenshots and resized viewports verify layout, never a gesture. Name what stayed untested and move on; unreachable hardware is a reported gap, not a blocker When the adaptation feels native to each context, hand off to `/impeccable polish` for the final pass. --- ## Reference Material The sections below were previously `responsive-design.md` and live inline now so the adapt flow has its deep responsive reference in one place. ### Responsive Design #### Mobile-First: Write It Right Start with base styles for mobile, use `min-width` queries to layer complexity. Desktop-first (`max-width`) means mobile loads unnecessary styles first. #### Breakpoints: Content-Driven Don't chase device sizes; let content tell you where to break. Start narrow, stretch until design breaks, add breakpoint there. Three breakpoints usually suffice (640, 768, 1024px). Use `clamp()` for fluid values without breakpoints. #### Detect Input Method, Not Just Screen Size **Screen size doesn't tell you input method.** A laptop with touchscreen, a tablet with keyboard. Use pointer and hover queries: ```css /* Fine pointer (mouse, trackpad) */ @media (pointer: fine) { .button { padding: 8px 16px; } } /* Coarse pointer (touch, stylus) */ @media (pointer: coarse) { .button { padding: 12px 20px; } /* Larger touch target */ } /* Device supports hover */ @media (hover: hover) { .card:hover { transform: translateY(-2px); } } /* Device doesn't support hover (touch) */ @media (hover: none) { .card { /* No hover state - use active instead */ } } ``` **Critical**: Don't rely on hover for functionality. Touch users can't hover. #### Safe Areas: Handle the Notch Modern phones have notches, rounded corners, and home indicators. Use `env()`: ```css body { padding-top: env(safe-area-inset-top); padding-bottom: env(safe-area-inset-bottom); padding-left: env(safe-area-inset-left); padding-right: env(safe-area-inset-right); } /* With fallback */ .footer { padding-bottom: max(1rem, env(safe-area-inset-bottom)); } ``` **Enable viewport-fit** in your meta tag: ```html ``` #### Responsive Images: Get It Right ##### srcset with Width Descriptors ```html Hero image ``` **How it works**: - `srcset` lists available images with their actual widths (`w` descriptors) - `sizes` tells the browser how wide the image will display - Browser picks the best file based on viewport width AND device pixel ratio ##### Picture Element for Art Direction When you need different crops/compositions (not just resolutions): ```html ... ``` #### Layout Adaptation Patterns **Navigation**: Three stages: hamburger + drawer on mobile, horizontal compact on tablet, full with labels on desktop. **Tables**: Transform to cards on mobile using `display: block` and `data-label` attributes. **Progressive disclosure**: Use `
/` for content that can collapse on mobile. #### Testing: Don't Trust DevTools Alone DevTools device emulation is useful for layout but misses: - Actual touch interactions - Real CPU/memory constraints - Network latency patterns - Font rendering differences - Browser chrome/keyboard appearances **Test on at least**: One real iPhone, one real Android, a tablet if relevant. Cheap Android phones reveal performance issues you'll never see on simulators. --- **Avoid**: Desktop-first design. Device detection instead of feature detection. Separate mobile/desktop codebases. Ignoring tablet and landscape. Assuming all mobile devices are powerful.