Even though the article is mostly talking about visualizations, but I thought I'd share that I did at one point build a dance choreography software that renders the UI entirely SVG. I was surprised as to how well that worked.
If you're curious, it's called StageKeep, and you can find it here. https://stagekeep.com/
The original project used React Three Fiber, but refactored it to SVG for reasons I don't quite remember. I was inspired by signed distance functions, and the fact that one function could have such an outsized visual effect. Although the software doesn't use SDFs, but I like the idea of atomic functions that accepts some input, and outputs SVG.
SVG was once hailed as the Flash-killer. With SVG + CSS + JavaScript you could do anything you could do with Flash, including those fancy Flash websites or complex applications. There just weren't any good authoring tools, while Flash had an amazing one.
Then Flash just died without being replaced by anything
Steve jobs killed it when said it would work on the iPhone because if the "huge" memory and battery resources.
He said Javascript and HTML was everything you needed.
Thank gawd. Flash, gawd bless it, was a low point in internet history. People simply couldn’t resist misusing it and abusing it. I’m not blaming the tool per se. But Flash’s addictiveness caused reasonable people to make gawd-awful UI and UX decisions. Crushing Flash is probably Jobs’ most underrated accomplishment.
Honestly, I blame Adobe most for the death of Flash.
If they had been willing to invest the resources needed to make it both performant and, most importantly, secure, there's a much better chance that it would have survived—it might even have been enough for Jobs to be willing to have it work on the iPhone. (Maybe.)
Too many people lamenting how the death of Flash ended a thriving ecosystem of games and other art forms forget that Flash was also a huge resource hog, one of the #1 sources of crashes on many systems, and an absolutely massive vector for malware. I'd love to see some statistics on just how many infections were enabled by Flash, and how fast that declined once it stopped being a requirement to browse large chunks of the web.
And don't forget, either, that Flash wasn't originally an Adobe product: they took it over when they bought Macromedia, eliminating their biggest competitor and guaranteeing their monopoly. I wasn't really paying that much attention to the space, but it wouldn't surprise me if under Macromedia, it was getting better and more frequent updates.
That kind of Flash is still around and well. Many newer shows are animated in Flash (MLP: FiM, Bluey, the last season of Fairly OddParents, etc.). What was killed wasn't Flash itself, but Shockwave Flash (Flash in the browser).
Part of the problem was that browsers never really fully optimized svg, especially with CSS. Animated stroke patterns were especially rough, if my memory serves.
SVG rendering on browsers is still sub-optimal, which I think is a shame as SVG has great potential if it was treated as a first-class element on the web. Recent improvements to the code driving (2D) Canvas API canvas elements shows that this work could be done across browsers. The big thing holding back development is possibly the continuing failure to finalise the SVG2 standard?
It's sub-optimal in that browser developers have - for a number of legitimate reasons - chosen not to spend their time building SVG engines into their browsers that are efficient, robust and fast. I think its more a story of benign neglect rather than active discouragement. Compared to the Javascript and CSS engines, which have improved massively over the past decade, SVG remains ... serviceable for basic requirements (simpler stuff - static graphics, icons, etc), but nothing more. If that makes sense?
I don't know anything about the browser internals or the development process/plans, but I've used requestAnimationFrame to animate SVG graphics from JavaScript and it has been super smooth for me even without a modern graphics card (only on-board graphics). The only time I've seen a performance degradation was with a complex filter involving blurs and specular reflection.
I was doing some pretty decent rendering in HTML4 back in 2008.. supporting various browers (let alone IE6, 7 and maybe 8 at the time)
Around 2010, I did experiment with things like Silverlight and SVGs. SVGs was OK, but the performance quality was not there. It might be a lot better now.
This is a brilliant piece of software and I've had a blast learning about it.
I would LOVE to see this feature: pass it a video, get a formulated choreography based on that video. For example, take a Project21 or Avantgardey video, do some AI/ML voodoo, import their choreography.
If this worked I'd love to see this applied to Bob Fosse's 'The Rich Man's Frug'. That kind of choreography is the kind that makes me wish I'd picked a wildly different career path.
Minor nit but I noticed at the bottom the text reads “Start free tiral”. Maybe a dance-themed joke that went over my head? But probably intended to be “trial” :^)
That said, the founder who hired me to work on this is a dancer.
He hired me because he liked the fact that during the interview, when asked "what do you know about dance", I responded "I used to crip walk when I was in high school", so I was the top choice just for that, haha.
Edit: the Founder is Axel Villamil, and he's super charismatic. Y'all are going to love him. Here's him trying to raise an investment round https://www.instagram.com/reel/CyhL5kitUbD/
"""
In my idealistic vision of how scientific publishing should work, each paper would be accompanied by a fully interactive environment where the reader could explore the data, rerun the experiments, tweak the parameters, and see how the results changed.
"""
I do like seeing larger labs/companies releasing research full of SVGs. In recent memory, I quite liked this from NVIDIA:
This really reminds me of a new paper [1] from my colleagues. All figures in the paper link to a website, where the figures can be reproduced and dynamically changed in the browser from the source data. It's really cool, it is a static website that runs DuckDB, WebR, and ggplot. Here [2] is an example for the first figure.
The idea of rerunning experiments only seems feasible when the entire experiment was based on modelling, presumably modelling that can easily/quickly be rerun in a browser environment.
The idea of being able to view and parse the dataset in different ways is interesting though, effectively allowing readers to interpret the experiment's resulting dataset from different angles than the author published.
Without the OP's proposed use of SVG, what format would someone use? PDFs won't handle it well - unless PDF's interactivity capabilities are much better than I think. We never developed a client-side multimedia file format; all we have are text formats like Word and PDF, which embed images decently, and embed multimedia and interactivity (beyond form filling) in awkwardly and in a limited manner.
What's wrong with SVG? Notebooks have their issues but are kinda this conceptually. I guess FLAs and Flash too. But you say we never developed a "client-side multimedia file format". Is that not exactly what html + js are for?
I mean the equivalent of a Word document: a file I can reasonably edit, including editing the multimedia and interactive/dynamic content, save, email, put on a thumb drive or Dropbox, etc.
I'd say that html+js suggestion of GP still holds, but with caveats. After all these years, HTML has everything needed for this, including images that can be embedded via the data URI scheme [1].
For example, I once adjusted an Object Pascal interactive program (target: Windows/Win32) for the browser target (FreePascal compiler has the JS target). An intermediate result was a bunch of files that worked locally on desktop but struggled on mobile. With a little help from the SingleFile extension [2], I ended up with a single HTML file containing all functionality and content. It worked great, for example, in MiXplorer's internal HTML viewer. I can't recall the exact details, but the file:/// protocol still had issues in Chrome, Firefox, or both. Anyway, preparing a local address correctly with a keyboard is a challenge so let's just assume that having capable file managers running local html files is enough
Sure, to make this manageable, you need good tools that handle all sides of the task. But at least in theory, the format is fully capable. My only global issue was that the state for locally run HTML files is a kind of ephemeral entity, but for interactive multimedia files, you may consider this obstacle small.
In essence you're describing epub, which is HTML, and I agree. It has great potential but nobody seems to see it as more than a cheap ebook format, and even that is underdeveloped in terms of capabilities: presentation quality and annotation are nowhere near PDF, for example.
Most of all it needs usable editors, and editors which integrate multimedia and dynamic content editing. End users can't turn to a different editor for each media and then integrate the output into the epub document, like a web developer does (e.g., for an image use Photoshop, save the jpg, copy to the proper directory, reference appropriately in the html).
I think HTML is exactly the "client-side multimedia file format" you want. I guess what we don't have is an established editor UI. You have to create it yourself.
It's if we had the .docx format but MS Word was read-only. You would have to create the XML and zip it yourself, to be then rendered by Word. That's effectively how I see HTML+js in browsers.
Interactive and SVGs don't really mix, although intuitively it would seem that they do. Rendering remotely complex SVGs tale multiple seconds, while any kind of interactivity demands ~30+ frames per seconds.
Without interactivity, postscript is vector graphics too.
I'd be curious to know what classes as complex for you, since ive done some frankly crazy stuff with svg's, which outperformed any raster implementation. Ultimately, poor performance was always my fault, especially initially when i was still treating it with paradigms better suited to the world of raster graphics.
- cannot embed font glyphs - your SVG might be unreadable if the user doesn't have the font installed. You can convert letters to curves, but then you won't be able to select and edit text. It's such an obvious problem, yet nobody thought of it, how? Photoshop solved this long time ago - it saves both text and its rendering, so the text can always be rendered.
- browsers do not publish, which version and features they support
- may contain Javascript and references to external resources, which makes it difficult to view in a secure, isolated environment
One of solutions is having two SVGs: author version, which you edit in Inkscape and which uses Inkscape-specific extensions, and published version, which is generated from the first, that uses only basic features and has text converted to curves.
- They often render differently in different browsers and other renderers. It's very frustrating to get consistent results (like a PDF). In complex diagrams I'd say it's basically impossible
- Renderers that are fast usually lack many features
- Nobody other than the browser seems to actually have all the features?
- You can link an SVG within an SVG (to make a lightweight composite image). But if you have two levels of indirection then all renderers I've tried will refuse to render the SVG
- Inkscape is basically the only good editor on Linux and it easily runs out of memory and crashes for complex images
- Complex SVGs eat all your RAM in Chromium (only marginally better in Firefox)
- Basic things like arrows from Inkscape will not render anywhere else
I still use SVGs all the time, b/c there are no good alternatives, but it's a crappy standard and I try to keep all my images/diagrams extremely simple
Safari supports base64-embedding font files in a <style>’s @font-face {} (iirc it's something like `@font-face { src: url('data:application/x-font-woff;charset=utf-8;base64,...'); }`) that can then be referenced as normal throughout the SVG. I don't recommend this though, nobody wants to deal with 500KB SVGs.
The idea was that you can embed only the glyphs used in a text. For example, instead of embedding thousands of existing Chinese characters, embed only 20 of them. Embedding is necessary anyway because otherwise you cannot guarantee that your image will be displayed correctly on the other machine.
Also, allowing CSS inside SVG is not a great idea because the SVG renderer needs to include full CSS parser, and for example, will Inkscape work correctly when there is embedded CSS with base64 fonts? Not sure.
> Also, allowing CSS inside SVG is not a great idea because the SVG renderer needs to include full CSS parser, and for example, will Inkscape work correctly when there is embedded CSS with base64 fonts? Not sure.
For better or worse, CSS parsing and WOFF support are both mandatory in SVG 2.[0][1] Time will tell whether this makes it a dead spec!
You can also point to font files with @font-face. I use a small custom font that's only 16 KB. Although, when opening the file locally, you have to first disable local file restrictions in safari's settings before it works...
This is possible, but only in the stupid way of using a `<foreignObject>` to embed HTML in your SVG (which obviously only works if your SVG renderer also supports at least a subset of HTML). SVG 2 fixes this by adding support for `inline-size`[0], so now UAs just need to… support that.
> - cannot embed font glyphs - your SVG might be unreadable if the user doesn't have the font installed. You can convert letters to curves, but then you won't be able to select and edit text. It's such an obvious problem, yet nobody thought of it, how?
Somebody did think of it. SVG 1.1 added the `<font>` element[1]; SVG 2.0 replaced this with mandatory WOFF support.[2] A WOFF is both subsettable and embeddable using a data URI, and is supported by all the browser UAs already, so it’s obvious why this was changed, but embeddable SVG fonts have existed for a long time (I don’t know why/how they got memory holed).
> - browsers do not publish, which version and features they support
It should be possible to use CSS `@supports` for most of this and hide/show parts of the SVG accordingly in most places.[3] The SVG spec itself includes its own mechanism for feature detection[4], but since it is for “capabilities within a user agent that go beyond the feature set defined in this specification”, it’s essentially worthless.
There are obvious unsolved problems with SVG text, but they are more subtle. For example, many things one might want to render with SVG (like graphs) make more sense with an origin at the bottom-left. This is trivial using a global transform `scaleY(-100%)`, except for text. There is no “baseline” transform origin, nor any CSS unit for the ascent or descent of the line box, nor any supported `vector-effect` keyword to make the transformation apply only to the position and not the rendering. So unless the text is all the same size, and/or you know the font metrics in advance and can hard-code the correct translations, it is impossible to do the trivial thing.
There are other issues in a similar vein where scaling control is just ludicrously inadequate. Would you like to have a shape with a pattern fill that dynamically resizes itself to fill the SVG, but doesn’t distort the pattern, like how HTML elements and CSS `background` work? Good luck! (It’s possible, but much like the situation with text wrapping, requires egregious hacks.)
Some of the new `vector-effect` keywords in SVG 2 seem like they could address at least some of this, but those are “at risk” features which are not supported by UAs and may still be dropped from the final SVG 2 spec.
Two years ago I re-vamped my "Spurious Correlations" side project, which is mostly just a bunch of charts. However, I couldn't find a charting software I liked that would display clean, simple visuals with the constraints I wanted. (I had used pCharts and HighCharts in the past, but didn't like charting in Javascript or PHP.)
I decided to "roll my own" and write Python scripts that outputted SVG markup. I was worried this would go about as well as every other "roll your own" project does, but was pleasantly surprised. It is surprisingly easy to output reliable, good-looking SVG graphics using Python. If you are making a chart, everything is just math.
The infinite scalability is almost just a happy upside to the simplicity of creating the visualizations, which is annoying in raster format. It made me like SVG even more.
If anyone is looking for a clean JS charting framework, I highly recommend Observable Plot.
It's from the creator of D3 and it's much easier than using raw D3. I've been using it outside the Observable platform for debug charts and notebooks, and I find its output crisp and its API very usable.
It doesn't try to have all the bells and whistles, and I'm not even sure if it has animations. But for the kind of charts you see in papers and notebooks I think it covers a lot.
It's a bit sad that Postscript never caught on as much as it could have. In an alternate timeline, it could have been the HTML (and SVG) we got in ours.
PDF is a sad replacement for PS. As far as I can tell, it was an attempt to obscure PS, because alternative vendors were getting better as Postscript than the originators.
(There was some justification in terms of 'Oh, a binary format like PDF is more space efficient.' But PDF never really was more efficient than compressed PS.)
It's not that PS has vanished, but PS isn't nearly as 'everywhere' as HTML came to be.
From the perspective of someone who worked in printing and publishing starting in the 1980s, there's more to it than that. PostScript was and is terrific as a page description language and as a printer control language. It absolutely revolutionized the printing business. For the first time, you could get complete pages (as opposed to unpaginated galleys) out of high-end imagesetters.
But it was not all that good as a way to send documents to be printed elsewhere. Postscript files were in some ways too dependent on the printer they targeted, so the person creating the PS file had to know too much about the printer that would be used to print it: its resolution and optimal halftone screen frequencies, media sizes, etc. With high-resolution output on photographic film costing around $10 per foot, mistakes could be expensive as well as time-wasting.
Fonts could also be a problem. Ideally, the PS file would contain all the fonts it required but this did not fit very well with the terms of most font licenses. And some applications would include a copy of every font used once on each page on which it was used. This was in line with Adobe's recommended Document Structuring Conventions and had the advantage of making pages within the file independent of one another, but for documents with hundreds of pages, this could add up fast and make the PS file literally hundreds of times larger than if all the fonts were included just once. With small storage media and slow network links, this was a real problem.
The "P" in PDF is for portable, and these are the problems it solved. Unlike a PS file, a PDF file is not targeted for a specific printer model, and most font licenses allowed the licensee to include subsetted fonts in PDF files. I personally prepared PS files for a few thousand books to be printed at various places around the US and later, PDF files for thousands more. There is no comparison: PDF was and is better in every way for this purpose.
PDF is also a lot less powerful, purposefully so. You can start an infinite loop just by double-clicking a PS file, for instance.
It is extremely useful to have a full programing language as a file format, though.
I miss macOS’s Preview.app auto-converting PS to PDF when double-clicked. It was a way to easily distribute a document that could randomize question orders each time it opened, print multiple bingo cards from a single file, etc.
The stack-based and reverse Polish notation thing was also fun.
Thanks for making that website. I used examples from it in the first day of my statistics course ("by the end of this course you won't make these kinds of mistakes").
The first Distill publication[0] made tasteful use of minimal interactivity through JavaScript/d3.js[1] on top of SVGs. Many of the illustrations were initially drawn in GUI editors.
(Outstanding work by Shan Carter; it’s what I first saw of his style and it’s what made me want to join his team.)
Around 15 years ago, I built a barbecue controller. This controller had four temperature probes that could be used to check the temperature of the inner cooking chamber as well as various cuts of meat. It controlled servos that opened and closed vents and had a custom derived PID algorithm that could infer the delayed effects of oxygen to charcoal.
Anyway, of relevance to this thread is that the controller connected to the local wireless network and provided an embedded HTTP server with an SVG based web UI that would graph temperatures and provided actual knobs and dials so that the controller could be tweaked. SVG in the browser works nicely with Javascript.
Author here: I've just made a ninja edit of the post as it didn't really make clear a quite important point - the SVG is literally 20 years old, and still works, astonishingly. I'm not sure much else I wrote around the time would still work without some editing!
The reverse is kind of true: In the beginning, SVGs were not really an option since it lacked adoption across all major browsers, or more specifically its integration was very heterogenous.
So a SVG you authored 20 years ago for some browser will likely work everywhere today.
I embedded a chess engine in SVG image of a chess board (https://github.com/jnykopp/svg-embedded-chess) so that the engine moved the pieces automatically and played against itself, just by viewing the SVG.
This was done for a friend of mine who made an art installation that projected like some 50x20 (can’t remember exactly) of these images in a grid on a wall, for perpetual chess madness.
The number of chess SVGs a laptop’s browser was able to run simultaneously did feel suprisingly low, but luckily it was enough for that particular piece of art.
Yeah; I've built a map viewer in SVG+JS for my small browser game, and it works quite well for that purpose, but when I tried to repurpose the underlying code for a different game, with a much higher object density, it became quite unmanageably slow. (I rebuilt the map for that game using canvas, but it does lose me some functionality.)
Ages ago, when doing the instructions for the opensource CNC Shapeoko v2 it became necessary (after the project was featured w/ a full page in _Popular Mechanics_ magazine to cater to users who could not visualize as well as the early adopters were able to, so the diagrams were made interactive:
Used to be if that was opened in a web browser one could click on the parts list to show/hide or highlight/unhighlight the matching items in the diagram.
My day job involves building dashboards, and SVGs have been invaluable for crisp icons and graphs... the portability across sizes is a blessing, but some of the more exotic filter effects still fail in certain browsers.
ALSO I've run into security reviews that flag inline SVGs because they can embed scripts... would love to see more tooling to lint and sanitize them before deployment.
BUT seeing a two-decade-old vector still render correctly gives me confidence that the core spec is solid.
> would love to see more tooling to lint and sanitize them before deployment
Sanitisation is one of two possible defences, the other being script execution controls or sandboxing. E.g., if you serve vector images on a web server, set a Content Security Policy header¹ for all your images that simply denies all scripting. You can also run it from a dummy domain ('origin') with nothing valuable on it (like how domains such as googleusercontent.com and githubusercontent.com are being used)
For sanitisation, DOMPurify² is the only widely used and tested library that I know of. It could use more bindings for other languages but, if you can call into it, it can go in your deployment pipeline. (Disclosure: I've worked with some of the people at Cure53, but not on this project)
You can also combine the approaches for defence in depth
This was delightful.
I would greatly enjoy seeing more use cases, as well as new editors, and new ways of working with SVG while keeping with it's capabilities and capacities.
now I find this:
https://cartosvg.com/
which is mind blowing the capability and capacity, just the first example from link, really makes my day https://cartosvg.com/italia then the 2nd!
It's compelling.
I wish I could have built what i was trying to conceive building using OSC (Open Sound Control), but what i was setting out to do was ultimately brought into the world by Hexler's TouchOSC, i just wish somehow someone could have took VST to a unified front, and made it random controller populatable. impossible back then, yes. Today, different.
I once solved a machining problem using SVG and a bit of javascript and python.
I was prototyping an orrery. It involved cutting out a lot of ad-hoc gears and frame bits on my CNC out of a sheet of brass. It was relatively easy to generate the g-code for the individual parts using fusion360, but then it was a lot of faff to zero the machine such that it cut the part from a fresh part of the brass sheet without wasting too much metal in between the parts. It involved a lot of guesswork, and eyeballing. And even with that there was a lot of brass “wasted” between the parts especially since you could only move your part in x-y but not easily rotate it.
As a solution I wrote a python script which converted the g-code into svg, and a simple one page website where i could drag the svg around and rotate it on a visual representation of the sheet. Once i found a good safe spot for it to be cut the page told me the x,y, theta coordinates for it. And then with a separate python script i could transform the g-code using the coordinates and rotation. This way the svg renderer was doing the heavy lifting of visualising the cutting paths, and i only needed to concentrate on the relatively easy transforms.
>They are supported on just about every device and platform
Except they aren't. I recently used a simple SVG in a background and Safari wasn't able to render it properly so after trying lots of different things I gave up and used different sizes of raster images instead.
SVGs also are mostly unsupported for og:image tags (dependents on the app/browser). I know it's supper specific and I am not even sure if open graph is standardized protocol or not, but it's used everywhere.
What was the SVG that didn't work? In Jon's example in the original post, the SVG he embeds there was one he wrote in around 2005. That's a pretty impressive run for it to render 20 years on...
I assume the goal is to get rid of all foreignObject uses eventually? (Otherwise it would be easier yo render one big foreignObject and convert everything to HTML)
Anyways, impressive, but what I’d really love to see is flexbox for SVG ;)
This feels a little bit like discovering frontend software development? I guess we're done with the trend of being scared of bundling features and running them in the browser close to the user with JavaScript.
I once built a music game that basically ran entirely on SVG. We hacked Musescore to attach the same UUID to both the note head in SVG and the MusicXML object in two different output modes, and then used that to synchronise the sheet music scrolling with a MIDI stream. If you're interested you can see it in action in our failed Kickstarter video from like eight years ago: https://www.youtube.com/watch?v=vgbB5Q4-dgY
I use ChatGPT to compress SVGs, in particular QR codes. Many QR code SVG generators produce inefficient SVGs, and conventional SVG compressors often lack the understanding required for some compression techniques. ChatGPT can replace alignment indicators with <use> elements.
Is there a way to embed the data encoded in the QR code directly within the image? This would allow the data to be parsed directly by the browser, eliminating the need for computer vision to decode it again. Going further, for web images QR codes could be efficiently encoded and rendered by the browser.
I am not sure about your use case. There exist many JS libraries which will generate client side QR codes. How many of them do you handle that you optimize for file size? Or is it just an academic interest?
SVGs are XML so technically, yes, you can just embed your visually encoded payload data with namespaces attributes and elements. If you don't want to use namespaces, you can use off-canvas texts, hidden/opacity=0 texts or even XML comments. You can even use the regular metadata section of SVGs. You can make the whole QR code within the SVG a clickable link.
I notice one issue in SVG support in browsers that make it pretty unusable. When multiple polygons connect by edge, renderers alpha-blend their edges as if they are in general position, causing visible 'seam'. This is well-known problem in 2D graphics, usually handled by explicit selection of blending functions, but i cannot find anything about how to fix it in SVG.
This way - even if the user changes themes, the colors of the image will be consistent with whatever theme is currently active. Also - the loading time is near-instant since we don't need to fetch the img file for the blog post image - just render the svg.
I remember an employee of mine, who was possibly the best engineer I ever knew, wrote up a specification document for his own vignetting algorithm, in Postscript.
The algorithm provided a 100X performance improvement over the classic Monte Carlo stuff that Tokyo had written.
The charts in the document were executable Postscript, running his algorithm.
That got the attention of the Ph.Ds in Tokyo. He was a high school-educated neurodivergent.
I recently found out that it is surprisingly hard to convert an SVG file that consists of series of line segments into a list of those line segments in Python.
I tried with ChatGPT and Claude but both were not able to find a solution that respects the entire specification, especially transforms.
Initially, my expectation was that there must be a library for this kind of thing, but alas.
I seem to remember that the DOM nodes themselves expose some pretty useful functions. I think it was in the context of detecting edge crossings for a graph router, but you were able to interact with the computed/rendered coordinates in this context.
Sorry that's not more useful and explicit, it was a while back and never went anywhere.
I love seeing old formats hold up this well. SVG surviving 20 years of browser evolution is a pretty strong argument for “boring tech” done right.
It makes me wonder why we don’t see more research papers ship with fully self-contained interactive SVGs today — the tooling and browser performance are better than ever.
Is there a 3D equivalent (technical or spiritual) of SVG? I've been working on a CAD visualizer, and I'm looking for something lightweight that I can use to build up representative changes to cad models without having to do a full loop through the CAD application, pull a full .step export, and visualize that.
SVGs will work nicely for showing 2d sketches, but I'm hoping for something similar for the models themselves, without the slowdown of having to use the underlying CAD software for visualization.
SVG's are so fun! The amount of logic you can put into an SVG is absolutely wild given what they're generally used for. My desktop wallpaper uses embedded JS to create a random Barnsley fern fractal every time the system starts, so it's different every time. The only problem is that only browsers have the full SVG spec support I needed to get it to work correctly, but that's nothing that systemd and puppeteer can't fix.
The magic here is happening via the <script> tags, where you have access to the browser APIs like you would an <canvas> instead of <svg>. E.g. here's a sample I forked following the mouse using <svg> with <script> inside https://codepen.io/zamadatix/pen/emZXZKx?css-preprocessor=sc...
Libraries like three.js had SVG rendering as an option but it got deprecated as <canvas> with more direct GPU APIs was a lot more efficient and flexible.
A few years ago I learned just enough d3 to show an interactive 2D lollipop graph. Later I learned just enough SVG to get a small diagram out for a college class. I think going back if I were to redo that first interactive graph I'd probably just do it in raw SVG.
I remember making an .svg spirit thermometer that polled our local weather station and scaled the red bar accordingly some 12 years ago. A nice gimmick but I didn't see any real use for it. We joked about making a single-image SCADA monitor screen.
This is going to really transform some data visualization things I've been thinking about. I've always loved SVG since working with Illustrator and Inkscape back in the day, but I didn't realize how much it could tie in with the modern web and interactivity. Thank you!
First off, what kind of SVG reader does cloudflare assume to just open SVGs and Willy nilly run contained js? Is that a windows os feature?
Second, do they not know about Content Security Policies?
And as a side note: Cloudflare itself is considered harmful
The JS is exposed in the full page's context the same as if you included a <script> under a <div> instead of <svg>. In much the same way, whether the <script> is before or after the <svg> tag doesn't matter - it's just a script working on a single DOM (with different namespaces for certain elements) either way.
I don't think LLM's are that great at manipulating SVG unless you mean like small edits like rotation and font size. Cool article though, I'll have to think how I can leverage it.
Of course, but in comparison to bitmap tools like midjourney, you can communicate with an AI by specifying a SVG element to be manipulated. "Rotate ID "logo" 30 degrees" is very legible to the AI
Even though the article is mostly talking about visualizations, but I thought I'd share that I did at one point build a dance choreography software that renders the UI entirely SVG. I was surprised as to how well that worked.
If you're curious, it's called StageKeep, and you can find it here. https://stagekeep.com/
The original project used React Three Fiber, but refactored it to SVG for reasons I don't quite remember. I was inspired by signed distance functions, and the fact that one function could have such an outsized visual effect. Although the software doesn't use SDFs, but I like the idea of atomic functions that accepts some input, and outputs SVG.
SVG was once hailed as the Flash-killer. With SVG + CSS + JavaScript you could do anything you could do with Flash, including those fancy Flash websites or complex applications. There just weren't any good authoring tools, while Flash had an amazing one.
Then Flash just died without being replaced by anything
Steve jobs killed it when said it would work on the iPhone because if the "huge" memory and battery resources. He said Javascript and HTML was everything you needed.
Here is the original memo: https://www.editionmultimedia.fr/wp-content/uploads/2020/12/...
Thank gawd. Flash, gawd bless it, was a low point in internet history. People simply couldn’t resist misusing it and abusing it. I’m not blaming the tool per se. But Flash’s addictiveness caused reasonable people to make gawd-awful UI and UX decisions. Crushing Flash is probably Jobs’ most underrated accomplishment.
Honestly, I blame Adobe most for the death of Flash.
If they had been willing to invest the resources needed to make it both performant and, most importantly, secure, there's a much better chance that it would have survived—it might even have been enough for Jobs to be willing to have it work on the iPhone. (Maybe.)
Too many people lamenting how the death of Flash ended a thriving ecosystem of games and other art forms forget that Flash was also a huge resource hog, one of the #1 sources of crashes on many systems, and an absolutely massive vector for malware. I'd love to see some statistics on just how many infections were enabled by Flash, and how fast that declined once it stopped being a requirement to browse large chunks of the web.
And don't forget, either, that Flash wasn't originally an Adobe product: they took it over when they bought Macromedia, eliminating their biggest competitor and guaranteeing their monopoly. I wasn't really paying that much attention to the space, but it wouldn't surprise me if under Macromedia, it was getting better and more frequent updates.
It ended an era of easy to make web games though.
Flash directly led to South Park, however. one of the funniest animated series ever. Worth it!
That kind of Flash is still around and well. Many newer shows are animated in Flash (MLP: FiM, Bluey, the last season of Fairly OddParents, etc.). What was killed wasn't Flash itself, but Shockwave Flash (Flash in the browser).
Part of the problem was that browsers never really fully optimized svg, especially with CSS. Animated stroke patterns were especially rough, if my memory serves.
SVG rendering on browsers is still sub-optimal, which I think is a shame as SVG has great potential if it was treated as a first-class element on the web. Recent improvements to the code driving (2D) Canvas API canvas elements shows that this work could be done across browsers. The big thing holding back development is possibly the continuing failure to finalise the SVG2 standard?
Can you describe what you think is sub-optimal? Is it just the performance or is there something else?
I've been using SVG for years for various purposes (though, admittedly, mostly static graphics) and I can't complain.
It's sub-optimal in that browser developers have - for a number of legitimate reasons - chosen not to spend their time building SVG engines into their browsers that are efficient, robust and fast. I think its more a story of benign neglect rather than active discouragement. Compared to the Javascript and CSS engines, which have improved massively over the past decade, SVG remains ... serviceable for basic requirements (simpler stuff - static graphics, icons, etc), but nothing more. If that makes sense?
I don't know anything about the browser internals or the development process/plans, but I've used requestAnimationFrame to animate SVG graphics from JavaScript and it has been super smooth for me even without a modern graphics card (only on-board graphics). The only time I've seen a performance degradation was with a complex filter involving blurs and specular reflection.
I was doing some pretty decent rendering in HTML4 back in 2008.. supporting various browers (let alone IE6, 7 and maybe 8 at the time)
Around 2010, I did experiment with things like Silverlight and SVGs. SVGs was OK, but the performance quality was not there. It might be a lot better now.
Certain businesses paid for years to keep a private-label version of Flash alive for their internal Flash business applications.
This is a brilliant piece of software and I've had a blast learning about it.
I would LOVE to see this feature: pass it a video, get a formulated choreography based on that video. For example, take a Project21 or Avantgardey video, do some AI/ML voodoo, import their choreography.
Think that'd be possible?
If this worked I'd love to see this applied to Bob Fosse's 'The Rich Man's Frug'. That kind of choreography is the kind that makes me wish I'd picked a wildly different career path.
Wow, that is really cool. As a stage director I touch on choreography a bit. It would be really cool to pre-plan blocking with something like that.
That's good for blocking. Then, for movement, what? Probably not Labanotation.
Minor nit but I noticed at the bottom the text reads “Start free tiral”. Maybe a dance-themed joke that went over my head? But probably intended to be “trial” :^)
Very cool. Are you a dancer yourself?
Heh, thanks.
I wish I was a dancer.
That said, the founder who hired me to work on this is a dancer.
He hired me because he liked the fact that during the interview, when asked "what do you know about dance", I responded "I used to crip walk when I was in high school", so I was the top choice just for that, haha.
Edit: the Founder is Axel Villamil, and he's super charismatic. Y'all are going to love him. Here's him trying to raise an investment round https://www.instagram.com/reel/CyhL5kitUbD/
That is the best reason I've ever heard a developer win an interview with.
I agree with the author when they write:
""" In my idealistic vision of how scientific publishing should work, each paper would be accompanied by a fully interactive environment where the reader could explore the data, rerun the experiments, tweak the parameters, and see how the results changed. """
I do like seeing larger labs/companies releasing research full of SVGs. In recent memory, I quite liked this from NVIDIA:
https://research.nvidia.com/labs/dbr/blog/illustrated-evo2/
This really reminds me of a new paper [1] from my colleagues. All figures in the paper link to a website, where the figures can be reproduced and dynamically changed in the browser from the source data. It's really cool, it is a static website that runs DuckDB, WebR, and ggplot. Here [2] is an example for the first figure.
[1] Paper: https://www.cs.cit.tum.de/fileadmin/w00cfj/dis/papers/clouds...
[2] Figure 1: https://tum-dis.github.io/cloudspecs/?state=N4IgzgjgNgigrgUw...
The idea of rerunning experiments only seems feasible when the entire experiment was based on modelling, presumably modelling that can easily/quickly be rerun in a browser environment.
The idea of being able to view and parse the dataset in different ways is interesting though, effectively allowing readers to interpret the experiment's resulting dataset from different angles than the author published.
Without the OP's proposed use of SVG, what format would someone use? PDFs won't handle it well - unless PDF's interactivity capabilities are much better than I think. We never developed a client-side multimedia file format; all we have are text formats like Word and PDF, which embed images decently, and embed multimedia and interactivity (beyond form filling) in awkwardly and in a limited manner.
What's wrong with SVG? Notebooks have their issues but are kinda this conceptually. I guess FLAs and Flash too. But you say we never developed a "client-side multimedia file format". Is that not exactly what html + js are for?
I mean the equivalent of a Word document: a file I can reasonably edit, including editing the multimedia and interactive/dynamic content, save, email, put on a thumb drive or Dropbox, etc.
I'd say that html+js suggestion of GP still holds, but with caveats. After all these years, HTML has everything needed for this, including images that can be embedded via the data URI scheme [1].
For example, I once adjusted an Object Pascal interactive program (target: Windows/Win32) for the browser target (FreePascal compiler has the JS target). An intermediate result was a bunch of files that worked locally on desktop but struggled on mobile. With a little help from the SingleFile extension [2], I ended up with a single HTML file containing all functionality and content. It worked great, for example, in MiXplorer's internal HTML viewer. I can't recall the exact details, but the file:/// protocol still had issues in Chrome, Firefox, or both. Anyway, preparing a local address correctly with a keyboard is a challenge so let's just assume that having capable file managers running local html files is enough
Sure, to make this manageable, you need good tools that handle all sides of the task. But at least in theory, the format is fully capable. My only global issue was that the state for locally run HTML files is a kind of ephemeral entity, but for interactive multimedia files, you may consider this obstacle small.
[1] https://en.wikipedia.org/wiki/Data_URI_scheme
[2] https://github.com/gildas-lormeau/SingleFile
In essence you're describing epub, which is HTML, and I agree. It has great potential but nobody seems to see it as more than a cheap ebook format, and even that is underdeveloped in terms of capabilities: presentation quality and annotation are nowhere near PDF, for example.
Most of all it needs usable editors, and editors which integrate multimedia and dynamic content editing. End users can't turn to a different editor for each media and then integrate the output into the epub document, like a web developer does (e.g., for an image use Photoshop, save the jpg, copy to the proper directory, reference appropriately in the html).
I think HTML is exactly the "client-side multimedia file format" you want. I guess what we don't have is an established editor UI. You have to create it yourself.
It's if we had the .docx format but MS Word was read-only. You would have to create the XML and zip it yourself, to be then rendered by Word. That's effectively how I see HTML+js in browsers.
Yes, that's epub. See my other comment in this thread.
Even just allowing GIFs or videos to be embedded would be a value add.
Interactive and SVGs don't really mix, although intuitively it would seem that they do. Rendering remotely complex SVGs tale multiple seconds, while any kind of interactivity demands ~30+ frames per seconds.
Without interactivity, postscript is vector graphics too.
How complex are you talking about? I've done animations with hundreds of elements and it's fine.
A typical scene graph for a visually interesting 2D game has more than 5000 elements and works on a 15 year old computer without issues.
I'd be curious to know what classes as complex for you, since ive done some frankly crazy stuff with svg's, which outperformed any raster implementation. Ultimately, poor performance was always my fault, especially initially when i was still treating it with paradigms better suited to the world of raster graphics.
Downsides of using SVG:
- cannot wrap text
- cannot embed font glyphs - your SVG might be unreadable if the user doesn't have the font installed. You can convert letters to curves, but then you won't be able to select and edit text. It's such an obvious problem, yet nobody thought of it, how? Photoshop solved this long time ago - it saves both text and its rendering, so the text can always be rendered.
- browsers do not publish, which version and features they support
- may contain Javascript and references to external resources, which makes it difficult to view in a secure, isolated environment
One of solutions is having two SVGs: author version, which you edit in Inkscape and which uses Inkscape-specific extensions, and published version, which is generated from the first, that uses only basic features and has text converted to curves.
plenty of other problems
- They often render differently in different browsers and other renderers. It's very frustrating to get consistent results (like a PDF). In complex diagrams I'd say it's basically impossible
- Renderers that are fast usually lack many features
- Nobody other than the browser seems to actually have all the features?
- You can link an SVG within an SVG (to make a lightweight composite image). But if you have two levels of indirection then all renderers I've tried will refuse to render the SVG
- Inkscape is basically the only good editor on Linux and it easily runs out of memory and crashes for complex images
- Complex SVGs eat all your RAM in Chromium (only marginally better in Firefox)
- Basic things like arrows from Inkscape will not render anywhere else
I still use SVGs all the time, b/c there are no good alternatives, but it's a crappy standard and I try to keep all my images/diagrams extremely simple
> and has text converted to curves.
But this then loses the ability to select it as text—which, at least in Safari, is present with an SVG <text> element.
So either way you don't get full functionality.
Safari supports base64-embedding font files in a <style>’s @font-face {} (iirc it's something like `@font-face { src: url('data:application/x-font-woff;charset=utf-8;base64,...'); }`) that can then be referenced as normal throughout the SVG. I don't recommend this though, nobody wants to deal with 500KB SVGs.
The idea was that you can embed only the glyphs used in a text. For example, instead of embedding thousands of existing Chinese characters, embed only 20 of them. Embedding is necessary anyway because otherwise you cannot guarantee that your image will be displayed correctly on the other machine.
Also, allowing CSS inside SVG is not a great idea because the SVG renderer needs to include full CSS parser, and for example, will Inkscape work correctly when there is embedded CSS with base64 fonts? Not sure.
> Also, allowing CSS inside SVG is not a great idea because the SVG renderer needs to include full CSS parser, and for example, will Inkscape work correctly when there is embedded CSS with base64 fonts? Not sure.
For better or worse, CSS parsing and WOFF support are both mandatory in SVG 2.[0][1] Time will tell whether this makes it a dead spec!
[0] https://www.w3.org/TR/SVG2/styling.html#StylingUsingCSS
[1] https://www.w3.org/TR/SVG2/text.html#FontsGlyphs
That's how OpenCL died. They made difficult to implement features mandatory.
You can also point to font files with @font-face. I use a small custom font that's only 16 KB. Although, when opening the file locally, you have to first disable local file restrictions in safari's settings before it works...
So if you save the SVG image, it won't display without Internet connection. Not great.
I don't think that helps with embedding fonts.
> - cannot wrap text
This is possible, but only in the stupid way of using a `<foreignObject>` to embed HTML in your SVG (which obviously only works if your SVG renderer also supports at least a subset of HTML). SVG 2 fixes this by adding support for `inline-size`[0], so now UAs just need to… support that.
> - cannot embed font glyphs - your SVG might be unreadable if the user doesn't have the font installed. You can convert letters to curves, but then you won't be able to select and edit text. It's such an obvious problem, yet nobody thought of it, how?
Somebody did think of it. SVG 1.1 added the `<font>` element[1]; SVG 2.0 replaced this with mandatory WOFF support.[2] A WOFF is both subsettable and embeddable using a data URI, and is supported by all the browser UAs already, so it’s obvious why this was changed, but embeddable SVG fonts have existed for a long time (I don’t know why/how they got memory holed).
> - browsers do not publish, which version and features they support
It should be possible to use CSS `@supports` for most of this and hide/show parts of the SVG accordingly in most places.[3] The SVG spec itself includes its own mechanism for feature detection[4], but since it is for “capabilities within a user agent that go beyond the feature set defined in this specification”, it’s essentially worthless.
There are obvious unsolved problems with SVG text, but they are more subtle. For example, many things one might want to render with SVG (like graphs) make more sense with an origin at the bottom-left. This is trivial using a global transform `scaleY(-100%)`, except for text. There is no “baseline” transform origin, nor any CSS unit for the ascent or descent of the line box, nor any supported `vector-effect` keyword to make the transformation apply only to the position and not the rendering. So unless the text is all the same size, and/or you know the font metrics in advance and can hard-code the correct translations, it is impossible to do the trivial thing.
There are other issues in a similar vein where scaling control is just ludicrously inadequate. Would you like to have a shape with a pattern fill that dynamically resizes itself to fill the SVG, but doesn’t distort the pattern, like how HTML elements and CSS `background` work? Good luck! (It’s possible, but much like the situation with text wrapping, requires egregious hacks.)
Some of the new `vector-effect` keywords in SVG 2 seem like they could address at least some of this, but those are “at risk” features which are not supported by UAs and may still be dropped from the final SVG 2 spec.
[0] https://www.w3.org/TR/SVG2/text.html#InlineSizeProperty
[1] https://www.w3.org/TR/SVG11/fonts.html
[2] https://www.w3.org/TR/SVG2/changes.html#fonts
[3] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...
[4] https://www.w3.org/TR/SVG2/struct.html#ConditionalProcessing...
Interesting, I stumbled upon SVG fonts only as a format for webfonts in CSS.
Two years ago I re-vamped my "Spurious Correlations" side project, which is mostly just a bunch of charts. However, I couldn't find a charting software I liked that would display clean, simple visuals with the constraints I wanted. (I had used pCharts and HighCharts in the past, but didn't like charting in Javascript or PHP.)
I decided to "roll my own" and write Python scripts that outputted SVG markup. I was worried this would go about as well as every other "roll your own" project does, but was pleasantly surprised. It is surprisingly easy to output reliable, good-looking SVG graphics using Python. If you are making a chart, everything is just math.
The infinite scalability is almost just a happy upside to the simplicity of creating the visualizations, which is annoying in raster format. It made me like SVG even more.
If anyone is looking for a clean JS charting framework, I highly recommend Observable Plot.
It's from the creator of D3 and it's much easier than using raw D3. I've been using it outside the Observable platform for debug charts and notebooks, and I find its output crisp and its API very usable.
It doesn't try to have all the bells and whistles, and I'm not even sure if it has animations. But for the kind of charts you see in papers and notebooks I think it covers a lot.
It's a bit sad that Postscript never caught on as much as it could have. In an alternate timeline, it could have been the HTML (and SVG) we got in ours.
Postscript is still everywhere. Its just out of sight, being used as a compile target.
PDF may have "officially" replaced it, but it is still embedded almost everywhere you look.
PDF is a sad replacement for PS. As far as I can tell, it was an attempt to obscure PS, because alternative vendors were getting better as Postscript than the originators.
(There was some justification in terms of 'Oh, a binary format like PDF is more space efficient.' But PDF never really was more efficient than compressed PS.)
It's not that PS has vanished, but PS isn't nearly as 'everywhere' as HTML came to be.
From the perspective of someone who worked in printing and publishing starting in the 1980s, there's more to it than that. PostScript was and is terrific as a page description language and as a printer control language. It absolutely revolutionized the printing business. For the first time, you could get complete pages (as opposed to unpaginated galleys) out of high-end imagesetters.
But it was not all that good as a way to send documents to be printed elsewhere. Postscript files were in some ways too dependent on the printer they targeted, so the person creating the PS file had to know too much about the printer that would be used to print it: its resolution and optimal halftone screen frequencies, media sizes, etc. With high-resolution output on photographic film costing around $10 per foot, mistakes could be expensive as well as time-wasting.
Fonts could also be a problem. Ideally, the PS file would contain all the fonts it required but this did not fit very well with the terms of most font licenses. And some applications would include a copy of every font used once on each page on which it was used. This was in line with Adobe's recommended Document Structuring Conventions and had the advantage of making pages within the file independent of one another, but for documents with hundreds of pages, this could add up fast and make the PS file literally hundreds of times larger than if all the fonts were included just once. With small storage media and slow network links, this was a real problem.
The "P" in PDF is for portable, and these are the problems it solved. Unlike a PS file, a PDF file is not targeted for a specific printer model, and most font licenses allowed the licensee to include subsetted fonts in PDF files. I personally prepared PS files for a few thousand books to be printed at various places around the US and later, PDF files for thousands more. There is no comparison: PDF was and is better in every way for this purpose.
I agree that postscript was far from perfect.
However we can imagine a world where some relatively minor evolutions in PS would have moved it into the right trajectory.
(Thanks for all the historic details!)
PDF is also a lot less powerful, purposefully so. You can start an infinite loop just by double-clicking a PS file, for instance.
It is extremely useful to have a full programing language as a file format, though.
I miss macOS’s Preview.app auto-converting PS to PDF when double-clicked. It was a way to easily distribute a document that could randomize question orders each time it opened, print multiple bingo cards from a single file, etc.
The stack-based and reverse Polish notation thing was also fun.
You could have made a deliberately restricted subset of PS without going all binary.
Btw, doesn't PDF include Javascript these days? So you can still randomise stuff at view-time in a PDF. See https://th0mas.nl/2025/01/12/tetris-in-a-pdf/
Thanks for making that website. I used examples from it in the first day of my statistics course ("by the end of this course you won't make these kinds of mistakes").
Glad to hear it! The use in stats courses is the main reason I keep it alive.
> I was worried this would go about as well as every other "roll your own" project does
We as an industry need to get rid of this fear of creating stuff.
The first Distill publication[0] made tasteful use of minimal interactivity through JavaScript/d3.js[1] on top of SVGs. Many of the illustrations were initially drawn in GUI editors.
(Outstanding work by Shan Carter; it’s what I first saw of his style and it’s what made me want to join his team.)
[0] https://distill.pub/2016/augmented-rnns/ [1] https://github.com/distillpub/post--augmented-rnns/blob/mast...
Around 15 years ago, I built a barbecue controller. This controller had four temperature probes that could be used to check the temperature of the inner cooking chamber as well as various cuts of meat. It controlled servos that opened and closed vents and had a custom derived PID algorithm that could infer the delayed effects of oxygen to charcoal.
Anyway, of relevance to this thread is that the controller connected to the local wireless network and provided an embedded HTTP server with an SVG based web UI that would graph temperatures and provided actual knobs and dials so that the controller could be tweaked. SVG in the browser works nicely with Javascript.
This sounds awesome. Did you ever filmed it working?
Author here: I've just made a ninja edit of the post as it didn't really make clear a quite important point - the SVG is literally 20 years old, and still works, astonishingly. I'm not sure much else I wrote around the time would still work without some editing!
The reverse is kind of true: In the beginning, SVGs were not really an option since it lacked adoption across all major browsers, or more specifically its integration was very heterogenous.
So a SVG you authored 20 years ago for some browser will likely work everywhere today.
I really like SVG, I did a lot of things with it and some interesting ones. The only blame I have is that it is sometime slow.
Like for QR Code, precise maps or +100 pixels wide squares. More than 100 "DOM" elements and it will take multiple seconds to show.
The animations also are slow too, compared to canvas, plain CSS or Lottie but nothing very cursed, it's mostly fine.
I embedded a chess engine in SVG image of a chess board (https://github.com/jnykopp/svg-embedded-chess) so that the engine moved the pieces automatically and played against itself, just by viewing the SVG.
This was done for a friend of mine who made an art installation that projected like some 50x20 (can’t remember exactly) of these images in a grid on a wall, for perpetual chess madness.
The number of chess SVGs a laptop’s browser was able to run simultaneously did feel suprisingly low, but luckily it was enough for that particular piece of art.
Yeah; I've built a map viewer in SVG+JS for my small browser game, and it works quite well for that purpose, but when I tried to repurpose the underlying code for a different game, with a much higher object density, it became quite unmanageably slow. (I rebuilt the map for that game using canvas, but it does lose me some functionality.)
Ages ago, when doing the instructions for the opensource CNC Shapeoko v2 it became necessary (after the project was featured w/ a full page in _Popular Mechanics_ magazine to cater to users who could not visualize as well as the early adopters were able to, so the diagrams were made interactive:
https://github.com/shapeoko/Docs/blob/gh-pages/content/tPict...
Used to be if that was opened in a web browser one could click on the parts list to show/hide or highlight/unhighlight the matching items in the diagram.
Done using Inkscape if memory serves.
That looks cool!
My day job involves building dashboards, and SVGs have been invaluable for crisp icons and graphs... the portability across sizes is a blessing, but some of the more exotic filter effects still fail in certain browsers.
ALSO I've run into security reviews that flag inline SVGs because they can embed scripts... would love to see more tooling to lint and sanitize them before deployment.
BUT seeing a two-decade-old vector still render correctly gives me confidence that the core spec is solid.
> would love to see more tooling to lint and sanitize them before deployment
Sanitisation is one of two possible defences, the other being script execution controls or sandboxing. E.g., if you serve vector images on a web server, set a Content Security Policy header¹ for all your images that simply denies all scripting. You can also run it from a dummy domain ('origin') with nothing valuable on it (like how domains such as googleusercontent.com and githubusercontent.com are being used)
For sanitisation, DOMPurify² is the only widely used and tested library that I know of. It could use more bindings for other languages but, if you can call into it, it can go in your deployment pipeline. (Disclosure: I've worked with some of the people at Cure53, but not on this project)
You can also combine the approaches for defence in depth
¹ https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
² https://github.com/cure53/DOMPurify
> would love to see more tooling to lint and sanitize them before deployment
Did you see?:
https://github.com/cloudflare/svg-hush
what dashboard software do you recommend?
This was delightful. I would greatly enjoy seeing more use cases, as well as new editors, and new ways of working with SVG while keeping with it's capabilities and capacities.
Once I happened upon carto.net namely this: https://old.carto.net/papers/svg/samples/index.shtml#iact
I was absolutely sold on SVG.
now I find this: https://cartosvg.com/ which is mind blowing the capability and capacity, just the first example from link, really makes my day https://cartosvg.com/italia then the 2nd! It's compelling. I wish I could have built what i was trying to conceive building using OSC (Open Sound Control), but what i was setting out to do was ultimately brought into the world by Hexler's TouchOSC, i just wish somehow someone could have took VST to a unified front, and made it random controller populatable. impossible back then, yes. Today, different.
I once solved a machining problem using SVG and a bit of javascript and python.
I was prototyping an orrery. It involved cutting out a lot of ad-hoc gears and frame bits on my CNC out of a sheet of brass. It was relatively easy to generate the g-code for the individual parts using fusion360, but then it was a lot of faff to zero the machine such that it cut the part from a fresh part of the brass sheet without wasting too much metal in between the parts. It involved a lot of guesswork, and eyeballing. And even with that there was a lot of brass “wasted” between the parts especially since you could only move your part in x-y but not easily rotate it.
As a solution I wrote a python script which converted the g-code into svg, and a simple one page website where i could drag the svg around and rotate it on a visual representation of the sheet. Once i found a good safe spot for it to be cut the page told me the x,y, theta coordinates for it. And then with a separate python script i could transform the g-code using the coordinates and rotation. This way the svg renderer was doing the heavy lifting of visualising the cutting paths, and i only needed to concentrate on the relatively easy transforms.
>They are supported on just about every device and platform
Except they aren't. I recently used a simple SVG in a background and Safari wasn't able to render it properly so after trying lots of different things I gave up and used different sizes of raster images instead.
SVGs also are mostly unsupported for og:image tags (dependents on the app/browser). I know it's supper specific and I am not even sure if open graph is standardized protocol or not, but it's used everywhere.
What was the SVG that didn't work? In Jon's example in the original post, the SVG he embeds there was one he wrote in around 2005. That's a pretty impressive run for it to render 20 years on...
They are also not supported on iOS native apps. We use pdfs for vectors.
I love SVG! Recently I needed to render markdown in SVG and found no library existed for that yet so I released one:
github: https://github.com/davefowler/markdown-svg playground: https://markdown-svg-production.up.railway.app
I assume the goal is to get rid of all foreignObject uses eventually? (Otherwise it would be easier yo render one big foreignObject and convert everything to HTML)
Anyways, impressive, but what I’d really love to see is flexbox for SVG ;)
This feels a little bit like discovering frontend software development? I guess we're done with the trend of being scared of bundling features and running them in the browser close to the user with JavaScript.
I once built a music game that basically ran entirely on SVG. We hacked Musescore to attach the same UUID to both the note head in SVG and the MusicXML object in two different output modes, and then used that to synchronise the sheet music scrolling with a MIDI stream. If you're interested you can see it in action in our failed Kickstarter video from like eight years ago: https://www.youtube.com/watch?v=vgbB5Q4-dgY
I use ChatGPT to compress SVGs, in particular QR codes. Many QR code SVG generators produce inefficient SVGs, and conventional SVG compressors often lack the understanding required for some compression techniques. ChatGPT can replace alignment indicators with <use> elements.
Is there a way to embed the data encoded in the QR code directly within the image? This would allow the data to be parsed directly by the browser, eliminating the need for computer vision to decode it again. Going further, for web images QR codes could be efficiently encoded and rendered by the browser.
I am not sure about your use case. There exist many JS libraries which will generate client side QR codes. How many of them do you handle that you optimize for file size? Or is it just an academic interest?
SVGs are XML so technically, yes, you can just embed your visually encoded payload data with namespaces attributes and elements. If you don't want to use namespaces, you can use off-canvas texts, hidden/opacity=0 texts or even XML comments. You can even use the regular metadata section of SVGs. You can make the whole QR code within the SVG a clickable link.
> I use ChatGPT to compress SVGs, in particular QR codes
Why? svgomg.net exists, uses far fewer resources, and is going to give you much better results.
I notice one issue in SVG support in browsers that make it pretty unusable. When multiple polygons connect by edge, renderers alpha-blend their edges as if they are in general position, causing visible 'seam'. This is well-known problem in 2D graphics, usually handled by explicit selection of blending functions, but i cannot find anything about how to fix it in SVG.
I love working with SVGs.
We use SVGs on https://typequicker.com/press for the blog post hero images.
This way - even if the user changes themes, the colors of the image will be consistent with whatever theme is currently active. Also - the loading time is near-instant since we don't need to fetch the img file for the blog post image - just render the svg.
I remember an employee of mine, who was possibly the best engineer I ever knew, wrote up a specification document for his own vignetting algorithm, in Postscript.
The algorithm provided a 100X performance improvement over the classic Monte Carlo stuff that Tokyo had written.
The charts in the document were executable Postscript, running his algorithm.
That got the attention of the Ph.Ds in Tokyo. He was a high school-educated neurodivergent.
I recently found out that it is surprisingly hard to convert an SVG file that consists of series of line segments into a list of those line segments in Python.
I tried with ChatGPT and Claude but both were not able to find a solution that respects the entire specification, especially transforms.
Initially, my expectation was that there must be a library for this kind of thing, but alas.
Not sure about python, but https://docs.rs/usvg in Rust is pretty good
I seem to remember that the DOM nodes themselves expose some pretty useful functions. I think it was in the context of detecting edge crossings for a graph router, but you were able to interact with the computed/rendered coordinates in this context.
Sorry that's not more useful and explicit, it was a while back and never went anywhere.
I find svg.path to be good for parsing path data
For actually parsing the file, there are a number of options (in the end, it's an XML file and I tend to treat it as such)Can't you do it by hand pretty easily? It's a list of coordinates separated by spaces. For example: "100,100 100,200 200,200 200,100"
I mean - it's XML so you could go that way and extract the d element from path element?
But there seems to be a lot of SVG specific tooling and code to do this in python?
Eg: https://github.com/RaubCamaioni/svgpath
I love seeing old formats hold up this well. SVG surviving 20 years of browser evolution is a pretty strong argument for “boring tech” done right. It makes me wonder why we don’t see more research papers ship with fully self-contained interactive SVGs today — the tooling and browser performance are better than ever.
Is there a 3D equivalent (technical or spiritual) of SVG? I've been working on a CAD visualizer, and I'm looking for something lightweight that I can use to build up representative changes to cad models without having to do a full loop through the CAD application, pull a full .step export, and visualize that.
SVGs will work nicely for showing 2d sketches, but I'm hoping for something similar for the models themselves, without the slowdown of having to use the underlying CAD software for visualization.
SVG's are so fun! The amount of logic you can put into an SVG is absolutely wild given what they're generally used for. My desktop wallpaper uses embedded JS to create a random Barnsley fern fractal every time the system starts, so it's different every time. The only problem is that only browsers have the full SVG spec support I needed to get it to work correctly, but that's nothing that systemd and puppeteer can't fix.
all we need is keyboard input and audio output and we have (most of) flash back. I may have to look into this in my idle hours
The magic here is happening via the <script> tags, where you have access to the browser APIs like you would an <canvas> instead of <svg>. E.g. here's a sample I forked following the mouse using <svg> with <script> inside https://codepen.io/zamadatix/pen/emZXZKx?css-preprocessor=sc...
Libraries like three.js had SVG rendering as an option but it got deprecated as <canvas> with more direct GPU APIs was a lot more efficient and flexible.
JavaScript to catch keypress events and edit the SVG in situ maybe?
I believe SVG is not accessible for visually impaired. Not sure what is the current status tho.
Still, the one-SVG-to-have-it-all might be an overkill for a web page. Both semantically and syntactically...
I still wonder why PDF remains so prevalent and why it can't just be a single SVG file for each page of the PDF.
There are many things that are missing with SVG. For example, putting all the pages in a single file, encryption, forms, etc.
Also note that different browsers might render and print the same SVG differently, which is not ideal for a print-oriented format.
A few years ago I learned just enough d3 to show an interactive 2D lollipop graph. Later I learned just enough SVG to get a small diagram out for a college class. I think going back if I were to redo that first interactive graph I'd probably just do it in raw SVG.
I have been pushing SVG hard for a decade now, but to be honest AVIF is magic. It even crushes SVG file sizes.
> A completely self-contained SVG file can either fetch data from a versioned repository or embed the data directly
But can it read email? https://www.laws-of-software.com/laws/zawinski/
> vector graphics in a simple XML format.
Simple? No. SVGs are not simple. If they were simple they weren't so capable.
I remember making an .svg spirit thermometer that polled our local weather station and scaled the red bar accordingly some 12 years ago. A nice gimmick but I didn't see any real use for it. We joked about making a single-image SCADA monitor screen.
Can't edit the previous message anymore, but I just vibecoded a functional replica while waiting for a pipeline to run: https://prkele.prk.tky.fi/~anilakar/thermo.svg
This is going to really transform some data visualization things I've been thinking about. I've always loved SVG since working with Illustrator and Inkscape back in the day, but I didn't realize how much it could tie in with the modern web and interactivity. Thank you!
SVG has been transforming web-experiences (particularly for viz) for quite some time now, see:
- https://mlu-explain.github.io/neural-networks/
- https://www.nytimes.com/spotlight/graphics
- https://pudding.cool/
Surely D3 is what you're referring to
"SVG Considered Harmful"
https://www.cloudflare.com/cloudforce-one/research/svgs-the-...
First off, what kind of SVG reader does cloudflare assume to just open SVGs and Willy nilly run contained js? Is that a windows os feature? Second, do they not know about Content Security Policies?
And as a side note: Cloudflare itself is considered harmful
"Since SVGs are essentially code, they can embed JavaScript"
Odd thing to say. Everything on a computer is "essentially code", executable or not.
I believe that would result in non accessible content, I believe screen readers cannot properly assist impaired users with SVG content.
As such I think it's not a good idea for a document that should have a large audience.
Is there any appropriate solution for complex interactive charts and graphs?
Good question. In general charts are not accessible because visually impaired users cannot use a mouse.
You would need an interacting charting library that works with a keyboard and that is readable by a screen reader.
Here's a fun older thread on a similar topic - SVG is Turing Complete:
https://news.ycombinator.com/item?id=20980837
An SVG and JS, right? It's not interactive on its own.
The JS is embedded within the SVG file and not exposed outside it
The JS is exposed in the full page's context the same as if you included a <script> under a <div> instead of <svg>. In much the same way, whether the <script> is before or after the <svg> tag doesn't matter - it's just a script working on a single DOM (with different namespaces for certain elements) either way.
I guess the point is you can give a single .svg file with the js inside. But you can also give a single .html with svg and js inside.
Sort of... the SVG is referencing `svgscript.js` which is being fetched from the server (https://jon.recoil.org/blog/2025/12/svgscript.js)
heck yeah. bring back the hype over SVGs. the amount of things you can do has always amazed me. just using SVG filters, interactions, accessibility...
I hate that slack doesn't support svg. So we end up taking screenshots of svg flame graphs when discussing things.
Have you created an issue/suggestion?
I believe Slack is an electron app so it might be easy to implement.
I just went down the same rabbit hole, it is totally fun! https://turbek.com/Designing-Interactive-SVGs-with-AI/
TLDR:
- SVG image files: powerful like HTML
- Supported widely in browsers
- Designer tools make SVGs
- SVGs are written in a language
- LLMs are great at manipulating language
- Designers can collaborate interaction into life
I don't think LLM's are that great at manipulating SVG unless you mean like small edits like rotation and font size. Cool article though, I'll have to think how I can leverage it.
Of course, but in comparison to bitmap tools like midjourney, you can communicate with an AI by specifying a SVG element to be manipulated. "Rotate ID "logo" 30 degrees" is very legible to the AI
[dead]