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.

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.)

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.

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.

[1] https://www.cocos.com/en/cocos2d-x

[2] https://godotengine.org/

[3] https://pixijs.com/

[4] https://phaser.io/

Also of interest for me would be whether SVG description markup gets picked up in the index.

To complete the search of possibilities, having the SVG generated by Javascript on page load would be of interest, for example, with some JSON object of data that then gets parsed to plot some SVG images.

Your SVG graphs are very neat and nobody caring is a feature not a bug. If they were blurry PNGs then people might notice but nobody notices 'perfection', just defects.

I noticed you were using 'NASA numbers' in your SVGs. Six decimal places for each point on a path is a level of precision that you can cut down with SVGOMG or using the export features from Inkscape. I like to go for integers when possible in SVG.

The thing with SVG is that the levels of optimisation go on forever. For example, I would set the viewbox coordinates so that (0, 0) is where the graph starts. Nobody would ever notice or care about that, but it would be something I would have to do.