Chrome, DOM과 Canvas의 딜레마 끝내다: HTML-in-Canvas API 오리진 트라이얼 시작
The HTML-in-Canvas API origin trial
Chrome 148~150에서 오리진 트라이얼로 공개된 HTML-in-Canvas API는 DOM의 접근성, 텍스트 선택, 폼 컨트롤, find-in-page 같은 기능을 그대로 유지하면서 DOM 콘텐츠를 2D canvas나 WebGL/WebGPU 텍스처에 직접 그릴 수 있게 한다. Three.js와 PlayCanvas가 이미 실험적 지원을 추가했고, 3D 책이나 굴절 UI 같은 데모도 등장했다. 다만 cross-origin iframe 콘텐츠에는 동작하지 않고, 스크롤과 애니메이션이 JavaScript에 종속되는 한계도 있다.
이 API를 사용하면 DOM 콘텐츠를 2D canvas나 WebGL/WebGPU 텍스처에 직접 그리면서도 UI는 상호작용 가능하고 접근성 있으며 좋아하는 브라우저 기능과 연결된 상태로 유지할 수 있습니다.
HN 토론
32- andsoitis
1년 전 html-in-canvas에 관한 논의: https://news.ycombinator.com/item?id=44772177
(댓글 116개)
- artpar
캔버스 네이티브 워크스페이스 전체를 구현하고 싶어서, HTML만으로 구현한 방식과 "가짜 캔버스" 접근으로 시작했는데, 패널 수가 적당한 수준(~50개)만 되어도 반응성이 꽤 많이 떨어졌어요. 그래서 "진짜 캔버스"로 새로 구현하고 패널/상호작용을 만들어냈습니다.
성능 면에서는 이 접근이 훨씬 잘 맞았습니다(1000개 이상의 패널/중첩 패널을 60fps 이상으로 쉽게 처리 가능). 하지만 각 패널 구현의 복잡도가 매우 높아집니다. 예를 들어 마크다운 렌더링 js 라이브러리나 서드파티 UI 컴포넌트를 그냥 쓸 수가 없어요. 그리고 조금만 변경해도 성능이 크게 떨어지는 일이 자주 생깁니다.
현재 text/markdown/image/audio/video와 pdf 패널이 있습니다(파일을 드래그 앤 드롭할 수 있어요).
html-in-canvas API로 다시 한번 도전해볼까 하는데, 혜택이나 사용처가 보이지 않으면 이 API가 유지되지 않을까 봐 걱정입니다.
- mrec
음, DOM 하이퍼링크를 캔버스에 그린 다음 픽셀 데이터에서 방문 여부 색상을 긁어가는 식의 잠재적 프라이버시 유출을 어떻게 막는지는 바로는 잘 모르겠네요.
아니면 제가 시대에 뒤처진 걸지도요. 오랫동안 진지한 웹 개발을 안 했거든요.
- hollowturtle
세상에, skia처럼 접근성과 텍스트 레이아웃 API를 따로 두고 DOM을 완전히 버릴 수 있다면 얼마나 좋을까.
- chrismorgan
(2026년 5월.)
그 시기의 관련 댓글 모음: https://news.ycombinator.com/item?id=48201222