브라우저 확장 툴팁 구현: Shadow DOM vs iframe, 제작 노트
Source: Dev.to
위키피디아식 컨텍스트를 새 탭을 열지 않고도 하이라이트 한 번으로 인라인에 유지하기 위해 rabbitholes를 만들었습니다. 어려운 부분은 API 통합이 아니라, 임의의 호스트 페이지에 툴팁을 삽입했을 때 툴팁이 어색해 보이거나 페이지를 깨뜨리지 않는 것이었습니다.
두 가지 옵션: iframe 오버레이 또는 shadow DOM.
iframe는 설계상 격리되어 있어 맞는 선택처럼 보이지만, 그 격리는 양쪽 모두에 영향을 미칩니다. 호스트 페이지가 로드한 폰트는 iframe 안에서는 명시적으로 다시 로드하지 않으면 사용할 수 없으며, 다시 로드하면 다운로드 중에 스타일이 적용되지 않은 순간이 나타납니다. 읽기용 서체가 경험의 일부인 장문 기사에서는 툴팁이 시스템 산스에서 올바른 폰트로 중간에 전환되는 것이 시각적으로 거슬려 한 번의 테스트만에 이 방식을 포기했습니다.
Shadow DOM은 폰트 문제 없이 캡슐화를 제공합니다. shadow root는 호스트 문서와 동일한 브라우저 폰트 로딩 라이프사이클에 참여하므로, 페이지가 이미 로드한 폰트를 shadow 트리 안에서도 즉시 사용할 수 있습니다. 툴팁은 첫 번째 페인팅에서 올바른 서체로 렌더링됩니다.
위치 지정도 더 깔끔합니다. shadow host 요소는 일반 DOM에 존재하므로 position: absolute와 Range.getBoundingClientRect()에서 얻은 좌표를 사용해 커서 기준으로 배치할 수 있습니다—좌표 공간 변환이 필요 없습니다. iframe을 사용했다면 두 개의 별도 뷰포트 프레임을 다루어야 했을 것입니다.
제가 받아들인 트레이드오프: shadow DOM은 완전한 격리가 아닙니다. 일부 브라우저에서는 넓은 선택자를 사용하는 호스트 페이지가 스타일을 뚫고 들어올 수 있습니다. 이를 완화하기 위해 shadow 컨테이너에 브라우저 기본값을 상속받지 않도록 모든 CSS 속성을 명시적으로 선언했습니다—다소 장황하지만, 제가 테스트한 사이트(Wikipedia, Substack, NYT, arXiv)에서는 신뢰할 수 있었습니다.
rabbitholes의 다른 모든 구성 요소도 최소 발자국 제약을 적용해 만들었습니다: Manifest V3, 중간 서버 없음, API 키는 chrome.storage.sync에 저장, 분석 도구 전혀 사용하지 않음. 요청은 브라우저에서 직접 api.anthropic.com으로 전송됩니다.