SVG Essentials: https://www.oreilly.com/library/view/svg-essentials-2nd/9781...
SVG Text Layout: https://www.oreilly.com/library/view/svg-text-layout/9781491...
The fact there’s a book on just text layout helped me learn how much depth there is in SVG.
The major browsers have no issues with this, though note that some tools like Inkscape won't parse the DTD nor expand the entities.
[0] https://kingbird.myphotos.cc/packing/squares_in_squares.html
I wonder why SVG's original designers found it necessary to supply an ad-hoc re-implementation of the entity mechanism. I think it might have to do with how rendering properties can be overridden at the usage site? At least I don't think it was established that browsers ignore entity definitions or basically anything in the document prolog/DOCTYPE considering SVG was part of W3C's push to replace HTML's SGMLish legacy syntax with XHTML/XML.
If I recall correctly, the primary motivation behind <symbol> and <use> was interoperability with corresponding primitives in Adobe Illustrator.
To be clear, it's using both of them for different purposes, you'll find both <use> elements and <!ENTITY> declarations in files like https://kingbird.myphotos.cc/packing/square-11.svg. You can't <use> a numeric quantity in an attribute, the closest alternative for those would be CSS variables.
As for the existence of <use>, I agree with jarek-foksa, the idea is that the original element and all its clones from <use> are linked in the DOM at runtime, as opposed to DTD entities which are baked in textually. Also, most people hate XML, I'd imagine they'd hate internal DTDs doubly so, especially with how little information can be found about them outside the XML standard.
(Browser devs also love to beat the drum of minimizing attack surface, so it's a bit surprising that DTDs and XML stylesheets still work at all. I'd expect them to tear out that functionality in a heartbeat if it were ever used in a modern exploit.)
https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/E...
That file was able to lock up or crash most SVG renderers back then.
E.g. Billion laughs attack https://en.wikipedia.org/wiki/Billion_laughs_attack
The frontend would basically call an API that would return an SVG image with the right colour assigned and the animation done by hiding and showing svg elements.
You can see an example here: https://web.archive.org/web/20221020133516im_/https://uncrow...
Now, take SVG, it has potential to do everything what SWF could. But there is no editor like Flash and scene/object based coding solution like ActionScript. And each browser has own quirks so only simple SVG is guaranteed to be displayed everywhere.
Comparing SVG to Flash seems like an apples to oranges comparison anyway. The format does not have to do everything that Flash did but can rely on the other technologies in the browser.
The problem is that each of these apps can be quite bloated and in the tens of MBs range not the usual single digit MB.
Especially if you know how easy it can be to accidentally do something that works fine in other browsers but makes Safari kill the tab.
Doesn't actually brick the device but a fairly hard failure in the browser.
Oh - it's an Axidraw, from Evil Mad Scientist Labs - great device, wonderful people.
I've been doing that sort of thing in:
