Svgs are capable of anything. You can draw anything with it as it’s just a format for vector graphics. The vectors can be manipulated so you can even make a 3D game engine from it if you wanted.
The only thing that separates it from html and css is that html and css biases towards website styled stuff. HTML is designed for text boxes and that kind of stuff while svgs bias more towards a neutral drawing medium: shapes and vectors.
So because it’s more neutral you can even make a html engine from svg if you so wanted.
Yeah this is a big part of the reason SVGs are dangerous if treated like normal image files. They are basically equivalent to HTML w/ embedded CSS and can even execute javascript.
If you aren't careful they can be used for XSS and all kinds of nasty stuff.
They are also super useful in general though despite that.
There were some tools that let you do a lot of flash-type things using html5 and svg. I used Tumult Hype for an animation project a few years ago, but I don't think it ever became as popular as Flash.
I do not observe any performance problem in Firefox (Nightly, Linux/Sway), and I’d say text selection is very good, with these caveats:
• Caret mode (F7) doesn’t work at all.
• Triple click selects all the text on the page, rather than just that of a single <text> element as I’d have expected (in which model you’d use <text> for a paragraph and <tspan> for its lines, and thus get the normal triple-click behaviour).
• Click and drag on a text link starts selection or drags the already-selected text, rather than dragging the link so you can drop it in a new tab or such. And if you mouse up on the same link (regardless of having left it), it activates.
• If you start a selection, it is only updated while you’re moving over text. Drag past the end of the line, then down, and it should select more text, but it only actually will when you move back over text.
• If text is selected, clicking outside text doesn’t clear the selection. (Probably the same root cause.)
• Shift+Up and Shift+Down select to the start or end of the containing <text> element, rather than operating linewise. (Because there’s no such thing logically, it’d require heuristic work. Or for people to implement flowed text, like Inkscape did but sadly then it was pulled out of the spec for some reason.)
There are also a couple of issues specific to this document:
• Document order is not sensible. For example, it goes title, then side nav title, then footer, then body text, then “Home”, then side nav contents, then magic keyword. But this does show a broader problem: in HTML it’s not the easiest to get stupid document ordering (possible, but you have to go a little out of your way), but in SVG it will happen unless you’re careful.
• Also likely to happen unless you’re careful: multiline text sometimes lacks the trailing spaces necessary to separate words once the line break is ignored (since there’s no such thing as a line break in SVG 1.1, only a shifted cursor position). For example, “Inkscapefor” fails, whereas “willing to” succeeds.
—⁂—
Chromium is interesting. Supports caret browsing (+), Up/Down do something weird (−), triple click only selects that <text> element (+), you can’t start a text selection in a link (±), but you can’t drag the link either (=), and while selecting, any time the pointer is not over text, it’ll shift that selection boundary to something like the start of the document (−), except it’s not actually the start because it excludes the title text for some reason.
The search term lmtbk4mh is found with Brave Search (3 hits so far, but it cannot provide a description of the SVG site). DuckDuckGo Search has zero results at this moment.
The page is old enough that it wouldn’t surprise me if Google and Bing used to index it and are capable of indexing it, but no longer do. A lot of older stuff where you know exactly what’s there just can’t be found any more.
Viewed it on iPhone in the passenger seat of my son’s 79 Thunderbird. Doesn’t reflow and is a disaster in portrait but I pinch zoomed it in landscape and it was readable.
I have used an LLM to write code in web servers to generate data plots using SVG embedded directly in web pages. This bypasses the need for PNG generation, Javascript for rendering a plot, and also the need for a plotting library. You can see two examples in the gist d29164051477ce1b2b95b788297a1932.
I have been using SVGs for charts on my blog for a couple of months[0] now. Using SVGs satisfied me, but in all honesty, I don't think anyone else cares. For completeness the benefits are below:
* The charts are never blurry
* The text in the chart is selectable and searchable
* The file size could be small compared to PNGs
* The charts can use a font set by a stylesheet
* The charts can have a builtin dark mode (not demonstrated on my blog)
Additionally as the OP shown, the text in SVG is indexed by google, but comes up in the image sections [1].
The downside was hours of fiddling with system fonts and webfonts and font settings in matplotlib. Also the sizing of the text in the chart and how it is displayed in your page is tightly coupled and requires some forethought.
I'm pretty confident it's intended to be read as a portmanteau for “instant satisfaction”. I appreciated the clever wordsmithery and wouldn't jump to the assumption that it shows any kind of lack or failing. But maybe that's just me.
A few years back I updated my site[1] so all of the UI graphics (e.g., logos, icons in the menus) are SVG sprites baked into the HTML. It resulted in a lot fewer requests per page, lower overall page size, and sharp navigation on any device at any resolution. It works great, though it was a lot of initial work to get it working.
One thing I love about SVGs for websites is their stability across many contexts, browsers, etc. Everything is pinpoint, coordinate based, nothing moves around unexpectedly. You define it once, it's done.
SVGs are under explored in generative AI. They are effectively a graphics language of their own. LLMs can write them directly without a vision architecture, and understand them in ways that non-vector graphics cannot.
Just serving a whole SVG file directly never even crossed my mind as an option, very cool.
A while back I used a giant interactive SVG as the UI for a site I was prototyping, albeit wrapped in a normal HTML page. It was easy to set up and worked reasonably well, but I found that in Firefox performance started to degrade beyond a few thousand elements and so converted everything (except some accessibility features) to use a canvas instead. (The core of the old version is still deployed here if you want to see how far you can push it: https://freeclimbs.org/wall/demo/edit-set )
I realize it's far from a best practice and even explicitly stated as a bad idea somewhere in the SVG spec, but the idea of a document editor where you can individually position each and every character and make detailed, individual glyphs natively without loading fonts is interesting to me.
Are there any examples of this? Or perhaps different (better) approaches to a document editor with the advantages I said above?
Even if I were to make a document editor in SVG, I would still use the <text> element with a font, rather than positioning every character separately or even rendering every letter as a path. That would be incredibly wasteful I think.
45 comments
[ 2.6 ms ] story [ 62.2 ms ] threadThe only thing that separates it from html and css is that html and css biases towards website styled stuff. HTML is designed for text boxes and that kind of stuff while svgs bias more towards a neutral drawing medium: shapes and vectors.
So because it’s more neutral you can even make a html engine from svg if you so wanted.
If you aren't careful they can be used for XSS and all kinds of nasty stuff.
They are also super useful in general though despite that.
Any time you drag over space between lines, it selects something else.
• Caret mode (F7) doesn’t work at all.
• Triple click selects all the text on the page, rather than just that of a single <text> element as I’d have expected (in which model you’d use <text> for a paragraph and <tspan> for its lines, and thus get the normal triple-click behaviour).
• Click and drag on a text link starts selection or drags the already-selected text, rather than dragging the link so you can drop it in a new tab or such. And if you mouse up on the same link (regardless of having left it), it activates.
• If you start a selection, it is only updated while you’re moving over text. Drag past the end of the line, then down, and it should select more text, but it only actually will when you move back over text.
• If text is selected, clicking outside text doesn’t clear the selection. (Probably the same root cause.)
• Shift+Up and Shift+Down select to the start or end of the containing <text> element, rather than operating linewise. (Because there’s no such thing logically, it’d require heuristic work. Or for people to implement flowed text, like Inkscape did but sadly then it was pulled out of the spec for some reason.)
There are also a couple of issues specific to this document:
• Document order is not sensible. For example, it goes title, then side nav title, then footer, then body text, then “Home”, then side nav contents, then magic keyword. But this does show a broader problem: in HTML it’s not the easiest to get stupid document ordering (possible, but you have to go a little out of your way), but in SVG it will happen unless you’re careful.
• Also likely to happen unless you’re careful: multiline text sometimes lacks the trailing spaces necessary to separate words once the line break is ignored (since there’s no such thing as a line break in SVG 1.1, only a shifted cursor position). For example, “Inkscapefor” fails, whereas “willing to” succeeds.
—⁂—
Chromium is interesting. Supports caret browsing (+), Up/Down do something weird (−), triple click only selects that <text> element (+), you can’t start a text selection in a link (±), but you can’t drag the link either (=), and while selecting, any time the pointer is not over text, it’ll shift that selection boundary to something like the start of the document (−), except it’s not actually the start because it excludes the title text for some reason.
https://www.google.com/search?q=svg.nicubunu.ro seems to surface it, with text; https://www.google.com/search?q=site:svg.nicubunu.ro gets the title, but no more text. I’m curious how it decided what the title was. I wonder if they have some kind of “choose the largest text” heuristic if a title is missing.
https://duckduckgo.com/?q=svg.nicubunu.ro and https://duckduckgo.com/?q=site:svg.nicubunu.ro don’t show a result.
It was so nice and unlocked so much creativity among early web developers. unfortunately Apple contributed to its demise
* The charts are never blurry
* The text in the chart is selectable and searchable
* The file size could be small compared to PNGs
* The charts can use a font set by a stylesheet
* The charts can have a builtin dark mode (not demonstrated on my blog)
Additionally as the OP shown, the text in SVG is indexed by google, but comes up in the image sections [1].
The downside was hours of fiddling with system fonts and webfonts and font settings in matplotlib. Also the sizing of the text in the chart and how it is displayed in your page is tightly coupled and requires some forethought.
[0] https://aleyan.com/blog/2025-llm-assistant-census
[1] https://www.google.com/search?q=%22slabiciunea+lui+Nicu+fore...
In-what? Unhappiness with a statistical outcome? Discouragement with events in one's home state?
Based on the many other uncorrected typos in the example SVG, I suspect that Inkscape has everything but a spell checker.
Apropos, Inkscape is a big app and does practically everything.
There are some very nice showcases at the bottom of the page. For example, 2021: https://2021.svija.love/
Previously featured on HN: https://news.ycombinator.com/item?id=33518845 [Show HN: All-SVG websites with complex animation]
[1] https://www.damninteresting.com
A while back I used a giant interactive SVG as the UI for a site I was prototyping, albeit wrapped in a normal HTML page. It was easy to set up and worked reasonably well, but I found that in Firefox performance started to degrade beyond a few thousand elements and so converted everything (except some accessibility features) to use a canvas instead. (The core of the old version is still deployed here if you want to see how far you can push it: https://freeclimbs.org/wall/demo/edit-set )
Strange, I've used SVG a lot and I've not seen that kind of performance problem except when overdoing it with the SVG filters (esp. gaussian blur).
They do get indexed by Google, and we take some extra steps to ensure usability.
I realize it's far from a best practice and even explicitly stated as a bad idea somewhere in the SVG spec, but the idea of a document editor where you can individually position each and every character and make detailed, individual glyphs natively without loading fonts is interesting to me.
Are there any examples of this? Or perhaps different (better) approaches to a document editor with the advantages I said above?