CSS에서 선택자를 더 구체적으로 작성했는데도 버튼 색상이 바뀌지 않거나, 스타일시트 아래쪽에 추가한 규칙이 적용되지 않는 일이 있습니다. 특히 @layer를 도입한 뒤 이런 현상이 생겼다면 CSS 코드의 작성 순서보다 캐스케이드 레이어의 우선순위를 먼저 살펴볼 필요가 있습니다. @layer는 스타일 충돌을 체계적으로 관리하기 위한 CSS 기능입니다. 그러나 일반 CSS 선언과!important 선언에서 레이어 우선순위가 서로 반대로 적용되기 때문에 기존 CSS의 선택자 규칙만 생각하면 결과를 잘못 판단하기 쉽습니다. 핵심은 세 가지입니다. 일반 선언은 나중에 생성된 레이어가 우선합니다. 레이어 밖에 있는 일반 선언은 레이어 내부의 일반 선언보다 우선합니다. 하지만!important가 붙으면 레이어 순서..

웹사이트에 웹폰트를 설정했는데 글자가 여전히 기본 글꼴로 보인다면 CSS 파일부터 수정하기 쉽습니다. 하지만 글꼴 파일을 찾지 못한 경우와 파일은 정상적으로 다운로드했지만 실제 텍스트에 적용되지 않은 경우는 해결 방법이 다릅니다. 크롬 개발자 도구에서 실제로 사용된 글꼴과 네트워크 요청을 구분하면 불필요하게 CSS를 수정하거나 CORS 설정을 변경하지 않고도 문제의 범위를 좁힐 수 있습니다. 특히 404 오류, CORS 차단, 글꼴 이름 불일치, 로컬 설치 글꼴의 영향은 서로 다른 증거로 판단해야 합니다. CSS에 적힌 글꼴과 화면에 사용된 글꼴은 다를 수 있습니다 font-family에 원하는 글꼴 이름이 표시된다고 해서 브라우저가 반드시 그 글꼴 파일로 문자를 그렸다는 뜻은 아닙니다. 해당 파일을 불..

윈도우에서 다크모드를 켰는데 웹사이트는 여전히 흰색이거나, 화면 배경은 어두워졌는데 입력창만 밝게 남아 있는 경우가 있습니다. 반대로 사이트에서 다크모드를 구현하지 않았는데 Chrome에서는 색상이 자동으로 바뀌기도 합니다. 이 문제는 모두 같은 설정으로 해결되지 않습니다. 사용자의 테마 선호를 감지하는 CSS, 웹페이지 요소의 색상을 지정하는 CSS, 브라우저가 직접 그리는 기본 UI의 색상 처리가 서로 다르기 때문입니다. 이번 글에서는 Chrome 개발자 도구로 문제가 발생하는 위치를 확인하고, prefers-color-scheme과 color-scheme을 어떤 상황에서 수정해야 하는지 구분합니다. 실제 사이트를 수정하기 전에 사용할 수 있는 독립적인 HTML 테스트 코드도 제공합니다.화면 증상에 ..

웹사이트에서 팝업이나 모달 창을 만들었는데 상단 메뉴, 고정 헤더, 사이드바 뒤로 숨어버리는 경우가 있습니다. CSS의 z-index를 100에서 9999로, 다시 999999로 높여도 달라지지 않는다면 숫자보다 요소가 속한 겹침 구조를 살펴봐야 합니다. 핵심은 두 가지입니다. 일반 HTML 요소는 부모의 stacking context(쌓임 맥락)에 영향을 받지만, 브라우저의 top layer에 올라간 모달은 일반 문서의 z-index 계층과 다른 규칙으로 표시됩니다. 문제를 해결하려면 현재 팝업이 어느 쪽에 해당하는지부터 구분해야 합니다. z-index가 999999인데도 팝업이 뒤에 표시되는 이유 z-index는 요소가 겹쳐지는 순서를 조절하는 CSS 속성입니다. 그러나 모든 요소의 z-index를 ..

PC에서는 정상인 웹사이트가 스마트폰에서는 하단 버튼이 잘리거나 화면 아래에 불필요한 스크롤이 생길 때가 있습니다. 특히 CSS에서 height: 100vh를 사용하는 로그인 화면, 첫 화면, 전체 화면 메뉴에서 나타나기 쉬운 문제입니다. 하지만 모든 하단 잘림 현상을 100dvh로 바꾸는 것만으로 해결할 수는 없습니다. 브라우저 주소창이 차지하는 공간인지, 콘텐츠가 화면보다 긴 것인지, 입력창을 눌렀을 때 나타나는 가상 키보드 때문인지에 따라 수정할 부분이 다릅니다. 이번 글에서는 세 상황을 구별하고, CSS 수정 예제와 Chrome 개발자 도구의 검증 절차를 함께 살펴봅니다. 마지막에는 직접 파일로 저장해 비교할 수 있는 최소 재현 예제도 제공합니다. 하단이 언제 잘리는지에 따라 수정할 코드가 달라집..

웹사이트의 메뉴나 사이드바에 position: sticky를 적용했는데, 페이지를 내려도 화면에 고정되지 않는 경우가 있습니다. CSS에 sticky를 선언했는데도 요소가 그대로 사라지거나, 잠깐 고정되다가 예상보다 일찍 움직이기도 합니다. 이때 top 값만 계속 조정하면 해결되지 않을 수 있습니다. sticky는 브라우저 화면에 무조건 붙는 기능이 아니라, 상위 요소의 스크롤 설정과 자신이 속한 영역의 경계에 따라 움직이기 때문입니다. 문제를 좁히려면 세 가지를 구분해야 합니다. 고정을 시작할 위치가 지정됐는지, 어떤 요소를 기준으로 스크롤하는지, 그리고 고정된 상태로 이동할 공간이 남아 있는지입니다. 페이지에 붙일까, 스크롤 박스 안에 붙일까? 수정할 CSS를 결정하기 전에 고정하려는 위치부터 생각해..

웹페이지를 아래로 스크롤하면 요소가 나타나거나 상단 진행 표시줄이 늘어나도록 CSS 애니메이션을 설정했는데, 아무 반응이 없을 때가 있습니다. 반대로 스크롤하기도 전에 애니메이션이 끝나거나, 특정 브라우저에서만 콘텐츠가 보이지 않는 경우도 있습니다. 이때 animation-timeline 속성 하나만 바꾸는 것으로는 해결되지 않을 수 있습니다. 애니메이션의 진행 기준, CSS 선언 순서, 실제 스크롤 영역, 브라우저 지원 여부가 서로 연결되어 있기 때문입니다. 이번 글에서는 CSS의 scroll()과 view()가 각각 어떤 움직임을 추적하는지 구분하고, 오류가 발생하는 조건을 재현용 코드와 함께 살펴봅니다. 브라우저가 기능을 지원하지 않을 때에도 중요한 콘텐츠가 정상적으로 표시되도록 대체 스타일을 구성..

웹사이트에서 Tab 키를 눌렀는데 버튼이나 링크 주변에 아무 표시도 나타나지 않는다면 두 가지를 구분해야 합니다. 키보드 포커스가 실제로 이동하지 않는 문제일 수도 있고, 포커스는 정상적으로 이동하지만 CSS 때문에 테두리만 보이지 않는 문제일 수도 있습니다. 두 상황은 해결 방법이 다릅니다. 무작정 CSS를 추가하기보다 Chrome 개발자 도구로 포커스 이동 여부를 확인하면 수정해야 할 위치를 훨씬 정확하게 찾을 수 있습니다. 이 글에서는 CSS의 outline과:focus-visible을 이용한 표시 복구, document.activeElement를 이용한 포커스 추적, tabindex 순서 확인까지 실제 적용 가능한 순서로 설명합니다. 포커스가 없는 것과 보이지 않는 것은 다릅니다 포커스는 현재 키..

웹사이트 상단 메뉴나 사이드바를 스크롤할 때 고정하려고 position: sticky를 적용했는데, 일반 요소처럼 위로 사라지는 경우가 있습니다. CSS 문법은 맞는데도 작동하지 않는다면 sticky 요소 자체보다 부모 요소의 overflow, 실제 스크롤 영역, 이동할 수 있는 공간을 확인해야 합니다. 특히 페이지 전체를 스크롤하는 구조와 특정 박스 내부를 스크롤하는 구조는 해결 방법이 다릅니다. 무조건 overflow: hidden을 삭제하거나 position: fixed로 바꾸면 다른 레이아웃 문제가 생길 수 있습니다. 이번 글에서는 크롬 개발자 도구를 사용해 어느 요소가 문제인지 찾고, HTML과 CSS 수정 전후를 비교하면서 적절한 해결 방법을 선택하는 과정을 설명합니다. sticky가 고정되는..

웹사이트를 열었을 때 글자는 빠르게 나타나는데 대표 이미지가 한참 뒤에 표시되거나, 아래로 스크롤할 때 사진이 뒤늦게 나타나는 경우가 있습니다. 이미지를 불러오는 도중 본문이나 버튼이 아래로 밀리는 현상까지 발생하기도 합니다. 이런 문제를 해결하려고 모든 이미지에 loading="lazy"를 추가하면 오히려 첫 화면의 로딩 속도가 느려질 수 있습니다. 이미지마다 화면에 나타나는 위치와 중요도가 다르기 때문입니다. 이번 글에서는 HTML 이미지 속성 세 가지인 loading, fetchpriority, width·height를 중심으로 이미지 표시 속도와 화면 밀림을 구분해 개선하는 방법을 살펴봅니다. 일반 웹사이트뿐 아니라 티스토리처럼 스킨과 본문 이미지가 함께 사용되는 블로그에도 적용할 수 있는 기준입..