That's the kind of thing you do not for the users but because of your own standards, and even if no one else appreciates it, you always do.

Another thing to watch out for with SVGs is how they appear in RSS readers or browser reader views. If you're using external SVG files then it should be fine. If you've optimized them by embedding into the HTML, then you need to be careful. If they rely on CSS rules in the page's CSS then it's not going to work well. For my website I try to make the SVGs self-sufficient by setting the viewBox, width, and height attributes, using a web safe font, and only relying on internal styles. You can still get some measure of light/dark mode support by setting fill or stroke to currentColor.

To complete the test, the website needs an HTML page that is mostly SVG. I think that might stand a chance of getting into the main search results rather than just the image search.

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.

> 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 used to make a lot of charts with R/ggplot and the big disadvantage is, as you mentioned, the sizing of elements, especially text. So I wrote a small function that would output the chart in different sizes and a tiny bit of JS to switch between them at different breakpoints. It worked pretty well I think, the text was legible on all devices, though I still had to check that it looks fine and elements aren't suddenly overlapping or anything.

Another advantage of SVGs is that they can have some interactivity. You can add tooltips, hovers, animation and more. I used ggiraph for that: https://ardata.fr/ggiraph-book/intro.html

It does come up in normal results for me, I don't need to go to the images section, the page has keyword for testing lmtbk4mh, see result https://www.google.com/search?q=lmtbk4mh

Chartist is an amazing JS include that is tiny (10kb), that makes it super simple to create beautiful SVG charts.

It’s way undervalued and rarely gets updates.

https://gionkunz.github.io/chartist-js/

What are you using to produce the graphs?

I wrote a small graphing library for mine [1], but it has limitations.

[1] https://coffeespace.org.uk/projects/sound-source-delta.html

I love damninteresting. Thanks for keeping it going for the last two decades.

The hamburger button animation is so buttery smooth

> will render notably different in different browsers (and renderers like Batik/Inkscape/SalamanderSVG/etc).

I've run into this too, but only with SVG filters, not with basic elements like text, although you do have to make sure that the correct fonts are always available.

> tooltips in SVG don't work when the SVG is in an HTML page.

They work just fine when the SVG is actually in the HTML. What you're likely talking about is SVG that is referenced by an <img> tag. The latter means that the browser treats it as an image, so yeah, it doesn't have tooltips. Try putting the SVG directly into the HTML.

> Some mildly complex SVGs take GBs of RAM and 1> min to render.

I have never encountered that in my 10+ years of using SVG.

If you want that 2000s feel for your own sites: Gradient background, drop shadows, and side bar nav.

It's from 2007: https://web.archive.org/web/20070730042618/http://svg.nicubu...

The reference to Firefox 3.0 probably helps with the vintage feel.

I wasn't even able to copy the text that was intended for search engines, so I guess it is not accessible

> found that in Firefox performance started to degrade beyond a few thousand elements

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

See svija.com/en — all SVG websites ;-)

If this is the goal, a PDF website could be even better.

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.

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.

My experience in a chromium-based browser was multiline text selection was not good.

Any time you drag over space between lines, it selects something else.

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.

Selectable and more importantly searchable text is one of the reasons why I occasionally open Large SVG diagrams in browser instead of the usual image viewer.

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.

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.

I wonder if you copying the term here in HN (with the link to that site) would pollute the benchmark dataset…

There's symmetry at this moment in the results from Brave Search and Google Search looking for lmtbk4mh.

When searching for it on DuckDuckGo, the search engine found your comment via a HN frontend while not finding the original site.

[dead]

Flash did not disappear because of an unfortunate accident. It disappeared because Adobe was unwilling to fix its outdated system and rampant security flaws.

For the web you can now use Cocos2d-x[1], Godot Engine[2], PixiJS[3], and/or Phaser[4].

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

[2] https://godotengine.org/

[3] https://pixijs.com/

[4] https://phaser.io/

I did wonder why they didn't just switch out actionscript for js and use plain html/svg/canvas. I'm kind of glad they didn't but I think there would have been money in doing so.

Why we would do that when canvas related apis support gpu acceleration?

No.

SVG is a proper part of the browser. You get native text rendering, real links, real text selection, stuff like that.

Flutter is pure-canvas. You get no accessibility (unless you duplicate everything, in which case why even bother?), fake links which don’t behave properly, incorrect text rendering, megabytes of overhead, slow startup, &c.

Though Stylus Labs’ site is not pure SVG, but a collection of SVGs embedded in an HTML container, which makes life quite a bit easier (applying a page background and embedding a video iframe are easier, and proper sizing and centring the column is not otherwise possible without scripting).

awful readibility tbh, and not accessible at all I guess

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.

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.

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.

Now right click it and view source. SVG is just markup, same as HTML.