SnapDOM

Un élément de page figé en image, côté navigateur

SnapDOM clone un élément déjà rendu dans la page, avec ses styles calculés, ses images et ses polices, puis l'exporte en PNG, JPG, WebP, SVG, canvas ou Blob. Tout s'exécute dans le navigateur, et le paquet npm @zumer/snapdom n'a aucune dépendance d'exécution. Une même capture s'exporte en plusieurs formats, même si l'élément a changé entre-temps.

Shadow DOM, polices web et pages plus hautes qu'un canvas

• Les racines Shadow DOM ouvertes, les iframes de même origine avec leurs propres polices, les compteurs CSS des pseudo-éléments et le line-clamp passent dans l'image.
• Depuis la v3, les polices web que l'élément utilise sont embarquées d'office (embedFonts: 'auto'), et une capture en polices système saute l'étape.
• Une page très longue sort en un seul PNG ou JPEG à pleine résolution par download() ou toBlob(), rendu par fenêtres plutôt que dans un canvas géant. Le JPEG monte à 65 535 px de côté.
• Un élément inchangé réutilise sa première capture, et une modification locale ne reconstruit que le sous-arbre touché.
• Les plugins officiels, sous MIT comme le cœur, ajoutent le PDF au texte sélectionnable, le SVG éditable, l'export HTML, GIF ou vidéo, et un contexte JSON destiné à un agent.

Export PDF, collage dans Figma et texture WebGL

• Télécharger une facture ou un graphique en PNG depuis l'écran qui l'affiche.
• Générer dans le navigateur un PDF paginé, aux liens actifs, à partir d'un fragment de page (plugin pdf).
• Copier un composant dans le presse-papiers au format Figma (plugin vector, en HTTPS ou sur localhost, au clic de l'utilisateur).
• Alimenter une texture Three.js avec un élément HTML, redessiné dans le même canvas à chaque rafraîchissement.

Navigateur obligatoire, troisième version majeure depuis mai 2025

Un vrai navigateur est indispensable, même côté serveur. SnapDOM travaille sur un DOM rendu : un processus Node.js doit piloter un navigateur pour s'en servir, par exemple un Chromium lancé par Playwright. Le paquet n'a pas de build CommonJS.

Les ressources d'un autre domaine restent à la charge de l'application. Images, polices et feuilles de style tierces doivent être lisibles par CORS ou passer par un proxy (useProxy) ; l'attribut crossorigin ne sert à rien si le serveur ne l'autorise pas. Une iframe d'une autre origine devient un espace réservé.

Le SVG par défaut est fait pour les navigateurs. Il enferme du HTML dans un <foreignObject>, que les autres visionneuses affichent inégalement. Un SVG à retoucher dans un éditeur passe par le plugin vector, qui ne convertit que les effets de peinture qu'il prend en charge.

fromString() exécute le HTML qu'on lui confie. Un gestionnaire inline comme <img onerror> tourne dans l'origine de la page appelante : le README demande de nettoyer tout HTML non fiable avec DOMPurify ou un équivalent. Dans un formulaire, le cœur ne masque que les mots de passe, et les autres valeurs saisies apparaissent dans l'image sans le plugin redact-inputs.

Les mesures de vitesse viennent du projet, avec leurs réserves. SnapDOM se compare à html2canvas, modern-screenshot, html-to-image et dom-to-image dans son fichier de benchmarks. Ce fichier présente ses tableaux comme des mesures du développement de la v3, pas comme une garantie de vitesse, et précise qu'aucun script de publication ne relance les benchmarks.

Trois versions majeures sont sorties depuis mai 2025 : la 1.0.0 le 19 mai 2025, la 2.0.0 le 18 novembre 2025, la 3.0.0 le 14 septembre 2026. La v3 supprime preCache, ne prend plus en charge burst ni compress, et fait primer width sur scale. La 3.4.0 date du 24 octobre 2026, septième version du mois, et les plugins 4.x exigent un cœur 3.3.0 ou plus récent.