홈 / Skills / 웹·UI 디자인 / 반응형 레이아웃 디버깅 (Responsive Layout Debugging)
웹·UI 디자인

반응형 레이아웃 디버깅 (Responsive Layout Debugging)

AIBarsMITSkill 언어: 영어
라이선스 확인됨스크립트 없음낮은 위험
데모실행 기록 · claude-sonnet-5-5 · 2026년 10월
Using the responsive-layout-debugging skill, help me with a fictional page that scrolls sideways on phones around 375px. Facts: a flex row holds a card with a long unbroken URL; a table has 8 columns; the hero uses height:100vh and looks too tall on phones; a sticky sidebar does not stick on desktop and its parent has overflow-x:hidden. I cannot share the code. For each problem give the likely cause, the fix and how to verify it.
Skill: responsive-layout-debugging

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:
    .card { min-width: 0; }                 /* let the flex item shrink */
    .card .url { overflow-wrap: anywhere; } /* allow breaks in the URL */
    
    If the row should stack on phones, add flex-wrap: wrap or switch to flex-direction: column below your breakpoint.
  • Verify: at 375 and 320, the card's getBoundingClientRect().right should be no more than the viewport width, and the URL should wrap inside the card. Test with the longest real URL you have. Remove min-width: 0 once 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>
    
    .table-scroll { overflow-x: auto; max-width: 100%; }
    
    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 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: 100vh is 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:
    .hero {
      min-height: 100vh;   /* fallback */
      min-height: 100svh;  /* or 100dvh if you want it to follow the bars */
    }
    
    Use min-height instead of height so tall content isn't clipped. svh always fits with the bars showing. dvh resizes as the bars move, which can cause jank. Also check for 100vw anywhere 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. Any overflow value other than visible makes 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 no top value, or its parent isn't taller than the sidebar.
  • Fix: remove overflow-x: hidden from 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: clip doesn't create a scroll container, so sticky keeps working.
    .sidebar { position: sticky; top: 1rem; align-self: flex-start; }
    
    align-self: flex-start matters 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 overflow other than visible. 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.

하는 일

어떤 화면 너비에서만 깨지는 레이아웃을 디버깅하는 방법입니다. 이름이 있는 너비에서 먼저 재현하고, 뷰포트보다 넓은 요소를 나열하는 콘솔 코드로 넘치는 요소를 정확히 찾은 뒤에야 CSS를 바꾸라고 요구합니다. '증상-원인' 표가 흔한 원인을 다룹니다. 고정 너비와 100vw(스크롤바 너비 포함), 자동 최소 크기를 갖는 flex·grid 항목(min-width: 0), 길고 끊기지 않는 문자열, 이미지, 표, 조상의 overflow나 너무 낮은 부모 때문에 막히는 position: sticky, 쌓임 맥락에 갇힌 z-index, 잘리는 드롭다운, 휴대폰에서의 100vh(dvh와 svh), 안전 영역(viewport-fit=cover와 env()), grid, viewport meta, 레이아웃 이동입니다.

함께 다루는 것

내용이 깨지는 곳에서 브레이크포인트 정하기, 모바일 우선 작성법, 상대 단위, 컨테이너 쿼리, 터치 영역, 200% 텍스트 확대와 320픽셀 리플로, 테스트할 너비와 조건 체크리스트. html이나 body에서 넘침을 숨기는 것을 해결책으로 삼지 말라는 경고도 있습니다.

이런 때 좋습니다

모바일 레이아웃 버그, '특정 너비에서만 깨진다', 가로로 스크롤되는 페이지.

참고 및 위험

낮은 위험:스크립트가 없는 지침 패키지로, 네트워크 접속이나 파일 쓰기가 없습니다. 브라우저 콘솔에 붙여 넣는 짧은 코드가 있지만 요소 위치를 읽기만 하고 페이지를 바꾸지 않습니다. 사용자의 페이지를 볼 수 없으므로 답변은 확인 방법이 붙은 가설이며 테스트하지 않은 부분을 밝힙니다. 에뮬레이터는 브라우저 바와 안전 영역을 안정적으로 재현하지 못하므로 이와 관련되면 실제 기기로 확인하세요. 최신 CSS 기능(컨테이너 쿼리, `dvh`)은 대상 브라우저의 지원 여부를 확인해야 합니다. AIBars가 만든 오리지널(MIT). 가상의 페이지로 한 번 시험 실행했습니다.