Antislop Layoutmobile

antislop-layoutmobile

Anti Slop: Rules for AI Coding Agents. Mobile Layout skill

Part of the antislop system. Read together with antislop.md (the core). This skill deep-dives the responsive layout concern: how a layout must reflow across screen sizes, phone to desktop. Breakpoints, scale, grids, overflow, tap targets, and navigation. It references core rules by number and never duplicates or renumbers them. Load it when the task builds or edits a layout that has to hold up at any screen width.

How to use this skill

• Load together with antislop.md whenever the task is mobile or responsive layout work. The core holds the mechanism (the purpose test, the three tiers, the Delivery Gate); this skill holds mobile-layout depth.
• Every entry has the same shape: Tell (the pattern), Why (why it reads as slop), Fix (what to do instead), with the governing core rule cited as R-XX.
• The principle behind this skill: mobile layout is a different layout, not the desktop layout at a smaller size. It must reflow: re-stack, rescale, and re-order with intent. Every pattern below is a way a layout fails to reflow.
• The Delivery Gate in the core remains the gate. The "Layoutmobile Skill Checklist" at the end of this file is the mobile-specific supplement to run alongside it.

Breakpoints

Desktop-Only Layout

• Tell: one layout state for every screen; the mobile view is the desktop layout squeezed into a phone.
• Why: R-03 requires a mobile layout that is perfect, not an afterthought. A page that only shrinks has no mobile design at all: cards that worked side by side overlap, and text meant for a wide canvas crowds into a narrow one.
• Fix: define a real mobile state at the breakpoint where the content stops working. The mobile layout reflows: columns stack, sizes drop, and order changes where the content needs it. If the mobile view is just the desktop view at a smaller width, the layout is not done.

Breakpoint Driven by Device List

• Tell: breakpoints named after phone widths (375px, 414px, 768px) chosen because "that is the iPhone size", not because the content breaks there.
• Why: device widths change every year and every model. A breakpoint is a point where the layout stops holding; forcing it to match a device list makes the layout follow a spec sheet instead of the content (R-03).
• Fix: place breakpoints where the content actually breaks: when a column stops being readable, when a row of cards gets too narrow. Test by narrowing the viewport and watching where it snaps, then set the breakpoint there.

Mobile Styled Last

• Tell: mobile rules bolted on as a trailing override: a long desktop stylesheet with a small media query at the end fixing one or two things.
• Why: an override patch is not a mobile design. It fixes the symptom that got reported and leaves the next one, and the base styles stay tuned for a wide screen (R-03).
• Fix: treat mobile as a designed state, not an override. Give the narrow viewport its own deliberate sizes and stacking, and verify the whole layout there, not just the patched spots (R-35).

Two-State Layout

• Tell: a layout with exactly two states: a single stacked column below one breakpoint, and a wide multi-column grid above it, with nothing defined in between. A tablet or small laptop width then inherits whichever state is closest: the phone stack stretched absurdly wide, or the desktop grid crammed into a fraction of its intended canvas.
• Why: a page is a continuous range of widths, and R-03 demands it hold up at every one of them, not just two chosen breakpoints. Two states leave the whole middle band of the range (roughly 600 to 1024 px, where tablets and small laptops live) as an accident: content that neither stacks with intent nor sits in a grid that fits. The layout reads as designed only at its two sample points and broken everywhere between.
• Fix: define real states at the widths where the content stops working, and let them be as many as the content needs. A typical reflow is three states, not two: single column, then a two-column grid when cards get too wide as a single stack, then the full multi-column grid only when it genuinely fits. Verify by dragging the viewport through the whole range, not by checking two widths and calling it done (R-35).

Scale & Sizing

Desktop-Sized Everything

• Tell: padding, gaps, hero heights, and card sizes carried unchanged from desktop to mobile, so every section looks blown up on a phone.
• Why: an element sized for a 1440px canvas dominates a 375px one. What reads as confident on desktop becomes oversized on mobile: nothing fits, nothing breathes, and the page feels like it was designed for a screen that is not the one in hand (R-03). Spacing and type should follow the design rhythm (R-05), and that rhythm has a smaller register on mobile.
• Fix: give mobile its own size step: a smaller type scale, tighter section padding, smaller gaps. Keep tap targets at their minimum size (see Tap Targets), but shrink everything else with intent at the breakpoint.

Fixed Pixel Type

• Tell: font sizes in fixed px that never change between desktop and mobile, so headings and body text stay oversized on a phone.
• Why: type that does not respond to the viewport is type sized for one screen. R-03 demands the mobile layout hold up, and R-06 requires typography that improves readability. A headline that spans the whole phone width or a body size tuned for a wide line breaks both.
• Fix: use fluid type (clamp()) so sizes scale with the viewport, or set a smaller type step at the breakpoint. Verify the result at a narrow width (R-35), not just in the desktop preview.

100vh Sections

• Tell: hero and section heights set to 100vh, so a section fills the whole phone screen and pushes everything else below the fold.
• Why: a full-viewport section designed for a desktop monitor becomes a giant slab on a phone, and 100vh includes the browser chrome, so it overflows the visible area on mobile browsers. It dominates the layout instead of introducing it (R-03).
• Fix: let sections size to their content (auto), or use the dynamic viewport unit (dvh) where a real full-height section is intended. Nothing below the fold should be an accident of viewport units.

Huge Empty Padding

• Tell: desktop-scale section padding (96px, 128px) kept on mobile, creating tall empty gaps between sections on a phone.
• Why: padding tuned for a large canvas turns into wasted vertical space on a small one. The page scrolls through emptiness, and the rhythm R-05 calls for becomes a void between every section.
• Fix: reduce section padding at the breakpoint to a mobile register (roughly half or less), and check that the page scrolls at a natural density instead of through deserts of space.

Grids & Stacking

Columns That Don't Collapse

• Tell: a multi-column grid keeps its side-by-side columns on mobile, so the columns shrink, the text wraps awkwardly, and elements collide.
• Why: a grid is a promise about how much width is available. When the viewport narrows and the grid does not re-stack, every column gets a sliver, text becomes unreadable, and cards overlap (R-03). This is the collision failure: desktop's side-by-side becomes mobile's pileup.
• Fix: collapse the grid to a single reflowing column at the breakpoint. Side-by-side becomes stacked, and each item gets the full width again. Re-verify at a narrow width (R-35).

Fixed-Width Grid

• Tell: grid-template-columns set in fixed px, or grid areas that cannot reflow, so the grid stays rigid when the viewport shrinks.
• Why: a fixed-px track does not care about the viewport; it keeps its width and forces overflow or collision. The layout was built for one canvas and cannot change shape (R-03).
• Fix: size tracks with minmax() or auto-fit and auto-fill so columns shrink and wrap with the content, and define grid areas that collapse at the breakpoint. The grid should be fluid by default, rigid only where a fixed size is deliberate.

Forced 12-Column

• Tell: a 12-column grid forced onto mobile content that needs one or two columns, so spans look arbitrary and the math fights the layout.
• Why: a 12-column system is for a wide canvas with many columns of content. Forcing it on a phone makes every element a fraction of an invisible grid the user never sees, and the content gets fitted to the grid instead of the grid to the content (R-03).
• Fix: let columns follow the content. On mobile the content usually wants one column, or two at most; the 12-column span only makes sense where the layout genuinely has that many things side by side.

Overflow

Horizontal Scroll Leak

• Tell: the page scrolls sideways because some element is wider than the viewport: a table, a code block, an image, a long unbroken string.
• Why: horizontal scrolling is a broken promise on mobile. The user cannot see where the page ends, and the layout visibly spills off the screen (R-03). It is the most common overflow slop because the offender is off-screen in the desktop preview and goes unnoticed until a phone opens it.
• Fix: find the element wider than the viewport (a table that needs a reflow layout or a scroll container, a code block that wraps, images with max-width: 100%), then contain or reflow it. Verify the whole page has zero horizontal scroll at the narrowest target (R-35).