В 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 — если они решают понятную задачу, а не просто красиво смотрятся в демо.

Все публикации автора