У Chrome 157 з’явився HTML-in-Canvas для інтерактивного DOM усередині графічних сцен

У стабільній версії Chrome 157 з’явився API HTML-in-Canvas. Як пише Habr, після origin trial браузер дає змогу відображати інтерактивні HTML-елементи всередині canvas — у 2D, WebGL і WebGPU. Текст і форми залишаються частиною DOM, навіть коли стають частиною графічної сцени. Перед впровадженням розробникам потрібно перевірити підтримку API та підготувати запасний варіант інтерфейсу.

Навіщо HTML знадобився всередині canvas

Раніше команди, які створюють складні графічні інтерфейси, мали два основні підходи. Перший — малювати текст і елементи керування засобами canvas. Він давав контроль над зображенням, але браузер бачив результат як пікселі. Щоб скринридер міг прочитати такий інтерфейс, доводилося окремо створювати й підтримувати DOM-версію. Пошук на сторінці, виділення та копіювання тексту теж потребували додаткових рішень.

Другий підхід — розміщувати звичайні HTML-елементи поверх полотна. Тут можливості браузера зберігалися, зате положення елементів потрібно було постійно узгоджувати з графікою. Під час прокручування, масштабування або руху камери HTML і сцена могли розходитися. Крім того, шар поверх canvas складно розмістити за тривимірним об’єктом або включити у відбиття всередині сцени.

HTML-in-Canvas поєднує ці підходи: браузер відображає оголошений HTML-елемент у canvas, але продовжує працювати з ним як із DOM-вмістом. Текст отримує CSS-оформлення та звичайну браузерну розкладку. Його можна виділяти, копіювати, шукати на сторінці й перекладати; для елементів доступні контекстне меню та можливості форм, зокрема автозаповнення.

Вміст потрапляє до дерева доступності для скринридерів, а стилі елементів можна переглядати й змінювати в Chrome DevTools. У матеріалі також зазначено, що DOM усередині графічної сцени доступний пошуковим роботам для індексації. Текст, намальований безпосередньо через fillText(), не має цих властивостей без окремої реалізації. Раніше Chrome тестував HTML-in-Canvas API; тепер ідеться про випуск у стабільній версії браузера.

Як працює рендеринг і де потрібні перевірки

Спочатку для canvas задають атрибут content="drawable", а дочірній HTML-елемент позначають атрибутом drawable. Далі дії залежать від контексту. У 2D елемент малюють методом drawElementImage(), і браузер за замовчуванням сам синхронізує його положення із зображенням. У WebGL і WebGPU розробник обчислює трансформацію та передає її методу updateElementGeometry().

Це відрізняється від розміщення HTML поверх полотна: не потрібно на кожному кадрі задавати нові CSS-трансформації, щоб узгодити шари. Але геометрія сцени нікуди не зникає із завдань команди. Якщо елемент перебуває в 3D, його трансформацію все одно треба обчислити й передати браузеру, щоб DOM і графіка збігалися.

Результат можна зберегти як зображення через toDataURL() або toBlob(), а також отримати відеопотік через captureStream(). Серед можливих застосувань — робочі області редакторів, інтерактивні елементи в 3D-сценах і поєднання HTML-типографіки із шейдерними ефектами. Наприклад, текст може залишатися доступним для виділення, навіть якщо візуально він включений до графічної композиції.

Випуск стабільної версії Chrome не означає однакової підтримки в усіх браузерах. У матеріалі пропонують спершу перевірити наявність API. Якщо його немає, можна показати альтернативний HTML-інтерфейс, використати шари поверх canvas або сторонні бібліотеки. Для тих, хто вже працює з графічними бібліотеками, описано інтеграції з Three.js, PlayCanvas, Babylon.js і PixiJS. Підтримку в Three.js названо експериментальною.

Що це означає для проєктів

Для розробників редакторів і візуалізацій це можливість розміщувати текст та елементи керування в робочій області, не перетворюючи їх винятково на пікселі. Потреба підтримувати окремий невидимий DOM заради доступності може зменшитися. Водночас сама наявність HTML не робить інтерфейс зручним: структуру, поведінку форм і взаємодію з графікою, як і раніше, потрібно продумувати й перевіряти.

Для власника сайту чи маркетолога головне питання — чи потрібна проєкту сцена, де людина взаємодіє з текстом і формами як із частиною графіки. Якщо завдання можна вирішити звичайною сторінкою, переносити її в canvas немає сенсу. API корисніший там, де наявний підхід із шарами вже заважає: наприклад, елементи мають рухатися разом з об’єктами 3D-сцени або потрапляти до композиції, яку експортують.

Плануючи таку функцію, варто відразу передбачити сценарій без HTML-in-Canvas. Тоді доступ до важливого вмісту не залежатиме від підтримки нового API, а команда зможе обирати графічний підхід відповідно до завдання, а не до можливостей одного браузера.

Моя думка

Мені подобається, що тут новий браузерний API відповідає на зрозумілу проблему. Особливо хочеться спробувати його в інструментах, де текст раніше доводилося або малювати пікселями, або вручну утримувати поверх рухомого полотна. Можливість зберегти властивості DOM безпосередньо в сцені видається кориснішою за черговий графічний трюк.

Але я б не переносив звичайний інтерфейс у canvas лише тому, що тепер це можливо. Для сторінки без складної графіки це додасть роботи. І якщо рух не допомагає людині розв’язати завдання, він забирає її увагу — навіть коли браузер уміє швидко рендерити сцену.

Джерела

Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.

1. [Перевод] HTML-in-Canvas в Chrome 157: интерактивный DOM в 2D, WebGL и WebGPU habr.com

Про автора

Борислав Ганев

досвідчений frontend-розробник

Розробляю інтерфейси на TypeScript і поступово переношу вдалі командні практики у власні пет-проєкти. Особливо люблю нові браузерні API — якщо вони розв’язують зрозуміле завдання, а не просто гарно виглядають у демо.

Усі публікації автора