Why HTML-in-Canvas is a game-changer for modern web apps

The first time you see real HTML rendered inside a canvas, it feels like magic—until you realize the hidden challenges of scaling it into a full-fledged application.

That’s the moment when a promising browser primitive transforms from a novelty into a complex lifecycle management problem. Developers must grapple with resizing logic, cleanup routines, pixel density mismatches, and framework-specific integration quirks. This complexity is exactly why tools like Prism exist.

The promise of HTML-in-Canvas

The WICG HTML-in-Canvas proposal introduces a groundbreaking capability: rendering authentic DOM elements directly within a canvas element. Unlike libraries that generate screenshots or SVG-based solutions, this approach leverages the browser’s native rendering engine to paint real HTML, CSS, and fonts into a canvas frame.

Consider the following minimal example:

<canvas id="canvas" layoutsubtree>
  <div id="panel" style="width: 400px; height: 200px">
    <h2>Real HTML</h2>
    <p>Real CSS. Real fonts. Real layout.</p>
  </div>
</canvas>

The JavaScript to render this inside the canvas is equally straightforward:

const canvas = document.getElementById("canvas");
const panel = document.getElementById("panel");
const ctx = canvas.getContext("2d");

if (!ctx) throw new Error("2d context unavailable");

canvas.onpaint = () => {
  ctx.drawElementImage(panel, 0, 0);
};

canvas.requestPaint();

Key components include:

• The layoutsubtree attribute, which enables layout calculations for canvas children.
• The drawElementImage() method, which paints a DOM element into the canvas.
• The onpaint event, triggered when the browser detects a need to repaint the canvas subtree.

For isolated use cases, this API feels almost too good to be true.

The hidden complexity of real-world applications

When translating this primitive into a production-grade application, developers encounter a cascade of mundane but critical challenges:

• Tracking which DOM elements should behave as canvas surfaces.
• Managing dynamic resizing and layout updates.
• Coordinating paint requests with the browser’s rendering pipeline.
• Handling cleanup during component unmounts or runtime destruction.
• Ensuring export operations wait for fonts and layout to stabilize.
• Resolving discrepancies between CSS pixels and canvas backing-store pixels.

A basic React component attempting to handle these concerns might look like this:

useEffect(() => {
  const canvas = canvasRef.current;
  const scene = sceneRef.current;
  const ctx = canvas?.getContext("2d");

  if (!canvas || !ctx || !scene) return;

  canvas.onpaint = () => {
    ctx.reset();
    ctx.drawElementImage(scene, 0, 0);
  };

  const resizeObserver = new ResizeObserver(([entry]) => {
    canvas.width = Math.round(entry.contentRect.width);
    canvas.height = Math.round(entry.contentRect.height);
    canvas.requestPaint();
  });

  resizeObserver.observe(canvas);
  canvas.requestPaint();

  return () => {
    resizeObserver.disconnect();
    canvas.onpaint = null;
  };
}, []);

While functional, this code quickly becomes a maintenance burden as the application scales. Adding features like multiple surfaces, export capabilities, pointer interactions, or framework integrations exacerbates the complexity.

Prism: a solution for managing DOM surfaces in canvas

Prism is a lightweight runtime designed to simplify the integration of HTML-in-Canvas into production applications. It doesn’t replace your rendering logic; instead, it encapsulates the lifecycle management of DOM surfaces within canvas applications.

With Prism, your application retains control over scene composition, animation loops, state management, and interaction handling. Prism takes ownership of surface registration, bounds adjustment, invalidation, paint readiness, coordinate transformations, and cleanup—freeing developers to focus on what matters.

Installing Prism is straightforward:

pnpm add @synthesisengineering/prism

Using it in your application is equally simple:

import { CanvasRuntime } from "@synthesisengineering/prism";

const runtime = new CanvasRuntime(canvas, {
  backend: "auto"
});

const surface = runtime.registerSurface(element, {
  bounds: {
    x: 0,
    y: 0,
    width: 320,
    height: 180
  }
});

runtime.onPaint(({ drawSurface }) => {
  drawSurface(surface);
});

runtime.start();

This separation of concerns allows developers to treat the DOM as a source of structured, styled content while leveraging the canvas for high-performance rendering and complex visualizations.

Reimagining data visualization with real DOM components

One compelling use case for Prism is data visualization. Take the example of Prism Atlantic, a tool that visualizes NOAA/NHC HURDAT2 Atlantic storm-track data from 2000 to 2025. The canvas handles the storm paths, while Prism manages the UI surfaces—titles, legends, tooltips, detail panels, and export buttons—all authored using standard HTML and CSS.

The code snippet below demonstrates how Prism integrates into such a visualization:

import { CanvasRuntime } from "@synthesisengineering/prism";

const runtime = new CanvasRuntime(canvas, {
  backend: "auto"
});

const tooltip = runtime.registerSurface(tooltipEl, {
  bounds: {
    x: 0,
    y: 0,
    width: 280,
    height: 120
  }
});

const legend = runtime.registerSurface(legendEl, {
  bounds: {
    x: 20,
    y: 20,
    width: 200,
    height: 400
  }
});

runtime.onPaint(({ ctx, drawSurface }) => {
  ctx.save();
  ctx.scale(runtime.pixelRatio, runtime.pixelRatio);
  drawStormTracks(ctx);
  ctx.restore();

  drawSurface(tooltip);
  drawSurface(legend);
});

runtime.start();

The export workflow is simplified significantly. Developers can wait for font loading and a single paint pass before exporting the canvas content:

await document.fonts.ready;
await runtime.waitForPaint();
// Proceed with canvas export

By bridging the gap between DOM and canvas, Prism enables developers to build richer, more maintainable applications without sacrificing performance or developer experience.