designpaca/research/youtube/SUMMARY.md

노마드코더 「이게 진짜 HTML이라고?」 분석

• URL: https://www.youtube.com/watch?v=8ucoskmA1yg
• 채널: 노마드 코더 Nomad Coders
• 주제: Chrome 신규 HTML in Canvas API
• 원문 자막: transcript-ko.txt / 압축본 transcript-ko-compact.txt / 영문 nomad-html.en.srt

목차 (영상 챕터)

시간	내용
0:00–2:29	이게 진짜 HTML이라고? (데모 쇼케이스)
2:30–2:50	왜 지금까지 불가능했을까?
2:51–3:51	HTML in Canvas는 어떻게 작동할까?
3:52–6:02	직접 만들어보자 (반사 버튼 구현)
6:03–6:37	아직 당장 쓸 수는 없다

핵심 주장

"웹사이트와 비디오 게임의 경계를 허무는 새로운 API" "2D 페이지라기보다는 비디오 게임이나 예술 설치 작품처럼 느껴지는 웹사이트"

기존의 딜레마: 캔버스는 다른 HTML 요소를 전혀 알지 못한다. 캔버스 안에 버튼을 그리려면 사각형+글자를 직접 그리고, 클릭 좌표를 히트테스트하고, 호버 시 다시 그려야 한다. 그렇게 해도 접근성·키보드 지원·CSS 스타일링이 전부 없는 "버튼 그림"일 뿐이다. → 픽셀(canvas)이냐 HTML이냐 둘 중 하나만 골라야 했다.

해결: 같은 요소가 DOM(상호작용)과 캔버스(픽셀)에 동시에 존재한다. 셰이더가 그 픽셀을 붙잡아 비틀고, 왜곡하고, 혼합하고, 3D 형태에 매핑한다. 접근성과 폼 동작은 DOM이 그대로 유지한다.

API 구조

⚠️ 영상이 쓰는 API 이름은 전부 구 명칭이다. 조사 결과 확정된 현재 이름으로 아래를 정정했다. 근거와 전체 스펙: research/canvas/01-api-spec.md

1. <canvas layoutsubtree> 속성 → 캔버스가 직계 자식 요소를 인식 (철자는 전부 소문자, IDL은 layoutSubtree)
2. 그리고 싶은 HTML을 캔버스 자식으로 넣는다 (평범한 HTML/CSS 그대로)
3. ctx.drawElementImage(el, x, y) — 요소 + 좌표를 주면 실시간 복사본을 그 자리에 그린다
   • 이름 변천: drawElement → drawHTMLElement → drawHTML → drawElementImage(2025-09-11 확정). 영상은 첫 이름을 쓴다
4. 반환값이 핵심: 그려진 위치를 나타내는 DOMMatrix 를 돌려준다 → 그것을 요소의 style.transform 에 넣으면 실제 DOM 요소가 그려진 위치로 이동한다 → 클릭이 맞아떨어진다
   • 구 API의 setHitTestRegions() 는 2025-11-08 폐기되고 이 방식으로 대체됐다
   • 매 프레임 반영하지 않으면 클릭이 전부 어긋난다 — 이 API의 필수 계약이다
5. WebGL gl.texElementImage2D(...) / WebGPU device.queue.copyElementImageToTexture(...)
   • 2026-04~06에 두 시그니처 모두 바뀌어 Chrome 공식 블로그 예제조차 구버전이다. WICG 공식 데모도 try/catch 로 신·구 양쪽을 지원한다
6. 캔버스 내부 HTML이 바뀔 때(포커스·호버 등) paint 이벤트 발생 → 듣고 다시 그린다 (중첩 시 역트리 순서)

보안 모델 — "read-back-allowed rendering"

캔버스 픽셀은 읽을 수 있으므로, 저자가 원래 볼 수 없던 것은 아예 그리지 않는다: cross-origin 콘텐츠, 시스템 색상, 맞춤법 마커, :visited(히스토리 스니핑 차단), 자동완성 미리보기, 서브픽셀 AA, IME 팝업. same-origin iframe은 그려진다.

데모 구현 흐름 (반사 버튼, JS 약 20줄)

매 프레임(rAF):
  캔버스 clear
  ctx.save()
  translate(아래로) + 상하 반전 + globalAlpha 0.3
  drawElement(button)        ← 흐릿한 뒤집힌 반사
  ctx.restore()
  drawElement(button)        ← 원본
  반환된 변환값 → button.style.transform 에 적용 (히트박스 정렬)
  requestAnimationFrame(render)

클릭 이벤트에서 클릭 좌표로 ripple() 호출 — 픽셀을 샘플링해 위치를 조정하는 건 기존 캔버스 연산이라 새로울 게 없다. 요점은 HTML이 일단 캔버스에 올라가면 무엇이든 할 수 있다는 것.

영상에 나온 데모들

• 3D 씬의 천 조각 위에 그려진 포트폴리오 — 찌르면 천이 실제처럼 반응하고 폼이 천에 녹아든다
• HTML range 입력 → 젤리 슬라이더
• 폼 제출 시 셰이더로 HTML이 왜곡되는 효과
• 라이트/다크 모드 전환 시 페이지가 타들어가는 애니메이션
• 웹에서 구현한 Apple Liquid Glass

한계

영상이 밝힌 것:

• Chrome Canary + 플래그 뒤에 있다 (chrome://flags/#canvas-draw-element)
• 아직 제안(proposal) 단계, 전부 초안
• API 시그니처와 기본 형태조차 바뀔 수 있다 — 실제로 조사 기간에만 4번 바뀌었다
• → "당장 내일 프로덕션에 투입할 것은 아니지만, 오늘 실험을 시작할 가치는 충분하다"

조사로 보강한 것 (영상이 말하지 않은 것):

• Origin Trial이 진행 중이다 (M148~M150, M154까지 연장 승인). OT 토큰을 등록하면 Chrome Stable 사용자에게도 동작한다 — 영상은 이 부분을 "플래그뿐"으로 축소해서 말한다. 다만 2026-10 초 만료 예정
• Firefox·Safari 모두 "No signal"(입장 미표명), WHATWG PR #11588은 2025-08 개설 후 여전히 미머지
• 실전 제약 둘: ① cross-origin iframe 미지원 ② 캔버스 안 콘텐츠는 컴포지터 스레드 스크롤/애니메이션을 잃고 JS에 묶인다 — Chrome은 캔버스 안에 스크롤 영역을 넣지 말고 캔버스 전체를 스크롤시키라고 명시
• three.js는 이미 정식 지원한다: THREE.HTMLTexture(element) + InteractionManager, r184 포함(2026-04-10 머지), WebGL/WebGPU 렌더러 양쪽
• 폴백이 존재한다: three-html-render 폴리필(MIT)이 동일 API 표면을 foreignObject로 제공하고 네이티브가 있으면 자동으로 fast path를 탄다. three.js 공식 예제가 이걸 쓴다

designpaca 에의 함의

1. 이 API는 스킬의 "실험 레이어"에 넣는다 — 기본 경로가 되어선 안 된다. 프로덕션 기본값은 SVG 필터 + three.js. 단 조사 결과 위상이 조금 올라갔다: three.js HTMLTexture(r184 정식) + three-html-render 폴리필 조합이면 점진적 향상으로 오늘 쓸 수 있다. "쓰지 마라"가 아니라 **"폴백을 먼저 만들고, 그 위에 얹어라"**로 규칙을 정한다
2. 폴백 필수: 미지원 브라우저에서 같은 인상을 주는 대안 경로를 항상 같이 설계한다 (foreignObject 폴리필, SVG displacement, backdrop-filter, CSS3DRenderer 등 — 비교표는 research/canvas/04-fallbacks.md)
3. "DOM은 살려두고 픽셀만 왜곡한다"는 원칙은 이 API 없이도 유효하다 — 접근성을 포기하지 않고 화려함을 얻는 designpaca의 기본 철학으로 삼는다
4. 영상의 문제의식("웹이 다시 재밌어질 수 있다", "플래시 시절처럼")이 곧 스킬의 방향성 — 안전하고 지루한 템플릿의 반대편