foreignObject is the current stable baseline in ReactSnap. It is the route you want when compatibility and deterministic fallback behavior matter more than experimenting with the latest browser APIs.
How it works#
At a high level ReactSnap uses this path:
- Clone the target DOM subtree.
- Inline the computed styles the export needs.
- Serialize the result into SVG with a
foreignObjectwrapper. - Load that SVG into an image.
- Draw the image onto canvas and export a
Blob.
Why it matters#
This route gives ReactSnap a dependable browser-side baseline while html-in-canvas stays experimental. It also keeps the mental model simple for product teams: when auto cannot use the WICG path, the export still completes through a known fallback.
Good fit scenarios#
- Product workflows where predictable export behavior matters more than trying an experimental renderer
- Browser compatibility-sensitive experiences
- SEO-facing demos where the explanation needs to stay stable even when browser support changes
Tradeoffs#
foreignObject is not the final architecture. It still depends on SVG serialization and today it does not solve every asset-embedding concern. ReactSnap's roadmap keeps calling out font embedding, image embedding, PDF work, and stronger diagnostics because those are the next layers needed around this baseline.
Relationship to SniCap#
For snicap.com/reactsnap, this strategy is useful because it mirrors the kind of product promise teams care about: generate a real output in the browser, then continue in SniCap for annotation, editing, and delivery.