Nice things with SVG(fuma-nama.vercel.app) |
Nice things with SVG(fuma-nama.vercel.app) |
<svg
class="w-16 h-16 text-blue-500 transition-all duration-300 ease-in-out transform hover:scale-125 hover:rotate-12 hover:text-purple-600"
fill="currentColor"
viewBox="0 0 100 100"
xmlns="http://www.w3.org/2000/svg"
>
<circle cx="50" cy="50" r="40" />
</svg>
What fresh hell is this?
HTML attribute: height="20"
CSS property: height: 20px;
JS statement: element.style.height = "20px";
https://simonwillison.net/2024/Oct/25/pelicans-on-a-bicycle/
Oh boy oh boy oh boy
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.
Oh - it's an Axidraw, from Evil Mad Scientist Labs - great device, wonderful people.
I've been doing that sort of thing in:
That landing page is a nauseatingly laggy experience on a very powerful M1 Pro laptop. And slow to load, all for some fancy lines? I'd take a product that focuses on substance over style as dev. Don't get me wrong, style is important and I like pretty things, but here it seems the tradeoff is not well done.
Apple's M series chips aren't really all that powerful, but they are very power efficient. There are far faster laptops out there than what Apple offers, though they do consume more power. My AMD-based laptop outperforms the M1 Pro by a wide margin, though it is a power hog. I had no problem viewing the Unkey website. If you're using Safari, that may also be a problem, because Safari honestly sucks.
> Apple's M series chips aren't really all that powerful, but they are very power efficient.
In terms of single threaded performance, they are both. Especially the IPC is very impressive take a look at for example https://github.com/Voultapher/sort-research-rs/blob/main/wri...
> Assuming the same instructions per cycle (IPC) and mapping of instructions to cycles, Zen 3 should be ~1.53x faster than Firestorm by virtue of clock frequency. Yet the micro-architecture released in the same year as Zen 3, goes from exceeding it to closely trailing it in terms of absolute throughput when the effects of branch misprediction are minimized.
Their newest generation of P-cores is simply unmatched in terms of ST perf, an M4 core can do 4k points in Geekbench ST, AMD's best Desktop offering does ~3.5k at a much higher clock frequency. For web browsing ST perf is king.
For as long as SVG's been around its potential feels untapped. I can't think of any other element that can encapsulate functional HTML, CSS and JS -- basically an entirely different HTML document -- as easily
Sun Clock: https://sunclock.net
Degrees What?: https://degreeswhat.com
I was feeling great but now I think "I have a lot to learn — I'd better get going!"
If you are interested in SVG animation, I wrote a program to do it from within Adobe Illustrator — see examples and how it works at https://svija.com/en/animation
I also made a game called Pro Office Calculator (available on Steam), which includes a Doom-style 3D engine for which I used Inkscape as my map editor. Here’s an example of a map: https://github.com/robjinman/pro_office_calc/blob/develop/da...
That said, most of this is probably better done with CSS today.
My only professional exposure to SVG was when a pen tester found my predecessor's code had unintentionally allowed them, and that one can do injection attacks from the SVG itself. Of course this was around the time a client discovered SVG worked for them, so I had to make support official and defeat injection attacks. Good times.
I wonder if anybody has recreated vector graphics games like Asteroids using SVGs and animation. You'd have to use JS to change the shape and direction of the asteroids when they're shot, but that would just require a bit of JS.
https://youtube.com/watch?v=wc8ovZZ78SY
I discovered this shortly after introducing The Secret of Kells to a child and had terrible, beautiful ideas about overly ornate websites that I have since thought better of. Mostly.
And the oft overlooked synergy with aria work is test automation. Code that is hard to screen read is often also difficult to integration or E2E test accurately.
- Complex graphics render different in different browsers. So you can't rely on it shows up the same (never had the same issue with a PDF for example)
- There are quite a few renderers but they typically don't implement large parts of SVG b/c it's too complex.. So you can never really be sure what parts are "safe" to use.
- Large complex graphics display extremely slowly (again, compared to a PDF)
- There is basically one editor.. Inkscape. And it's got it's own quirks and doesn't match Chrome/Firefox's behavior. Ex: You can add arrows to lines in Inkscape and they don't display in Firefox
It's also just got too many weird corner case limitations. For instance you can embed a SVG in another SVG (say to make a composite diagram). But you can't embed a SVG in to an SVG in to an SVG. On the web if you inline or link an SVG you also end up with different behaviors
Do you mean in terms of open source vector editors? As there a wide variety of tools with SVG authoring/editing capability, among the most well-known being Adobe Illustrator, Sketch, Affinity Photo/Designer, even some web apps are available that were made for online SVG editing (eg: SVGator).
Inkscape, like some tools such as Affinity's, adds its own XML namespace with custom attributes and values, though for arrows I would expect it to use native `marker` elements.
It's certainly true that with SVG's flexibility and particularly with cross-browser handling differences/bugs it can become its own task to get consistent presentation when doing more complex things with it. Still very fond of the format.
- adding toolpath information so as to use Flash as the engine for a Computer Aided Manufacturing tool: https://github.com/Jack000/PartKAM
- (this was my project along w/ Edward R. Ford) adding hyperlinks to part lists to highlight parts in an assembly diagram: https://github.com/shapeoko/Docs --- unfortunately, that doesn't seem to work anymore.
without groups and layers
SVGator is focused primarily on animation and it's rather pricey. Boxy SVG might be a better choice if you are looking for a web-based SVG editor (disclaimer: I'm the developer).
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.
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.