Što je HTML‑in‑Canvas i zašto je važan
HTML‑in‑Canvas je nova web platformska značajka koju je Google najavio na I/O 2026. API omogućuje da se HTML elementi renderiraju izravno u canvas, uključujući WebGL i WebGPU kontekste, uz zadržavanje pristupačnosti, fokusa i pune interaktivnosti. Drugim riječima, klasični DOM elementi više ne moraju živjeti u odvojenom sloju iznad 3D scene, već mogu postati dio istog renderinga.
Za autore 3D web aplikacija to je velika promjena. Do sada je tipičan WebGL UI bio kombinacija barem dva svijeta: 3D scene u canvasu i HTML/CSS sučelja iznad nje. Sinkronizacija tih slojeva donosila je probleme s koordinatama, responzivnim dizajnom, performansama i pristupačnosti. HTML‑in‑Canvas pokušava taj jaz zatvoriti na razini same platforme.
Kako se WebGL UI radio do sada
Klasični pristup WebGL sučeljima oslanja se na dva glavna obrasca:
- DOM overlay: HTML i CSS sloj iznad canvasa za izbornike, HUD, debug panele i tooltipove.
- Custom 2D rendering: tekst i UI elementi iscrtani kao teksture, spriteovi ili kroz vlastite shader‑bazirane sustave.
DOM overlay je jednostavan za implementaciju, ali uvodi tehničke kompromise. Koordinate kursora moraju se ručno prevoditi između DOM‑a i WebGL koordinatnog sustava. Responsivnost znači održavanje dva odvojena layout svijeta. Događaji poput focusa, tipkovničkih prečaca i pointera moraju se pažljivo prosljeđivati kako bi se izbjegle „mrtve zone” ili dvostruki klikovi.
S druge strane, potpuno custom 2D UI unutar WebGL‑a daje potpunu kontrolu nad izgledom, ali po cijenu kompleksnosti. Tekst se često rješava preko tekstualnih atlasa ili SDF fontova. Svaka promjena jezika, fonta ili veličine teksta traži regeneriranje tekstura i ručno podešavanje layouta. Pristupačnost praktički ne postoji jer čitači ekrana ne vide što se događa u shaderima.
Što konkretno donosi HTML‑in‑Canvas
HTML‑in‑Canvas nudi treći put: omogućuje da se standardni HTML i CSS layout renderiraju direktno u isti canvas gdje živi WebGL ili WebGPU scena. Ključna razlika je u tome što ti elementi i dalje ostaju dio DOM‑a, sa svim semantičkim informacijama, ali su vizualno ucrtani u canvas.
To znači da se tipični HUD‑ovi, overlay izbornici i tooltipovi više ne moraju raditi kao zaseban DOM sloj. Umjesto toga, isti elementi mogu se pozicionirati unutar istog koordinatnog sustava kao i 3D sadržaj. Browser i dalje upravlja fokusom, tipkovničkim prečacima i čitačima ekrana, ali izlaz ide kroz istu render pipeline kao i WebGL.
U praksi se otvaraju dva glavna scenarija:
- 2D overlay u istom canvasu: HTML UI se „lijepi” uz rub ekrana, ali se renderira u istom canvasu kao i 3D scena. Zadržava se klasičan HUD, ali bez dodatnog DOM overlaya.
- UI u 3D prostoru: HTML elementi se mogu projicirati u 3D, primjerice kao paneli unutar virtualne galerije, kokpita ili kontrolne sobe. Transformacije se mogu vezati uz 3D objekte, a klikovi i fokus i dalje funkcioniraju kao u običnom HTML‑u.
Primjeri upotrebe u Three.js, Babylon.js i PlayCanvas projektima
Za popularne WebGL enginee poput Three.js, Babylon.js i PlayCanvas, nova mogućnost mijenja način razmišljanja o UI‑u.
HUD i overlay bez tekstualnih atlasa
Umjesto custom tekstualnih atlasa i SDF fontova za svaku labelu, developeri mogu definirati UI kao običan HTML:
- gumbi za promjenu kamere ili načina prikaza
- statusni panel s FPS‑om, latencijom ili debug informacijama
- tooltipovi koji ovise o objektu ispod kursora
Layout se rješava CSS‑om (flex, grid, media queriji), a engine zatim te elemente projicira u canvas. Lokalizacija se pojednostavljuje jer se tekstualni sadržaj mijenja kao u bilo kojoj web aplikaciji, bez pečenja teksta u teksture.
3D UI paneli unutar scene
U Three.js projektu, na primjer, možete imati 3D model kontrolne sobe, a UI panele na zidovima definirati kao HTML komponente. Babylon.js može HTML‑in‑Canvas koristiti za složene in‑game izbornike koji prate poziciju kamere ili određenog objekta. PlayCanvas, često korišten u igrama i interaktivnim oglasima, može integrirati HTML bannere ili forme direktno u 3D scenu bez klasičnog overlaya.
U svim tim slučajevima, engine upravlja transformacijama i projekcijom, dok preglednik brine o tipografiji, layoutu, fokus menadžmentu i pristupačnosti.
Performanse: gdje se dobiva, a gdje gubi
HTML‑in‑Canvas ne čini WebGL besplatnim. I dalje postoji cijena layouta, stiliranja i rasterizacije HTML sadržaja. No mijenja se balans posla između CPU‑a i GPU‑a, te između custom koda i optimiziranog browser enginea.
Layout engine preuzima dio posla
Umjesto da developeri pišu vlastite layout sustave u JavaScriptu ili shaderima, mogu se osloniti na postojeći CSS engine preglednika. To je osobito korisno za složene UI‑eve s puno elemenata, responzivnim gridovima i dinamičkim sadržajem. Browser već ima visoko optimizirane algoritme za layout, caching stilova i invalidaciju.
Međutim, broj elemenata i učestalost promjena layouta po frameu i dalje su kritični. Ako se pri svakom frameu mijenja veliki dio DOM‑a, trošak layouta i repainta može postati usko grlo, neovisno o tome što se izlaz crta u canvas.
Interakcija s WebGL pipelineom
U tipičnom renderingu, WebGL scena se crta u jednom ili više rendering passova, a UI se zatim composita na vrh. S HTML‑in‑Canvasom, browser mora uskladiti vlastiti rendering pass za HTML s WebGL sadržajem. To otvara nova pitanja oko frame pacinga i sinkronizacije:
- kako uskladiti animirani UI s animiranom 3D scenom
- kada trigirati reflow i repaint u odnosu na WebGL draw callove
- kako izbjeći nepotrebne invalidacije kada se mijenja samo 3D sadržaj ili samo HTML sloj
Dobra vijest je da se postojeći WebGL projekti ne moraju odmah potpuno prebaciti na HTML‑in‑Canvas. API se može uvoditi postupno: prvo za HUD i overlay, zatim za pojedine 3D panele, a tek kasnije za dublju integraciju cijelog UI‑a u 3D svijet.
Pristupačnost i fokus: najveći dobitnici
Jedan od najvećih problema dosadašnjih WebGL UI‑eva bila je pristupačnost. Kada je UI iscrtavan u shaderima, čitači ekrana nisu imali nikakav uvid u sadržaj. Tipkovnična navigacija bila je ručno implementirana, često ograničena i krhka.
S HTML‑in‑Canvasom, UI elementi ostaju standardni DOM čvorovi. To znači:
- čitači ekrana mogu čitati sadržaj i slijediti fokus
- tipkovnični prečaci i tab‑navigacija rade kroz postojeće mehanizme preglednika
- atributi poput
aria-*i semantičke oznake (button,nav,form) i dalje funkcioniraju
Za 3D aplikacije koje ciljaju širu publiku, uključujući korisnike s poteškoćama vida ili motoričkim poteškoćama, ovo je ključna promjena. Umjesto custom pristupačnosti u okviru enginea, veći dio posla rješava sama platforma.
Responzivni dizajn u 3D svijetu
Responzivnost je još jedno područje gdje HTML‑in‑Canvas mijenja pravila igre. Do sada su developeri morali ručno prilagođavati WebGL UI različitim rezolucijama i omjerima stranica, često kroz vlastite media querije u JavaScriptu ili kroz više setova tekstura.
Sada se isti CSS media queriji koji se koriste u standardnim web aplikacijama mogu primijeniti na UI unutar WebGL canvasa. Primjerice:
- HUD se prebacuje iz horizontalnog layouta u vertikalni na užim ekranima
- font‑size i padding se automatski prilagođavaju DPI‑ju i veličini prozora
- određeni paneli se skrivaju ili zamjenjuju kompaktnijim verzijama na mobilnim uređajima
U kombinaciji s 3D transformacijama, to otvara mogućnost UI‑a koji se ne samo skalira, već i prostorno prilagođava. Na većim ekranima panel može „izaći” u 3D prostor, dok se na manjim vraća u 2D overlay način rada, sve kroz iste HTML/CSS definicije.
Dugoročne posljedice za WebGL i WebGPU
HTML‑in‑Canvas je više od još jedne API opcije. Signalizira smjer u kojem se WebGL i WebGPU scene sve više tretiraju kao ravnopravni građani DOM‑a, a ne kao izolirane „crne kutije” u kojima browser vidi samo piksele.
Dugoročno, to može značiti:
- dublju integraciju 3D sadržaja s ostalim web tehnologijama (formulari, autentikacija, analitika)
- manju potrebu za custom rješenjima pristupačnosti i responzivnog dizajna unutar enginea
- novu generaciju 3D web aplikacija u kojima UI više ne izgleda kao kompromis između performansi i pristupačnosti
Za WebGPU, koji već cilja na moderni, niskorazinski grafički pipeline, HTML‑in‑Canvas može postati ključni sloj za izgradnju bogatog UI‑a bez ponavljanja istog posla u shaderima. WebGPU će brinuti o sirovoj grafici i compute zadacima, dok će HTML‑in‑Canvas preuzeti prikaz kontrola, panela i interakcijskih elemenata.
Što developeri trebaju pratiti u sljedećoj fazi
Iako je HTML‑in‑Canvas najavljen na I/O 2026, put do široke primjene ovisit će o nekoliko faktora:
- podrška u više preglednika, ne samo u Chromeu
- standardizacija API‑ja kroz W3C i WHATWG procese
- najbolje prakse koje će se iskristalizirati kroz ranu adopciju u Three.js, Babylon.js i PlayCanvas zajednicama
Za sada ima smisla razmišljati o arhitekturi projekata tako da UI bude što više deklarativan i odvojen od renderinga. Projekti koji već koriste komponente (npr. React, Vue, Svelte) za definiciju UI‑a bit će u prednosti kada HTML‑in‑Canvas postane stabilan, jer će moći relativno lako preusmjeriti izlaz komponenti u canvas umjesto u klasični DOM overlay.
Jedno je jasno: granica između „web aplikacije” i „3D aplikacije u pregledniku” nastavlja se brisati. HTML‑in‑Canvas je još jedan korak prema webu u kojem 3D, UI i pristupačnost dijele istu platformu, umjesto da žive u paralelnim svjetovima.
