HTML внутри canvas: Chrome 157 объединяет DOM и графическую сцену
В анонсе 26 октября Google объявила стабильный выпуск HTML-in-Canvas. Интерфейс можно рисовать в 2D, WebGL и WebGPU, сохраняя связь с семантикой HTML; совместимость и геометрия требуют отдельного внимания.
Изображение перестаёт быть единственным представлением интерфейса
Обычный canvas предоставляет программе пиксели, но сам по себе не сообщает браузеру, где находится поле ввода и какой текст нарисован на сцене. Поэтому графические редакторы и сложные визуализации вынуждены отдельно поддерживать доступность и взаимодействие. HTML-in-Canvas использует реальные элементы DOM как источник изображения. Браузер продолжает знать о тексте и контролах, а графический движок получает возможность включить их в композицию. Анонс касается Chrome 157: наличие API в одном браузере не означает всеобщей поддержки.
Семантика и расположение — разные части задачи
Техническое руководство описывает canvas с content="drawable" и дочерние элементы drawable. Важно, что доступность связана не только с наличием текста в DOM. Элементы должны иметь корректную семантику, подписи и сведения о расположении. Если элемент ещё не нарисован и геометрия не задана, он может присутствовать в дереве доступности без координат. Это позволяет экранному диктору прочитать содержимое, но визуальные вспомогательные инструменты должны учитывать, что на экране соответствующего изображения пока нет. В техническом примере figure сохраняет связь изображения и подписи, хотя два drawable-элемента рисуются в разных координатах. Это демонстрирует разделение семантической структуры и графической композиции. Для 2D размер bitmap canvas и координаты DOM не являются одним и тем же понятием, особенно при масштабировании устройства. В 3D добавляются преобразования модели, камеры и поверхности. API предоставляет связь с геометрией элемента, а конкретный движок определяет, как включить полученное изображение в свой материал и сцену.
Двумерная и трёхмерная сцены обновляются по-разному
В 2D drawElementImage по умолчанию синхронизирует геометрию. Для WebGL и WebGPU положение зависит от преобразований сцены, поэтому разработчик передаёт transform через updateElementGeometry. Ошибка в таком соответствии способна создать кнопку, которая выглядит в одном месте, а реагирует в другом. Это особенно заметно при масштабировании, вращении и прокрутке. Современная документация отличается от раннего origin trial: примеры старого API с layoutsubtree нельзя механически переносить в рабочий выпуск. В самом старом материале теперь есть предупреждение об изменившейся реализации.
Поддержка библиотек не заменяет проверку среды
Google перечисляет интеграции Three.js, PlayCanvas, Babylon.js и PixiJS, оговаривая независимый статус сторонних проектов. У разных движков свои обёртки, версии и степень экспериментальности. Проверка поддержки должна происходить до запуска сцены. Если API отсутствует, возможны обычный HTML-интерфейс или другой резервный способ отображения. Снимок DOM в картинку не равнозначен живому HTML: он не сохраняет автоматически все возможности ввода, поиска и вспомогательных технологий. Поэтому выбор запасного пути зависит от задачи интерфейса.
Текст остаётся частью документа
Выделение, копирование, поиск и перевод зависят от наличия реальных DOM-элементов, а не от распознавания нарисованных букв. Внутри сцены сохраняются стандартные текстовые узлы и контролы формы; графический вывод использует их изображение. Обновление геометрии связывает эти представления, чтобы координаты взаимодействия соответствовали видимому результату. HTML при этом сохраняет структуру: например, figure и figcaption могут оставаться семантически связанными, хотя изображение и подпись рисуются отдельно. Для вспомогательных технологий неотрисованный элемент может оставаться доступным без визуальных координат. Это различие прямо описано в техническом руководстве и объясняет, почему скрытый резервный DOM и нарисованный текст не являются взаимозаменяемыми.
