Safari 27, 이미지가 늦게 떠도 읽던 문단을 지킨다

Safari 27에서는 위쪽 이미지가 떠도 읽던 문단을 지킨다

글을 읽는 도중 위쪽 이미지가 나타나면서 문단이 아래로 밀리는 현상은 Safari 27의 스크롤 앵커링이 줄여 주는 문제다. 브라우저가 기준이 되는 요소의 위치 변화를 보고 스크롤을 보정한다. WebKit의 정식 출시 설명에 따르면 사이트가 별도로 켜는 코드를 넣을 필요는 없다.

이미지뿐 아니라 위쪽에 뒤늦게 삽입되는 광고나 댓글도 같은 상황을 만든다. 페이지 전체 높이는 달라져도 현재 읽는 내용은 화면의 같은 자리에 남도록 조정하는 것이다. 이는 Safari 27에 추가된 동작이므로 구버전까지 같은 결과를 전제로 만들 수는 없다.

위치를 유지한다는 것은 scrollTop 숫자를 고정한다는 뜻이 아니다

스크롤 앵커링이 지키는 것은 화면에서 보이는 내용의 위치다. MDN의 동작 설명처럼, 이를 위해 문서 안의 스크롤 위치 수치는 오히려 바뀔 수 있다.

가령 읽던 문단 위에 새 콘텐츠가 생기면 문서의 시작점에서 그 문단까지 거리가 늘어난다. scrollTop 숫자를 그대로 두면 다른 부분이 보이게 된다. 따라서 “스크롤 값이 변했다”는 관찰만으로 위치 유지가 실패했다고 판단하면 안 된다. 삽입 전후에 같은 문단이 화면의 어디에 있는지도 봐야 한다.

CSS 스크롤 앵커링 명세는 자동 보정 역시 scroll 이벤트를 만든다고 규정한다. 모든 scroll 이벤트를 사용자가 움직인 결과로 처리하거나, 이벤트마다 위치를 다시 쓰는 코드는 이 동작과 함께 점검할 대상이다.

자동 보정을 끌 때는 직접 제어하는 목록에만 적용한다

overflow-anchor의 기본값은 auto다. 직접 스크롤 위치를 관리하는 특정 목록에서 자동 보정을 제외하려면 그 영역에 none을 적용할 수 있다. 다음은 앱이 위치를 맡는 목록에만 적용하는 CSS 예다.

.manually-managed-list {
  overflow-anchor: none;
}

페이지 전체에 먼저 none을 붙일 이유는 없다. 단순한 본문은 기본 보정의 이점을 유지하고, 앱이 별도 규칙으로 이동시키는 영역만 나눠 보는 편이 원인을 찾기 쉽다. MDN도 scroll 이벤트 처리 코드가 자동 보정을 제대로 다루지 못할 가능성을 디버깅 항목으로 제시한다.

같은 스크롤 상자에서는 조상에 none을 준 뒤 자식에 auto를 적어도 그 자식만 다시 앵커 후보로 만들 수 없다. 다만 명세는 별도의 중첩 스크롤 컨테이너를 구분한다. 안쪽 컨테이너는 자신의 스크롤 상자에 대해 독립적으로 앵커링할 수 있으므로, CSS를 고칠 때 실제로 스크롤되는 요소부터 찾아야 한다.

계속 밀린다면 삽입·보정·스타일 변화를 나눠 본다

스크롤 앵커링은 모든 이동을 막는 고정 장치가 아니다. 앵커와 스크롤 요소 사이 경로에서 높이·위치·transform 등의 계산값이 바뀌는 경우에는 보정이 억제될 수 있다. 스타일 값이 바뀌는 시점과 콘텐츠가 들어오는 시점을 함께 봐야 한다.

문제를 좁힐 때는 같은 문단을 기준으로 위쪽 콘텐츠를 삽입해 보고, 기존 수동 보정 코드를 켰을 때와 껐을 때를 비교한다. none 적용 범위와 브라우저 버전도 함께 기록한다. 이 비교는 자동 보정과 앱 코드 중 어느 부분부터 조사할지 정하는 작업이다.

채팅·가상 목록은 관성 스크롤까지 별도로 살펴야 한다. TanStack Virtual의 사용자 제보에는 Safari 18.4에서 목록 맨 위를 넘겨 당겼다가 화면이 튕겨 돌아오는 동안 이전 항목이 추가되면, 보던 위치가 달라지는 사례가 있다. Safari 27의 기능 추가만으로 이런 개별 라이브러리 문제가 모두 해결됐다고 볼 수는 없다.

일반 본문은 기본 동작을 유지하고, 직접 위치를 제어하는 목록은 실제 삽입 흐름으로 검증한다. 구버전 지원이 남아 있다면 최신 Safari에서 잘 작동한다는 이유만으로 보정 코드를 일괄 삭제하지 않는다.