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.
Qué hace
Un método para depurar layouts que se rompen en determinados anchos de pantalla. Insiste en reproducir el error a un ancho concreto y, después, en localizar el elemento exacto que desborda mediante un fragmento para la consola que enumera los elementos más anchos que el viewport, antes de cambiar cualquier CSS. Una tabla de síntoma a causa cubre los sospechosos habituales: anchos fijos y 100vw (que incluye la barra de desplazamiento), elementos flex y grid con tamaño mínimo automático (min-width: 0), cadenas largas sin espacios, imágenes, tablas, position: sticky bloqueado por el overflow de un ancestro o por un padre con altura insuficiente, z-index atrapado en un contexto de apilamiento, desplegables recortados, 100vh en móviles (dvh y svh), áreas seguras (viewport-fit=cover y env()), grids, meta viewport y layout shift.
También cubre
Elegir breakpoints donde el contenido se rompe, reglas mobile-first, unidades relativas, container queries, áreas táctiles, redimensionado del texto al 200 % y reflujo a 320 píxeles, además de una lista de comprobación de anchos y condiciones que probar. Advierte contra ocultar el overflow en html o body como solución.
Ideal para
Errores de layout en móviles, «solo se rompe en un ancho», y páginas con scroll horizontal.
Riesgo bajo: solo instrucciones sin scripts, sin acceso a la red y sin escritura de archivos. Incluye un fragmento breve para pegar en la consola del navegador; solo lee la posición de los elementos y no cambia nada en la página. No puede ver tu página, así que sus respuestas son hipótesis con una comprobación para confirmar cada una, e indica qué no probó; los emuladores no reproducen de forma fiable las barras del navegador ni las áreas seguras, así que prueba en un dispositivo real cuando intervengan. Las funciones CSS más recientes (container queries, `dvh`) requieren comprobar la compatibilidad con tus navegadores. Skill original de AIBars (MIT). Probada una vez en una página inventada.