본문으로 건너뛰기
J
피드

HTML을 캔버스 안에 넣는 데모 모음이 등장함

frontend 약 3분
tags
#canvas#html#threejs#playcanvas
vote
0
댓글
북마크

구글 크롬 랩스 저장소에 HTML-in-Canvas 관련 데모와 프레임워크 지원 목록이 정리됐다. Duck Hunt 스타일 폼, 흔들리는 버튼, 셰이더 기반 페이지 전환, 천처럼 매달린 폼 같은 실험적 예제가 포함돼 있고 Three.js와 PlayCanvas 쪽 샘플도 연결돼 있다.

  • 1

    HTML-in-Canvas 생태계 데모를 모아둔 큐레이션 자료

  • 2

    Wes Bos 등 서드파티 개발자가 만든 실험 데모 포함

  • 3

    Three.js와 PlayCanvas가 HTML 텍스처 관련 샘플을 제공

  • 크롬 랩스 쪽 저장소에 HTML-in-Canvas 데모 모음이 올라옴

    • 말 그대로 HTML UI를 캔버스나 3D 그래픽 환경 안에 넣어보는 실험들을 한곳에 모은 큐레이션임
    • 구글이 직접 만든 데모만 있는 건 아니고, 생태계 개발자들이 만든 서드파티 데모 링크도 같이 정리돼 있음

  • 데모 목록이 꽤 장난감 같으면서도 프론트엔드 관점에선 흥미로움

    • Wes Bos의 Duck Hunt 데모는 폼 자체를 슈팅 게임처럼 다루는 예제로 소개됨
    • Wobble Buttons는 물결 효과가 들어간 인터랙티브 버튼 데모임
    • Compiz Web은 셰이더 기반 웹 페이지 전환을 보여주는 실험이고, HTML cloth는 게임 안에서 천에 매달린 폼을 커스터마이즈하는 식의 데모임

  • 프레임워크 쪽 지원도 같이 언급됨

    • Three.js는 WebGL과 WebGPU 기반 3D 그래픽 라이브러리이고, HTMLTexture 샘플이 연결돼 있음
    • PlayCanvas도 html-texture 샘플을 제공하는 프레임워크로 정리돼 있음

  • 아직은 “당장 프로덕션에 넣자”보다 “이런 UI도 가능해지는구나”에 가까움

    • 특히 게임 UI, 3D 에디터, 인터랙티브 제품 데모처럼 DOM과 캔버스 경계가 자주 부딪히는 영역에서 참고할 만함
    • 저장소에서도 서드파티 데모는 구글이 만들거나 유지보수하는 게 아니라고 선을 긋고 있어서, 안정성보다는 아이디어 탐색용으로 보는 게 맞음

아직 제품 기능 발표라기보다는 실험실 느낌이 강하지만, 웹 UI와 3D 캔버스 경계가 점점 흐려지는 흐름을 보기엔 꽤 괜찮은 자료다. 게임 UI, 인터랙티브 랜딩, 3D 에디터 쪽 하는 프론트엔드 개발자라면 한 번 훑어볼 만함.

prev

이전 기사 (P)

next

다음 기사 (N)

댓글

댓글

댓글을 불러오는 중...

관련 기사

frontend

요즘 픽셀 폰트가 그냥 복고 감성이 아닌 이유

1990년대 기기 화면 느낌을 현대 폰트 시스템으로 재해석한 픽셀 폰트 몇 가지를 소개한 글이다. 핵심은 예쁜 복고풍 글자 모양만이 아니라, 실제 제품에서 쓸 수 있게 기준선, 자간, 메타데이터, 세로 메트릭까지 챙기는지가 중요하다는 점이다.

frontend

HTML의 `<dl>`이 생각보다 쓸모 많은 이유

이 글은 HTML의 description list, 즉 `<dl>`, `<dt>`, `<dd>`가 단순 용어 사전용 태그가 아니라 이름-값 쌍 UI를 표현하는 꽤 강력한 시맨틱 도구라고 설명한다. 숙소 편의시설, 요금 내역, 기술 용어 설명, 게임 능력치표처럼 흔한 패턴을 중첩 `<div>` 대신 의미 있는 HTML로 만들 수 있다는 얘기다.

frontend

싱글 페이지 앱이 웹을 너무 비싸게 만들었다는 불평

이 글은 싱글 페이지 앱(SPA)이 사용자 경험을 좋게 만든다는 명분 아래 웹의 초기 로딩 비용, 도구 복잡도, 개발 진입 장벽을 키웠다고 비판한다. 페이스북 로그인 페이지의 CSS 3.8MB, 레딧 몇 개 클릭 후 33MB 다운로드 같은 숫자를 들며, 지금의 프론트엔드 생태계가 사람보다 대기업의 요구에 맞춰져 있다고 주장한다.

frontend

네이티브로 끝까지 가려다 텍스트에서 막힌 macOS 개발자의 고백

20년 가까이 macOS와 iOS 네이티브 개발을 해온 작성자가 SwiftUI, AppKit, TextKit 2로 마크다운 채팅 UI를 만들다 결국 WebKit과 Electron 쪽이 훨씬 낫다는 결론에 도달한 글이다. 문제는 성능 하나가 아니라 선택, 스트리밍, 스크롤, 접근성, 텍스트 상호작용 같은 ‘사용자가 당연히 기대하는 기본기’가 네이티브 조합에서 계속 깨진다는 점이다.

frontend

Tailwind를 떠나며 다시 CSS 구조를 배운 이야기

Julia Evans가 몇 년간 써온 Tailwind를 걷어내고, 의미 있는 HTML과 순수 CSS로 사이트를 다시 정리한 경험을 공유했다. 핵심은 Tailwind를 단순히 버린 게 아니라, Tailwind가 줬던 제약과 시스템을 CSS 코드베이스 안에서 직접 재구성했다는 점이다.