I can't run your page, so everything below is a hypothesis. Each one comes with a check that will confirm or rule it out. Start at 375px, then test 320, 414, 768, 1024 and 1280, and 200% zoom at desktop width.
First, find the widest element. Run the overflow-finder snippet from the skill in the console at 375px. Skip anything inside the table wrapper. The URL card or the table will probably be at the top of the list.
1. Card with a long URL in a flex row (sideways scroll at 375px)
- Cause: a flex item has an automatic
min-width, so it can't shrink below its content. An unbroken URL has no break opportunity, so the card keeps the URL's full width and pushes the row past the viewport. - Fix:
If the row should stack on phones, add.card { min-width: 0; } /* let the flex item shrink */ .card .url { overflow-wrap: anywhere; } /* allow breaks in the URL */flex-wrap: wrapor switch toflex-direction: columnbelow your breakpoint. - Verify: at 375 and 320, the card's
getBoundingClientRect().rightshould be no more than the viewport width, and the URL should wrap inside the card. Test with the longest real URL you have. Removemin-width: 0once to confirm the overflow comes back. That proves this was the cause.
2. Table with 8 columns
- Cause: tables don't shrink below their content width, so 8 columns exceed 375px.
- Fix: scroll the table inside its own container, not the page.
<div class="table-scroll"><table>…</table></div>
If the table is read often on phones, restack each row into a card below about 600px. Don't hide columns. If the wrapper sits inside a flex row, it may also need.table-scroll { overflow-x: auto; max-width: 100%; }min-width: 0. - Verify: the page has no horizontal scrollbar at 375, and only the table area scrolls sideways. Check that every column can be reached and that the wrapper can be scrolled with the keyboard. Add
tabindex="0"to the wrapper if it can't. At 1280 the table should look unchanged.
3. Hero with height: 100vh too tall on phones
- Cause:
100vhis the largest viewport height, measured with the browser bars retracted. While the address bar is showing, the hero is taller than the visible area. - Fix:
Use.hero { min-height: 100vh; /* fallback */ min-height: 100svh; /* or 100dvh if you want it to follow the bars */ }min-heightinstead ofheightso tall content isn't clipped.svhalways fits with the bars showing.dvhresizes as the bars move, which can cause jank. Also check for100vwanywhere on the hero. It can cause sideways overflow of its own. - Verify: this needs a real phone, because emulation doesn't reproduce the browser bars reliably. Load the page with the address bar visible and confirm the hero fits without cutting off its content. Then scroll and confirm nothing jumps.
4. Sticky sidebar doesn't stick on desktop
- Cause: the parent has
overflow-x: hidden. Anyoverflowvalue other thanvisiblemakes that element the sticky element's scroll container. Because it never scrolls vertically, the sidebar has nothing to stick against. Less likely, but worth checking: the sidebar has notopvalue, or its parent isn't taller than the sidebar. - Fix: remove
overflow-x: hiddenfrom that parent, or move it somewhere that isn't an ancestor of the sidebar. If it was there to hide the overflow from bug 1 or 2, fixing those removes the need for it. If you must clip,overflow-x: clipdoesn't create a scroll container, so sticky keeps working..sidebar { position: sticky; top: 1rem; align-self: flex-start; }align-self: flex-startmatters if the parent is a flex or grid container. A stretched sidebar is as tall as its parent and has no room to stick. - Verify: at 1280, scroll the page and confirm the sidebar stays pinned. In DevTools, walk up the ancestor chain and check that none has an
overflowother thanvisible. Then check 375 again, since removing the clip could expose any overflow that remains.
Order of work
Fix 1 and 2 first and re-run the finder. Then fix 4, which removes the clip that was hiding the problem. Without both, you'd be hiding the overflow while breaking sticky. Do 3 last, on a real device.
I haven't tested any of this. If you can paste the computed styles for the card, the table wrapper and the sidebar's ancestors (not your code), I can narrow the causes down further.
Real run in an isolated folder with only this skill installed. Only the Skill and Read tools were enabled, so no command was run and no file was written. The scenario is fictional and the model had no access to the code. Everything in the answer is a hypothesis with a check to confirm it.
Was es macht
Eine Methode zum Debuggen von Layouts, die nur bei manchen Bildschirmbreiten brechen. Sie besteht darauf, den Fehler bei einer benannten Breite zu reproduzieren und mit einem Konsolen-Snippet, das Elemente breiter als der Viewport auflistet, das genaue überlaufende Element zu finden, bevor irgendein CSS geändert wird. Eine Symptom-Ursache-Tabelle deckt die üblichen Verdächtigen ab: feste Breiten und 100vw (das die Scrollbar-Breite einschließt), Flex- und Grid-Elemente mit automatischer Mindestgröße (min-width: 0), lange unterbrechungsfreie Zeichenketten, Bilder, Tabellen, position: sticky, das durch overflow eines Vorfahren oder ein zu niedriges Elternelement blockiert wird, in einem Stacking-Kontext gefangenes z-index, abgeschnittene Dropdowns, 100vh auf Smartphones (dvh und svh), Safe Areas (viewport-fit=cover und env()), Grids, Viewport-Meta und Layout-Verschiebungen.
Außerdem
Breakpoints dort wählen, wo der Inhalt bricht, Mobile-first-Regeln, relative Einheiten, Container Queries, Touch-Ziele, 200 % Textvergrößerung und Reflow bei 320 Pixel sowie eine Checkliste der zu testenden Breiten und Bedingungen. Sie warnt davor, Überlauf auf html oder body zu verstecken und das als Lösung auszugeben.
Geeignet für
Layoutfehler auf Mobilgeräten, „bricht nur bei einer Breite“ und Seiten, die seitlich scrollen.
Geringes Risiko: Reine Anweisungen ohne Skripte, ohne Netzwerkzugriff und ohne Dateischreiben. Enthalten ist ein kurzes Snippet zum Einfügen in die Browserkonsole; es liest nur Elementpositionen und ändert nichts an der Seite. Es sieht Ihre Seite nicht, seine Antworten sind daher Hypothesen mit einer Prüfung zur Bestätigung, und es nennt, was nicht getestet wurde; Emulatoren bilden Browserleisten und Safe Areas nicht zuverlässig nach, testen Sie in diesen Fällen auf einem echten Gerät. Neuere CSS-Funktionen (Container Queries, `dvh`) brauchen eine Unterstützungsprüfung für Ihre Browser. Originalwerk von AIBars (MIT). Einmal mit einer erfundenen Seite ausprobiert.