Proposal: Investigate HTML-in-Canvas (CanvasDrawElement) support via Chromium/CEF flags

## Summary

This issue proposes exploring support for the experimental *HTML-in-Canvas* API (CanvasDrawElement) from the [Web Incubator Community Group](https://wicg.io/) in Kurogane via Chromium/CEF feature flags.

Rather than committing to adoption, the goal is to evaluate feasibility, performance impact and alignment with Kurogane’s rendering-focused use cases.

## Background

The HTML-in-Canvas proposal (incubated in WICG) introduces APIs that allow rendering DOM elements directly into `` contexts, including:

* `drawElementImage()`
* `layoutsubtree` attribute
* `canvas.onpaint` event
* `captureElementImage()` for OffscreenCanvas workflows

The feature is currently:

* Implemented behind a Chromium flag (`canvas-draw-element`)
* Available in experimental builds (e.g. Chromium Canary)
* Not standardized and subject to change

Reference:
[https://github.com/WICG/html-in-canvas](https://github.com/WICG/html-in-canvas)

## Why is this relevant?

Kurogane is explicitly designed for:

* High-frequency rendering workloads (WebGL, Canvas, WASM)
* Direct control over the Chromium rendering pipeline
* Cross-platform GPU consistency (especially on Linux)

HTML-in-Canvas aligns strongly with these goals by enabling:

* Rendering complex, styled DOM content into GPU-backed canvas contexts
* More consistent accessibility vs traditional canvas text rendering
* New hybrid rendering patterns (DOM -> GPU surface -> 2D/3D composition)
* Potential use in:

* In-app UI layers
* Game-like interfaces
* Visualization overlays
* Media export pipelines

## Proposal

Investigate whether Kurogane can expose this feature **optionally** via Chromium/CEF flags.

### Exploration areas

1. **CEF / Chromium compatibility**

* Identify the Chromium version where `canvas-draw-element` exists
* Map to corresponding CEF version(s)
* Verify whether the feature is compiled into CEF builds

2. **Flag support**

* Test enabling via:

```
chrome://flags/#canvas-draw-element
```

Read more over https://html-in-canvas.dev/docs/browser-support/

3. **Runtime behavior**

* Validate basic demos from the WICG repo
* Test:

* 2D canvas usage
* OffscreenCanvas + worker flows
* WebGL/WebGPU interop (if available)

4. **Performance characteristics**

* Compare against:

* Manual canvas text/layout rendering
* DOM overlays
* Measure:

* Frame consistency
* GPU utilization
* Latency

5. **Platform consistency**

* Especially Linux vs Windows behavior
* Any compositor / vsync interactions

## Non-goals

* Shipping this as a stable or default feature
* Building abstractions around the API (yet)
* Guaranteeing long-term support

This is strictly exploratory.

## Risks

* API is unstable
* Potential mismatch between Chromium and CEF exposure
* Behavior may change or be removed upstream
* Additional maintenance burden if relied upon too early

## Potential outcome

If viable, Kurogane could:

* Expose experimental rendering capabilities ahead of mainstream frameworks
* Enable advanced GPU/DOM hybrid rendering patterns
* Further differentiate from WebView-based approaches and higher-level runtimes

## Next steps

* [x] Identify minimum Chromium + CEF version
* [x] Attempt flag enablement in a dev build
* [x] Run WICG demos inside Kurogane
* [ ] Document findings (working / broken / missing)

The issue is an exploration proposal. Start by checking the linked WICG repository and the html-in-canvas.dev documentation for browser support. Identify the Chromium and CEF versions that include the 'canvas-draw-element' flag. Run the WICG demos within a Kurogane dev build to see if the feature works. Document any findings on compatibility, performance, and platform consistency.

Written by the indexing model from the issue text.