I've been using html2canvas for a long time in https://play.basketball-gm.com/ so I gave your library a try. It was much slower (I know your README has benchmarks saying the opposite so idk) and the result looked a lot worse.
Also I recommend putting the npm package name clearly in your README. I guess I don't really know what other people are doing these days, but I think most people are like me and consume packages like this from npm rather than a <script> tag.
Thank you for testing it out and sharing the screenshots!
I’ve run some performance tests using Vitest Bench, and SnapDOM was faster. I also created a few manual demos, and SnapDOM won in both speed and accuracy.
That said, I still need to run more real-world tests. So, thanks again for your help!
You can embed HTML in an SVG via foreignObject. Seems like that's exactly what the library is doing[0].
Whether that's faster or more reliable, I don't know. Seems likely to render different depending on where you view the SVG (especially out of browsers).
Awesome! I was making exactly this library 13 years ago but only made it as far as creating CSS and other asset inlining+normalization tools before I ran into a few major roadblocks.
The most significant roadblock was that drawing SVG <foreignObject> with inline subresources (data: and blob: URIs) tainted canvases in Chrome and Safari, and this was partially resolved in 2019[1].
Notably, some issues still remain but apparently it's now workable. As is apparent from snapDOM, completely accurate CSS normalization is still an unsolved problem.
While I'm excited to see the HTML-in-foreignObject use case mature, it is also important to point out that the Media Capture API now has the ability to capture individual elements natively in Chrome[2].
Capturing HTML as scalable SVGs is huge, how do you manage condensing all of CSS and its quirks into an SVG? Do you only support a subset of styling properties and rely on the browser to calculate layouts for you?
I was upset about the size of generated svg file because at first all styles were inlined in each element. So I created a function to make mini css classes (.c1, c2, c3,...) So the final size is quite small.
How does this compare to something like the the Media Capture API? Looks like this uses `canvas.toDataURL()` which can be slow to serialize compared to `toBlob` or `canvas.captureStream(0).getVideoTracks()`
Hi! Insaw this API when I was starting to work on snapDOM but I thought it was not ok for my needs so I discarded it. Regarding other API it would be great if View Transitions API could exposed the old view in a future
Looks cool, somebody should make a package that puts a nice API around it. However seems that those APIs are only in Chrome now, not Firefox or Safari.
Tiny feature request: snapdom.toJpg(el) appears to return a JPEG image where the background color for any transparent areas is set to black - it would be useful to be able to set that to another color (I needed it to be white).
Image in the readme would really be helpful.
In fact anytime there is a visual output it makes sense to put an image.
Thanks for creating this though - Will give it a try for an upcoming project.
I’ve been writing a browser extension recently, and part of the functionality I want is to export part of a view as an image, shareable for the socials. I wanted to use html2canvas, but the docs explicitly advise against using it in a browser extension. Would snapDOM be suitable for inclusion in an extension?
Firefox has screenshot that auto-picks elements, or you can click and drag a crop, or you can save the whole page. That and ad nauseam are the reason I use firefox; that singlefile also works is great (single html file dump of a web page, somehow).
Maybe add a function to convert to PDF? I've always dreamed of converting an element or the document body to a long-scrolling PDF. I tried to implement it with Playwright Python, but I had no luck. The resulting PDF height is messed up.
It is pretty the same idea. There are many good solutions like dom-to-imge-more: the battle tested html2canvas, dom-to-image, modern-screenshot, etc. SnapDom is focused on avoiding long-taks whenever is possible because was designed to a zoomble UI engine that needs the capture doesnt affect the transition. But this is the first public version and there many things to adjust.
Not only screenshots, but also actual results. As I understand the short description, this tool allows to transform a website's current visual state into an SVG.
I've been using html2canvas for a long time in https://play.basketball-gm.com/ so I gave your library a try. It was much slower (I know your README has benchmarks saying the opposite so idk) and the result looked a lot worse.
html2canvas: https://i.imgur.com/zfSwNR1.png
snapdom: https://i.imgur.com/FxowTzp.png
Also I recommend putting the npm package name clearly in your README. I guess I don't really know what other people are doing these days, but I think most people are like me and consume packages like this from npm rather than a <script> tag.
Thank you for testing it out and sharing the screenshots!
I’ve run some performance tests using Vitest Bench, and SnapDOM was faster. I also created a few manual demos, and SnapDOM won in both speed and accuracy.
That said, I still need to run more real-world tests. So, thanks again for your help!
I'm working on enabling a special full mode for those who don't mind the final size:
https://github.com/zumerlab/snapdom/issues/1
How can svg be faster, and especially more accurate (lets throw some IMG or CSS shadows for fun) than canvas?
You can embed HTML in an SVG via foreignObject. Seems like that's exactly what the library is doing[0].
Whether that's faster or more reliable, I don't know. Seems likely to render different depending on where you view the SVG (especially out of browsers).
[0]: https://github.com/search?q=repo%3Azumerlab%2Fsnapdom%20fore...
I added to README the npm / yarn reference. Thanks!
Awesome! I was making exactly this library 13 years ago but only made it as far as creating CSS and other asset inlining+normalization tools before I ran into a few major roadblocks.
The most significant roadblock was that drawing SVG <foreignObject> with inline subresources (data: and blob: URIs) tainted canvases in Chrome and Safari, and this was partially resolved in 2019[1].
Notably, some issues still remain but apparently it's now workable. As is apparent from snapDOM, completely accurate CSS normalization is still an unsolved problem.
While I'm excited to see the HTML-in-foreignObject use case mature, it is also important to point out that the Media Capture API now has the ability to capture individual elements natively in Chrome[2].
1. https://issues.chromium.org/issues/41054640#comment49
2. https://developer.mozilla.org/en-US/docs/Web/API/CropTarget/...
Capturing HTML as scalable SVGs is huge, how do you manage condensing all of CSS and its quirks into an SVG? Do you only support a subset of styling properties and rely on the browser to calculate layouts for you?
I was upset about the size of generated svg file because at first all styles were inlined in each element. So I created a function to make mini css classes (.c1, c2, c3,...) So the final size is quite small.
How does this compare to something like the the Media Capture API? Looks like this uses `canvas.toDataURL()` which can be slow to serialize compared to `toBlob` or `canvas.captureStream(0).getVideoTracks()`
I've been using CropTarget.fromElement with a CaptureController: https://gist.github.com/akre54/e93ab2ce27999aecb109e38085f2e...
Hi! Insaw this API when I was starting to work on snapDOM but I thought it was not ok for my needs so I discarded it. Regarding other API it would be great if View Transitions API could exposed the old view in a future
What were your needs that the API didn't meet?
It requires user intervention and doesn't work for me.
Looks cool, somebody should make a package that puts a nice API around it. However seems that those APIs are only in Chrome now, not Firefox or Safari.
IMO it's simple enough to just write directly without library code.
For most cases, the Element Capture or Region Capture API should be sufficient: https://developer.mozilla.org/en-US/docs/Web/API/Screen_Capt...
Demos: https://mdn.github.io/dom-examples/screen-capture-api/elemen... https://mdn.github.io/dom-examples/screen-capture-api/region...
If you need cross-browser compatibility (and can't just use a canvas) then yeah html2canvas is the way to go
idk, your code is 170 lines, html2canvas and similar are 1 line to use.
I tested it on Chrome, Firefox and Safari
Tiny feature request: snapdom.toJpg(el) appears to return a JPEG image where the background color for any transparent areas is set to black - it would be useful to be able to set that to another color (I needed it to be white).
No problem! May you open an issue on the repo?
https://github.com/zumerlab/snapdom/issues/2
Image in the readme would really be helpful. In fact anytime there is a visual output it makes sense to put an image. Thanks for creating this though - Will give it a try for an upcoming project.
Thank you for the suggestion!
It doesnt load, snapdom dont appear in my devtools had to copy paste script
Plus it just struck at pending promise dont work
Plus css is messed up, i cant call it a snapshot, if it dont look same
domtoimage lib works for me and is fast whole html body node captured within second
I’ve been writing a browser extension recently, and part of the functionality I want is to export part of a view as an image, shareable for the socials. I wanted to use html2canvas, but the docs explicitly advise against using it in a browser extension. Would snapDOM be suitable for inclusion in an extension?
Firefox has screenshot that auto-picks elements, or you can click and drag a crop, or you can save the whole page. That and ad nauseam are the reason I use firefox; that singlefile also works is great (single html file dump of a web page, somehow).
Sincerely, I don't know if snapdom would work on a browser extension. I've never tested it on this scenery
Maybe add a function to convert to PDF? I've always dreamed of converting an element or the document body to a long-scrolling PDF. I tried to implement it with Playwright Python, but I had no luck. The resulting PDF height is messed up.
Its a bit out of scope right now, but I thing it would be possible using some external libraries such as jsPDF or svg2pdf.js
How does this compare with https://www.npmjs.com/package/dom-to-image-more?
It is pretty the same idea. There are many good solutions like dom-to-imge-more: the battle tested html2canvas, dom-to-image, modern-screenshot, etc. SnapDom is focused on avoiding long-taks whenever is possible because was designed to a zoomble UI engine that needs the capture doesnt affect the transition. But this is the first public version and there many things to adjust.
I found puppeteer or playwright to be good at this with their screenshot method. I made a cli tool for this recently that worked quite well.
Yes they are so good. But in my case I need to work only on the client side
Does snapDOM support capturing elements with CSS animations in their current frame, or does it only capture static states?
Yes it capture elements with css animations in theirr current frame. It isnt't work for animted gifs. And I have to test js animations engines
Does it work with some DOM polyfill in Node.js?
Not tested yet
How does it work
Screenshots on the GitHub would be great.
Not only screenshots, but also actual results. As I understand the short description, this tool allows to transform a website's current visual state into an SVG.
Why not do it at the back end where you can literally snapshot node to png.