LogoSniCap
OverviewDemosAPIArchitecture

Strategy guide

HTML in Canvas

Understand the experimental WICG rendering path ReactSnap uses when the browser exposes layoutSubtree, requestPaint(), and drawElementImage().

Rendering StrategiesHTML in CanvasMenu

Experimental WICG path with capability-based routing.

On this page

ReactSnap can prefer the experimental html-in-canvas strategy when the browser exposes the current WICG canvas APIs. This route is fast to explain on a demo page because it renders the real DOM into canvas without serializing through SVG first.

html-in-canvas is still experimental. In Chrome-based manual testing you currently need to enable chrome://flags/#canvas-draw-element before expecting ReactSnap to resolve to this strategy.

What the strategy does#

The html-in-canvas path asks the browser to keep layout and paint decisions native, then snapshots that rendered subtree into a canvas context. For ReactSnap this means the strategy can stay closer to real DOM rendering behavior than a serialized foreignObject fallback.

When ReactSnap uses it#

ReactSnap resolves strategy selection in this order:

  1. Use the explicit strategy when the caller passes one.
  2. When the caller requests auto, prefer html-in-canvas if capability checks succeed.
  3. Fall back to foreign-object when the browser cannot satisfy the capability requirements or runtime rendering fails.

Browser requirements#

Today the capability check looks for these APIs:

  • layoutSubtree
  • requestPaint()
  • CanvasRenderingContext2D.drawElementImage()

If one of these is unavailable, ReactSnap should not pretend support exists. The invoice workbench on this site shows that state directly and surfaces the fallback reason so teams can debug in the browser, not just in docs.

Best use cases#

  • Strategy experiments during local development
  • Platform validation while browser vendors iterate on canvas rendering APIs
  • Internal tooling where Chrome configuration is controlled

What to tell users on this site#

A good product page should be plain about this route: it is a promising browser-native path, but not yet the compatibility baseline. That is why ReactSnap keeps foreignObject as the deterministic fallback and why SniCap's /reactsnap demo pages always render meaningful static explanation around the live workbench.