HTML-in-Canvas API 오리진 트라이얼

1. rudedogg12시간 전 HN

   웹에서 앱을 만들 때 문제는 바로 DOM입니다. 30년 넘은 레거시를 물려받지 않는 새로운 UI 렌더링 방식이나 기반을 추가하면 될 일인데, 브라우저는 왜 굳이 복잡한 걸 계속 얹는 건지 어이가 없네요. (그 30년 중 15년 가까이는 웹 앱이라는 것 자체가 없었다는 걸 떠올려 보세요.)

   진짜 애플리케이션을 만들려고 하면 DOM은 느리고 짜증 나는 쓰레기 더미예요.

2. aweiher10시간 전 HN

   DOM을 배우지 않는 자는 DOM을 다시 발명하게 될 운명이죠. 그것도 더 못나게요.

3. rudedogg6시간 전 HN

   90년대부터 이어진 GUI 툴킷들을 보세요. DOM과 웹 개발은 역사의 우연이었어요.

4. artpar18시간 전 HN

   저는 캔버스 네이티브 워크스페이스를 통째로 만들고 싶었습니다. 처음에는 HTML만 쓰는 "가짜 캔버스" 방식으로 구현했는데, 패널이 50개쯤만 되어도 반응 속도가 꽤 많이 떨어졌습니다. 그래서 "진짜 캔버스"로 새로 구현하고 패널과 상호작용을 하나씩 만들어 냈습니다.

   성능 면에서는 이 방식이 훨씬 나았습니다(패널과 중첩 패널 1000개 이상을 60fps 이상으로 거뜬히 처리합니다). 하지만 패널마다 구현 복잡도가 크게 올라갑니다. 예를 들어 마크다운 렌더링 JS 라이브러리나 서드파티 UI 컴포넌트는 그냥 가져다 쓸 수 없습니다. 게다가 뭔가 하나 바꿀 때마다 성능이 크게 떨어지는 일이 잦았습니다.

   https://canaster.in/

   지금은 텍스트, 마크다운, 이미지, 오디오, 비디오, PDF 패널이 있습니다(파일을 드래그 앤 드롭할 수 있습니다).

   html-in-canvas API로 다시 한번 구현해 봐야 할지 고민 중입니다. 다만 이 API가 효용이나 사용량이 안 보인다고 유지보수되지 않을까 걱정입니다.

5. spankalee8시간 전 HN

   최신 브라우저의 DOM은 사람들이 캔버스나 WebGPU로 직접 만드는 것과 똑같이 텍스처 합성(compositing) 기반이라서 아주 빠를 수 있습니다.

   캔버스 렌더링으로 버틸 수 있는 정도라면, 오히려 HTML을 쓰되 CSS containment와 절대 위치 지정으로 CSS와 레이아웃 비용을 크게 줄일 수 있습니다.

       #my-container > * {
         contain: strict;
         position: absolute;
       }
   

6. vollbrecht13시간 전 HN

   죄송해요, 제가 웹은 초보라서요. 혹시 이거 재귀적으로도 되나요? 예를 들면 html-in-canvas 안에 또 html-in-canvas를 넣을 수 있나요? :D

7. jmaw10시간 전 HN

   저는 웹 초보는 아니지만 똑같은 게 궁금하네요!

8. johnhenry9시간 전 HN

   됩니다.

   크롬에서 활성화하면 지금도 중첩은 동작하는데, 어째서인지 이벤트가 깨집니다.

   https://johnhenry.github.io/html-in-canvas-lab/

9. qingcharles10시간 전 HN

   도멤션(Domception)이네요.

10. andsoitis14시간 전 HN

    1년 전에 html-in-canvas를 두고 나온 토론입니다: https://news.ycombinator.com/item?id=44772177

    (댓글 116개)

11. chrismorgan19시간 전 HN

    (2026년 5월.)

    그 무렵에 나온 관련 댓글 모음입니다: https://news.ycombinator.com/item?id=48201222

12. boomskats16시간 전 HN

    거기에 "yo dawg" 짤(Xzibit 밈)이 하나쯤은 있을 줄 알았는데요.

13. hollowturtle17시간 전 HN

    아, 스키아(Skia)처럼 접근성과 텍스트 레이아웃 API를 따로 두고 DOM을 완전히 버릴 수 있으면 얼마나 좋을까요.

14. pmkary13시간 전 HN

    맞아요, 바로 그거예요.

15. mrec16시간 전 HN

    음, 이게 잠재적인 프라이버시 유출을 어떻게 막는지 얼른 이해가 안 되네요. 예를 들어 DOM 하이퍼링크를 캔버스에 그린 다음 픽셀 데이터에서 방문 여부에 따른 링크 색을 긁어내는 식으로요.

    아니면 제가 시대에 뒤처진 걸 수도 있겠네요. 진지한 웹 개발은 안 한 지 오래라서요.

16. rafram15시간 전 HN

    이 블로그 글은 제안서가 아니고, 제안서에는 당연히 그 내용이 들어 있어요.

    https://github.com/WICG/html-in-canvas/#read-back-allowed-rendering

17. unconed18시간 전 HN

    저는 얼마 전 이 글에서 HTML-in-Canvas에 대한 우려를 이야기한 적이 있습니다: https://acko.net/blog/html-is-dead-long-live-html/

    그 뒤로 이 API를 만든 두 사람을 실제로 만나 보았는데, 결론은 이렇습니다.

    • 겉보기 효과를 넘어서는 용도는 염두에 두고 있지 않았습니다.

    • 광고 회사 소속이라는 사실이 웹 기술을 만들고 구상하는 방식을 어떻게 좌우하는지 잘 이해하지 못합니다.

    • 응원이 아닌 반응에는 꽤 좋지 않게 반응합니다.

    곡면 요소는 어떻게 하느냐는 물음에 "평면 투영 변환으로 근사하면 된다"며 얼버무렸습니다. 성숙한 UI 내부 구조를 제대로 노출하려는 진지한 시도가 아니라, 삐걱거리는 괴물 같은 HTML5 웹 API 위에 또 하나 얹은 번지르르한 주전원(epicycle)일 뿐이라는 뜻입니다.

    "자동으로 동작한다"는 기능 목록은 사소한 시각 조정에서만 성립하는 가정에 기대고 있습니다. HTML-in-Canvas를 좀 더 기본적인 구성 요소로 쓰려는 순간 그중 상당수가 무너집니다.

    예를 들어 글자 한 줄을 렌더링한 다음 그걸 시각 효과의 마스크로 쓴다고 해 보죠. 이때 브라우저가 그 마스크에 텍스트 선택 하이라이트까지 그려 넣으면 글자를 읽을 수 없게 됩니다.

18. stymaar17시간 전 HN

    https://acko.net/blog/html-is-dead-long-live-html/

    블로그를 여러 번 읽어서 보자마자 알아봤는데, 블로그 헤더가 움직이고 상호작용되는 3D 데모라는 건 이번에 처음 알았네요. 멋져요!

19. TazeTSchnitzel13시간 전 HN

    새 API가 저는 헷갈립니다. 캔버스 위에 떠 있는 position:absolute 요소 몇 개를 얹는 것만으로는 안 되는 일이 뭔지 모르겠거든요. 텍스처로 렌더링되니 임의의 시각적 변환을 적용할 수는 있겠죠. 그런데 입력 처리는 사용자가 제어할 수 없다고 하니 도대체 무슨 소용입니까? 요소와 제대로 상호작용할 수도 없을 텐데요. 다른 것들을 제대로 가리는 것(occlusion)도 사실상 안 될 거라고 짐작합니다. 저로서는 말이 안 됩니다.

    비교하자면, Win32에는 버튼이나 텍스트 입력 필드 같은 것을 창(= DOM 요소와 비슷한 것)을 만들지 않고도 그릴 수 있는 API가 있습니다. 다만 실제 창 없이 입력 처리를 어디까지 할 수 있는지는 저도 잘 모르겠습니다. 어쨌든 브라우저는 웹 페이지를 대신해 네이티브 컨트롤을 우스꽝스러운 모양으로 비틀어 주는 데 성공했으니, 그쪽 API가 더 많은 가능성을 제공하는 것만은 분명합니다.

20. cantalopes10시간 전 HN

    그러니까 결국 한 바퀴 돌아서 매크로미디어 플래시로 돌아왔네요.

21. WillAdams10시간 전 HN

    사람들이 플래시로 만든 것 중에는 놀라운 게 꽤 있었습니다. 본격적인 2.5D CAM 도구도 그중 하나였죠.

    https://github.com/Jack000/PartKAM

22. dvh19시간 전 HN

    HTML 요소에 캔버스를 붙이는 쪽이 더 논리적이지 않을까요? 예를 들면 checkbox.getContext("2d").fillRect(...) 같은 식으로요.

23. aroman19시간 전 HN

    그런 쓸모가 있기야 하겠지만, 웹 게임 개발자인 저한테는 별로 도움이 안 됩니다. 핵심 기능은 입력과 텍스트 렌더링이거든요.

24. longor199616시간 전 HN

    아니면 캔버스 연산을 CSS에 (간접적으로든?) 직접 넣어도 좋겠고요!

    속성, 변수, calc() 값으로 채워지는, 채우기/선 페인트가 달린 경로의 목록을 선언해서 그릴 수 있다고 상상해 보세요... 꿈일 뿐이겠지만요.

25. rafram15시간 전 HN

    이미 있습니다. 실험적이고 Chromium 전용이긴 하지만요: https://developer.mozilla.org/en-US/docs/Web/API/CSS_Painting_API

26. longor199612시간 전 HN

    네, 그 API는 알고 있습니다. 그런데 제 생각엔(IMHO) 바로 그게 문제예요. 그건 API일 뿐 CSS 자체에 내장된 게 아니라서 JavaScript를 쓸 수밖에 없잖아요.

    제가 정말 원하는 건 뭔가 이런 형태입니다...

        @declare-some-shape MYSHAPE (ARGS) {
            /* tree of draw commands */
            /* can reference css animations, timelines, variables, etc. */
        }
    
    #my-div { content: draw-some-shape(MYSHAPE ARGS, TRANSFORM); }
    
    /* or, as some kind of pseudo-element: */
        #my-div::draw-some-shape(MYSHAPE) { ??? }
    

    그리고 네, 이게 보기 흉하다는 건 저도 잘 압니다. 그래도 문자열이나 DOM으로 SVG를 만들어 내거나 캔버스에 그리는 것보다는 이쪽이 낫겠어요.

27. rafram11시간 전 HN

    절대 안 됩니다. 정말로 원한다면 SVG를 데이터 URI로 이미 임베드할 수 있어요(두 배로 고생하고 싶다면 데이터 URI를 출력하는 SCSS로 구현해 볼 수도 있겠죠).

28. azangru18시간 전 HN

    캔버스에 그려진 3D 객체의 모양에 HTML이 맞춰져야 한다면 그렇게는 안 됩니다.

    말씀하신 건 CSS Painting API(CSS Houdini의 일부)입니다.

29. pmkary13시간 전 HN

    역대급 희소식이네요! 그 블로그 글이 나온 지 딱 1년 만에 구현됐다니 믿기지가 않아요... 이제 저는 이 API로 뭔가 만드는 데 인생의 상당 부분을 쓰게 될 것 같습니다...

30. jmull9시간 전 HN

    이건 중요한 사용 사례를 해결해 줍니다.

    캔버스로 앱을 만들기로 해 놓고 사실은 DOM이 필요했다는 걸 깨달았을 때, 처음의 실수를 바로잡는 대신 이제 더 깊이 파고들 수 있게 됐다는 거죠!

    ..."캔버스에 DOM을 가져오는 것의 장점"에 나열된 이점은 전부 DOM을 일반적으로 쓸 때의 이점이기도 하고요.

    사실 주로 캔버스 기반이면서도 DOM을 조금 곁들이는 앱이 필요한 경우가 있다는 건 이해합니다. 거슬리는 건 이 발표 방식이에요.

    ("interactive"를 쓰면 될 자리에 "intractable"을 써서 감점입니다. intractable은 영어 단어가 아니고 interactive는 영어 단어잖아요. 저는 순수주의자가 아니라서, 게임 프로그래밍처럼 그런 단어가 필요한 맥락에서 interactable을 명사로 쓰는 건 괜찮다고 봅니다. 그런 영어 단어가 없으니까요. 하지만 형용사로 쓰는 건 원어민이 아닐 때, 그리고 공식 발표가 아닐 때만 괜찮아 보입니다. 이러면 이 사람들이 자기들이 뭘 하는지 모른다는 인상만 굳어져요.)

Hacker News에서 보기 ↗