One of funnest projects I worked on at Corel was called "Smart Graphics Studio" (I'm guessing most of the people who worked on it also read HN, so "Hi!"). It was an absolutely stupid idea: Some insane PGM read that XSLT could transform any XML into any other XML. Then they read that SVG was XML. They put 2 and 2 together and got a billion: You could draw a picture in SVG and then modify it intelligently (through XSLT) using some XML data set.
Of course the opposite is actually a brilliant idea (at least at a time when XML was still popular): Take an XML dataset and visualise it in SVG using XSLT transformations (well... yeah... doing it all in XSLT is still insane, but you get the idea).
Anyway, we built a very high performance SVG viewer (for the time, anyway) from scratch. We built an SVG/Javascript widget library. We built an incredibly impressive data manipulation library in XSLT (ok... yeah... insane).
Fun times. And all nearly 20 years ago. It really was ahead of its time. Of course the end finally had to come. The PGMs sold this thing to a certain aviation company with the promise that it would automatically build circuit diagrams from their XML chipset database (because.... XSLT!)
When Vector took over Corel, they very rightly dropped our division like a hot potato (we had something like 3 PGMs per developer). It was quite unfortunate because the developers and QA people I worked with there were some of the best I've every had the pleasure of working with. I've always waited for something to come of SVG and really wish we had been able to release something that wasn't crazy so that people could see what the potential was.
Edit: In my old age I'm losing track of time. It seems that Vector acquired Corel in 2003, so that's only 15 years ago :-)
It's such a shame that XSLT has such a poor image - v1.0 was troublesome for sure, but the modern language is remarkably flexible, expressive and elegant, as long as you leave your procedural baggage at the door.
It's not without its wobbly bits, but show me a language that isn't.
I should probably admit that I really like XSLT (perhaps I'm insane too), but it was really unsuited to the task we were using it for. I've since done quite a bit of XSLT and it's definitely the main tool I'd use if I wanted to screen scrape some HTML, for instance. But can you imagine someone saying "We want you to draw paths between points and they can't cross. And we want you to do it in XSLT"? I mean, you can do it... but... "not fun" doesn't begin to describe the pain.
SOAP, RDF and the semantic web clique, and other monstruosities of the 2000s gave XML a bad name but XSLT is nice. Indeed it would have been a nicer solution than responsive css to tackle the challenges of mobile devices.
I've done quite extensive XSLT development and like it for particular tasks, but I think XSLT's weak points are
1. It's Turing-complete, which means you can just use any other language for XML manipulation as well such as JavaScript (has DOM language bindings) or Prolog (rule/pattern based like XSLT) or maybe LISP (like DSSSL was). The benefit is that using a mainstream language gives you better mindshare and infrastructure such as APIs for DB access, IDE support for testing, etc. which I found inevitably necessary in every large XSLT project
2. XSLT 2 and 3 only has a single implementation (Saxon) by the same author as the XSLT spec itself - not my idea of a standard (and, in fact, not meeting W3C's criteria of at least two interoperable implementations).
XSLT works well if you need lots of literal XML content to be produced to the output, but will get verbose, degenerative, and awkward (priority rules) for highly dynamic content.
Amen. And while we're at it, let's throw some of the credit to XPath. Wouldn't you like concise, declarative traversal for your data structures? (Yeah, I'm sure somebody's already built it.)
I don't think I agree about responsive css, but that's another discussion.
I ended up writing a full compiler stack in XSLT for declarative, XML-based DSLs[0][1] and a few targets (mainly JavaScript and HTML). It didn't start out as that, but having already written basic HTML/JS generation from a simple DSL, it evolved from there.
It was originally written in XSLT 1.0 so that it could generate in the web browser, which had some serious limitations and was incredibly verbose. XSLT 2 is much less verbose, but obviously XML is verbose in general.
If I had to do it over, I'd use Lisp, but the functional and template-based style of XSLT made for very natural syntax-directed translation for the compilers. I still have the cruft of old XSLT 1 code (which was written when I was also _learning_ XSLT), but all things considered, it's not all that bad. Most of the pain points are the patchwork evolution of the project; done from scratch in XSLT, it'd be much more elegant.
And, like Lisp, XSLT can parse itself as data (sans xpath). That allowed me to use a semi-literate style (generate literate documentation from the sources), for example.
Project Manager - Writes specs and documentation for individual features.
Product Manager - Figures out what new features or changes the product needs to better fit or find a new audience. Usually responsible for doing market research and analysis.
Business Product Owner - Similar to product manager, they own all changes associated with a company product. Position should only exist if product is so large, multiple product managers are needed for it. The product managers would then need to report to or clear their work past this individual.
Program Manager - Everyone above reports to this person. They own all of the products. And possibly oversee development as well.
Yeah, sorry. It's terribly unclear :-) Basically there is a kind of markup called XML. You can define arbitrary hierarchies with it. It's very similar in shape to HTML (and at one point there was a big push to make HTML a subset of XML, but it failed). SVG is a graphics format that is defined in XML.
XSLT is a programming language. It's not the usual kind of programming language where you tell the computer what to do. Instead it's a bit like a pattern matcher. If you have X kind of pattern, then do Y action. It's difficult to do procedural kinds of things with it, but it is awesome for transforming one kind of data to another kind of data. It reads XML files natively and you can output any kind of data you want (although usually you output XML).
We had a strange team which was heavy in "idea people". These people had the title "program manager" (or something similar). The idea was that they would have ideas and tell the programmers what to build. In practice, they had pretty crappy ideas and then we had to find a way to make them not crappy.
None of the program managers understood technology very well, but they latched on to ideas with a certain tenacity. One of these people found out that XSLT could transform XML. He also heard that SVG was written in XML. Finally, he also knew that there were many databases (at the time) that stored the data in XML. So he thought that it would be easy (in fact, automatic) to use XSLT to transform the data in an XML database to SVG.
The idea was to draw a picture using Corel Draw and save it as SVG. Then you would alter the picture using the data in the database using the magic of XSLT. Unfortunately he did not understand that XSLT was a programming language, and no amount of explanation would illuminate the situation. He was absolutely sure that if we added XSLT to our software then it would automatically alter SVG images in an intelligent way.
We had to take that idea and make a viable product. What we did was to make an IDE that allowed you to connect portions of an SVG diagram to data in a database. You used snippets of XSLT to transform the data in the database to transformations in the SVG diagram. On top of that, we built a GUI API that would give you a full interactive experiences using SVG rather than HTML (so you could build entire apps in SVG and hook it up to live data in a database). It was actually pretty awesome (and I take no credit for that -- we had awesome people on the team).
Unfortunately the "magic pixie dust" of XSLT was do heady a draw for the program managers and they got it into their head that you could automatically route circuit board diagrams if you had an XML database of electronic parts. This was a terminal mistake (and we warned them many, many, many times that it was impossible).
At the time of the takeover (Corel was bought by a venture capital company called Vector), we were treading water and trying not to drown. They mercifully terminated us, but unfortunately buried a pretty wonderful suite of software.
Great times indeed. I did map-rendering and later (limited) map editing with SVG, XSLT and python 15 years ago. I even had something that resembled AJAX/REST in my stack, but that was not named in that way back then. I really learned a lot, even if some of it was as crazy as your thing.
Or, for the slightly more insane approach we (and by that I mean people in my organisation prior to my arrival) decided that XSLT was the right tool to transform XML to Python. XML to XML sounds like a walk in the park after that. :)
This showcases what's wrong with SVG: It does way too much!
To be useful as a vector image format, there should be strict rules (and less cruft). Why is there no libsvg like libjpeg or libpng? Why have interaction as part of an image format?
SVG lives in an uncanny valley between jpeg and flash/js.
I think there is still a big need for a real vector interchange and display format. Right now people pick a "good" subset of SVG. Or even fallback to fonts.
My dream vector format:
- Pixel perfect across implementations at 50%,100%,200% renderings. At least grid aligned lines.
- Lossless roundtrip across apps. Start in Illustrator, edit parts in Inkscape, other parts in Animate, untouched things stay exactly the same.
- Standard zero dependency C reference implementation: Stream in, bitmap out.
This! I've started to look for usable vector image format for game development somewhere in 2004, now it's 2017 and there is still nothing available. For SVG you literally need to pull-in whole browser engine, which is most likely 2-3 times the size of your whole game.
One possible solution is to the same what XMPP did on XML, or JSON did on JavaScript: Define a "safe subset" of SVG, and stick to that. Perhaps use the "safe subset of XML" as a base (as defined e.g. in XMPP.)
Use a library (or at least a validator) that works exactly on this subset, and fails for anything not strictly conforming to this.
Of course, this is not as satisfying as a "clean slate" approach, but on the other hand, this is a clear migration path with backwards compatibility - which is always good to have during a transition period to avoid all those bootstrapping and chicken-egg issues.
I've found librsvg to be pretty good. It's used for exactly this purpose in Gnome. You stick a Cairo surface behind it and it translates the operations to that.
However, admittedly, I use it in combination with a full blown browser because it doesn't need/handle text completely. I like SVG, but I too have accepted that if I want stuff to render properly, the only place to find a usable and complete SVG engine is in a web browser.
It explicitly doesn't require that the engine do anything with the content of <script> tags, and CSS is explicitly unsupported - they simply use a small subset of properties from CSS as attributes.
But how to deal with things like line-wrapping, when fonts have unknown size? Somehow, it should be possible to programmatically determine how each line is broken up. A similar argument holds for hinting at low pixel sizes.
This means it is inevitable that SVG should be Turing-complete.
The files could get quite huge after that. Also one feature of svg (whether it is an advantage is for everyone to decide) is that it can render fonts as they are rendered in the other parts of OS. Which is why it can be seamlessly embedded.
also it does things weirdly and surprisingly - like right in the first codepen sample when she put width and height to be 100% of the viewport but the svg engine decided not to stretch it... ugh.
and that ignoring browser specific issues, for example svg and css filtering don't work on edge/ie11
but nice hacks I guess. the real takeaway are probably svg animations, those can make cool stuff without the keyframe weirdness.
It isn't perfect and it works inside of OpenFL but Haxe has a svg render in OpenFL that makes it much smaller in size to import and is more stream lined.
It's always been a curiosity of mine why SVG didn't get more attention from browsers through the years to solve the performance issues. It's open source, cross platform, "dynamic" in a sense AKA no compiling needed, light weight, supports shapes and text, offers immediate responsiveness, etc. Why the lack of love while we pour ever increasing energy into mangling HTML and CSS and every six months a new JS framework/module/whatever to try to make it work?
The problem with SVG 1.1 is, that it doesn't support text wrapping. Text wrapping came with SVG 1.2 Tiny years later, but this standard had been ignored at that time. Then came HTML5.
SVG support is a lot better now but it used to be horrible. A few years ago I wrote a simple game in SVG and it would be broken in almost all mobile browsers at the time.
I think GP was referring to the fact that you don't need to generate SVG assets at multiple sizes for size/picture clarity balance, as you do with popular raster formats.
SVG is the replacement for HTML when you're doing something graphical in nature, styling it with css and animating with js. I've always felt that there was a huge potential in SVG for building UI.
But GP's point is the opposite, that HTML/CSS/JS is being used too often for tasks that could be much more simply solved by SVG. I can think of a couple just in my current project.
That's exactly my point. It's seems the task now with Web UI is adapting to screen sizes and capabilities to build complex layouts of components that IMHO HTML/CSS is fundamentally not suited for. The leap from using SVG just for simple elements that scale to entire UIs that scale and shift their layouts doesn't seem to far fetched to me...Oracle, Google, Adobe, Microsoft all use(d) XML with a schema for their layout engines and yet the Web won't (cant?) While it has in its grasp an XML as well?
In brief, our product includes a web-based process flow component, typical nodes-and-edges kind of thing. Much better done with SVG IMHO, with first-class support for box & line modelling and styling. But the powers-that-be decreed we'd do it all in HTML & CSS.
Well, I'll happily agree that SVG is a perfect fit for data-driven graphics, but that represents are reasonably large set of solutions, so I'd not say "useless" at all.
SVG works so fantastically well with React -- it's just part of the DOM, after all. Unless there are performance concerns, that reason alone would make me choose it over Canvas every time.
Shameless plug, one of my first experiments with SVG+react (+cljs): https://polymeris.github.io/carlos/ Done in one day, without knowing the tech.
When I started learning React, I realised a dream of mine could finally come true: a proper Celtic Knotwork generator. Uses SVG and React together in harmony.
Pardon my ignorance, but aren't these patterns just composed of certain tiles in rows and columns? This is something you can do equally well with raster graphics, so what's the gain of using SVG here?
I tried that on an earlier version, but there's complications ;)
The "double corded" style paints one side of a cord red and the other blue. The problem comes when the pattern changes what side is which. You can play around with it to see - put in some breakpoints and you'll see the "sides" switch on some cells. This can't be done with tiles.
The tile manipulation is actually no simpler than drawing SVG, because the hard bit is calculating the entry and exit points for each tertiary cell. And SVG produces better results :)
I also plan on doing some more stuff with it someday - like deforming the grid by moving the corners. This is pretty simple with SVG but would be really hard with tiles.
Not yet - it's on github (the site runs off Github pages) but I need to prune the repo of private keys before I open-source it.
Given the reaction here, I'll try and open it over the weekend :)
Agreed. Going with SVG instead of something else to render the Jenkins pipeline graph has made our lives much easier when it comes time to make changes since we introduced it.
That's actually what got me into React as well - I was initially going to try my hands at a then-alpha of Angular 2, but it couldn't work with SVG. I then decided that React would be nice to try for a hobby project, and there we are: https://agripongit.vincenttunru.com/
We do exactly this (SVG + React) at Bleacher Report.
It’s basically the best of every world for us (visuals, code, etc) and we’re trying to convert as much as we can to this (takes a while... we have a LOT of logos for example)
> Unless there are performance concerns, that reason alone would make me choose it over Canvas every time.
I agree, but ironically am one of the few here with a use-case that seems to be in the canvas-is-always-better category, and performance reasons aren't even the only motivation (although that matters too).
I'm working on a data browser of huge data sets, and the plotted data needs to maximise the use of the limited available pixels to convey as much information as possible (see [0] for an example). At that point canvas is the more convenient option.
I would say not fantastically - it is part of the DOM, but it is 1. XML - so namespaces? 2. SVG has it's own DOM - it builds on an extends the HTML DOM but React only understands the HTML DOM.
Most of that is a problem in browsers already as well. While SVG works without problems in other XML languages due to namespaces, browsers run it through an HTML parser and certain things are simply required by that parser for no good reason, e.g. that the XLink namespace prefix must be xlink and otherwise it won't work.
Wow, this is cool. It looks like an API capable of things that Vector Magic[1] can do, but FOSS. Vector Magic has been excellent for some occasions where you have a rasterized clipart, but need it as a vector.
I love and use Inkscape exclusively for any SVG editing, but this particular feature in Inkscape is woefully under anything I've seen vector magic provides.
Edit: https://blogs.adobe.com/creativecloud/export-svg-animations-... exports SVG animations, but only, it seems, for special types of documents ("From here you simply create a new “Snap.svg Animator” document type and begin creating content s you would normally. Publishing your content then generates a boilerplate HTML file along with all the assets you need, giving you an example of how to embed your animation into a webpage.")
Inkscape is OK, but a little rough. Take a look at Affinity Designer. It is very polished and has a feature set approaching Adobe illustrator at a very reasonable price. It's also well supported by the publisher.
I've been using both recently. Affinity Designer has a much, much better interface but I keep finding features and options missing that make it frustrating for coding projects. You can't easily open an SVG file, edit it and quickly save to the same SVG file without going through several clicks and setting options to export ("save" will save in a proprietary format). There isn't a command line interface for exporting either. I can't see a way to edit the SVG XML either (you can do that in Inkscape) which is important when you're wanting to script it later.
For previous projects, I've had workflows where images were extracted from one place, added into existing SVG files and Inkscape was scripted to slice up and export sections into PNG files. I can't see a way to do anything similar with Affinity Designer.
Inkscape is what I always use for editing static SVGs. Not using it enough to become familiar with it myself, the interface is usually intuitive enough for me to guess my way to success.
My biggest gripe with inkscape is that it suffers from some sort of floating point precision error, when you do certain copy/paste/transformation operations it mercilessly outputs more digits of significance than are necessary, which bloats the text and peeves off someone who must obsessively keep their ml clean
And also the output png is sometimes unpredictable. I hate it when what's supposed to be flat-coloured in svg turns out to be this 'pixelated-swirl' in png. I also find minimising operations can reduce this effect.
I would guess it's just outputting the 16 or so (decimal) digits of a IEEE float using one of the round-tripable representations. Not sure what else would be reasonable. Could you round the output with some specialized tool?
Great tool, I used it to build image assets a couple years ago for a native android app and now use it for any diagrams I want to look particularly nice.
Experienced Flash developers would rasterize complex vector shapes on the first load to consume less CPU by raw vector rendering, especially animations. So it's still not a Flash replacement.
SVG has the opposite performance profile of Canvas.
SVG hits a performance ceiling as number of elements increases.
Canvas, since it's rasterized image can handle a rasterized representation of millions of SVG elements.
However as Canvas dimension increase, it will hit a performance ceiling.
In my experience, canvas 2D also has a number-of-elements performance ceiling if you're drawing things rather than using images, which feels like it defeats the purpose.
For example, try drawing hundreds of coloured rectangles per frame. Easy, right? If you're using WebGL, or any sensible graphics API, yes. If you're using canvas, the web-browser will parse and re-parse your colour expression CSS n times per frame. Enjoy your 100% CPU usage.
> has a number-of-elements performance ceiling if you're drawing things rather than using images, which feels like it defeats the purpose.
Well you can generate your imagery programmatically and then render it to canvas as a raster image. Canvas is not purely for implementing a web based drawing app.
when you are faced with between rendering hundreds of thousands of SVG DOM element vs in memory generation of a final raster image, the latter will always be more performant.
Basically, canvas performance depends a lot on how many pixels you draw and how you draw them (blitting an image vs. drawing a gradient are very different things, obviously).
SVG performance depends on how many things in the DOM are changed at the same time (and then it's mostly dependent on how well the browser can avoid redraws – that's an area where we frequently encounter bugs when either too much or too little is redrawn). A large static image¹ manipulated only via affine transforms performs quite well; an image containing lots of different things that all vary constantly is bad. But as long as the viewport isn't too large, canvas can be a viable alternative to SVG if the visualization is simple.
This comes up on each SVG thread and I post the same comment each time (so excuse me if you've heard this from me before).
We render SVG that contain beyond 100k nodes in the browser and find that it works fine. You need to be careful with your manipulations and we've developed a couple of tricks to keep things snappy, but the final experience is great.
There's not a specific ceiling. This morning I did a quick test with 400k nodes and we sometimes get 2-3 million or more.
We only use chrome because Firefox struggled in the initial testing. Having said that, I haven't tried in anything other than chrome in ages and I'd wager the situation has changed a lot in the last couple of years.
No, in our case they're all unique elements - unfortunately for me! That demo example is actually much smaller though (2k nodes).
Here's an example with over 150k nodes [1]. To be honest, we would normally doctor documents that had this many nodes to make the experience smoother for users. You'll notice that it's a bit sluggish when you zoom in and out, but panning is the same speed regardless of number of elements, and updating elements within the document is fast too.
You can use something like `transform:translateZ(0px)` to force a subsection of the dom to exist on its own rendering layer. Then you can transform the parent nodes and they'll move the lower layer around as if it were a static picture that they don't need to redraw. I'm not sure how well this works within an svg, but you can certainly use it to do your transformations outside the svg.
ok i dug out the project I was thinking of and I was wrong - performance is fine at 10k nodes. adding translateZ causes a slight delay after changing the transform matrix while it re-renders the bitmap, and you see the switch - thanks for the advice
Choice between SVG and Canvas comes down to a balance between performance and interactivity, IMO. It is very easy to attach events and create interactions with a SVG object -- much harder to do that in Canvas (basically, you have to keep track of everything that was drawn). The flipside is, Canvas it effectively a bitmap, doesn't care what the pixels are, so the complexity is a constant regardless of what is drawn. SVG renderers will start to bog down once there are "too many" elements.
While SVG can do a lot, there are certain things that it isn't optimized for. In particular animating lots of shapes simultaneously. The animation of the globe exploding into a bunch of triangles from the slides is a good (bad?) example of this. Also, there can also be inconsistencies is in the rendering of SVGs between browsers.
Ironically we found that IE had the best SVG performance for quite a while (by now the others have mostly caught up). And then they broke a lot of things behaviour-wise in Edge again for quite some time. Performance was still great, but if your image doesn't look like it should it doesn't help.
I use svg all the time to make tiny web interfaces for embedded systems. When the entire web app has to fit in 350k, you don't have space for gif's or jpg's.
Had to do almost the same thing in 2013 with internet lightbulbs. I had to draw a page without buffering as even page's full html was bigger that MCU's ram
If your embedded system only has 350 kB of space for your app how on earth do you fit a browser in there? Or do you only use the 'static' features of SVG?
Usually this is done in a 'Bring Your Own Device' scenario, where the user has a standard mobile/tablet that the UI is shown on.
Using a webapp served by the embedded device allows a zero-install workflow, and zero-config (assuming network connectivity is taken care of).
The most impressive rabbit I've pulled out of the SVG hat in this regard is being given a 2.1MB logo and told that it had to appear full screen during the log in and be "crisp and not all jaggy".
Logos are typically shipped in SVG or Adobe Illustrator format aren't they? Even the old style ones had technical specifications. Seems odd you'd have to hand trace a JPEG.
All the kb saving are meaningless with performance issues caused by lots of nodes, gradients, etc.
It's great for responsive icons, but for a full interactive UI with illustrations bitmaps are the better choice IMO unless you really need dynamic scaling.
Just because you can do it doesn't mean you should.
Beware of using it for responsive icons. Popular browsers render SVG icons orders of magnitude slower than fonts, with the same vector content and scalability.
I recently had to convert an entire UI from SVG icons to fonts + bitmaps because the performance had gone down the drain, with just a few dozen different icons.
It's awesome. last time, I using SVG to import image to pdf files (using TCPDF). The quality is clearly & beautiful. Now, Thank you for your introduction about another things SVG can do on the website.
I've used SVG to design custom PCBs using traces as magnetic coils, something that, surprisingly, doesn't have a good industrial software package for. Everything in PCB design software is geared toward routing wires conveniently between components, but if you try to actually use the wires as actual components, it's almost impossible to freely design. And even regular PCB design software feels almost unchanged since the 1980s or 1990s. Incredibly clunky.
I had a hard time with all these packages, however, and ended up just hacking it together by hand with python code and outputting in KiCAD format. I wasn't even able to get KiCAD to read/render it properly (too many weird elements), but since OSH Park (where I got my PCBs from) takes KiCAD format directly and gives you a preview, that all worked fine, and when I ordered my PCBs, they arrived in working condition just fine the first time.
Altium can do that sort of thing fairly easily. We use it for boards with waveguide filters, couplers, etc. (usually the geometry is designed and simulated in a field solver first, and then imported in, but you can do it straight in the software if you want).
The easiest way is to design the coil as a part, but you can use traces and arcs and stuff like normal in that.
That works well if your coil component is small and is just acting as a microwave RF component or something, but in my case I had a pretty complicated coil design (although simple conceptually) that spanned the entire PCB and interwove with other coils and wasn't arranged in a simple rectilinear manner. My original plan was to design the whole thing in Solidworks, which I did (and it was pretty easy to do), but there was simply no easy way to convert that into an actual PCB for manufacture (there is a Circuitworks module, but it's designed only for importing circuits to design around in Solidworks, not the other direction). Sitting there and manually making arcs and such in the PCB design software was just a non-starter. There are no parametric modeling features to speak of, and it's actually way easier to do what I did.
We have it specified by now at least with SVG 2, but browser vendors have made it clear that they don want to support it at all, presumably because SVG 1.1 works well enough as a vector image format and more complexity and features could just be added by scripting. It felt a lot like browser vendors don't care about SVG at all beyond the extent that it's implemented at the moment.
They also tend to break non-static SVG things all the time which further suggests that things like applications or animations built with SVG are definitely not a use case they cater for (or that those things are simply very rare on the top 500 sites they test).
You can embed HTML within SVG via SVG's foreignObject, and use HTML/CSS text flow layout within embedded HTML. But it works only on rectangular shapes, and not on IE.
I wonder if we should encourage print designers to switch to svg (that is, if they don't already... it's not a world I know much).
I have in mind all those concerts or various events' png/jpeg files that are dropped on the web here and there. If they were svg files, it would be made easier for search engines to index their content.
Even without that, svg totally rocks. About a decade ago, I played with SVGWeb and made a showcase carousel presenting screenshots of projets with automated reflection on them (like it was common back then, a reverse image on bottom of actual image with a gradient from transparency to white to make an effect like if the ground was a mirror). I just had to upload a plain screenshot and everything was automated, I was mind blown, and surprised we seemed to go the canvas way instead (not so much, in retrospect).
Nowadays, I often make my icons as svg react components. It makes it so much easier to change their color or saturation on hover, this is very cool. We probably still have a long way to go to exploit all of svg potential.
If they're designing in Illustrator as most are they're usually working with vectors and have to use export to create their PNG/JPEG; SVG is right there as an export option. In my experience there's heavy inertia in the world of print though.
The SVGO-GUI has not been updated since 2015. I added out-of-the-box SVG optimization to my Optimage [1]. Fun fact: Node.js binary can be just 3MB compressed. ImageOptim [2] handles SVGs as well if Node.js is installed.
The transparent JPEG-in-SVG files can also be made with nothing but ImageMagick and Bash [3].
Have not seen anyone mention it, but does it make sense to do Web Game development using SVG's with JavaScript? Has anyone tried this? Is it as fun as these slides make it seem or are there downsides to that approach?
I think you'd want to combine it with canvas to replicate Flash's cacheAsBitmap. As others have mentioned here though the decisions on where to use it (raster vs vector) and where not to use it need to be made carefully as your map of bits uses memory [(width x height x 3 or 4 for RGB/RGBA) bytes - soon adds up but maybe browser renderers optimise this somehow] in exchange for what you save on drawing calculations.
cacheAsBitmap brought a major performance boost to Flash when used wisely though. Maybe some libraries can handle this for you nowadays?
We attempted to do a complex animation in SVG and the primary complaint was that it killed the browser in terms of CPU and memory usage. Are we doing something wrong?
I had the same experience using SVG to render music notation. We hit a performance issue - high CPU usage, skips/stutters - with several hundred to a thousand nodes, some animated. Switching to canvas increased that limit, in that we were able to keep smooth rendering with larger documents.
The whole score was rendered as one SVG element, until we hit the performance limit. Now we're rendering each row of measures (a stack of staves) as a canvas element, and it performs much better for our purposes.
lots of svg elements animated in conjunction will surely have a negative performance impact. At work we created a mind mapping tool, in where every node has events (drag, click, raggin, dragend, contextmenu, etc). After 200+ nodes the performance hit was very high. We had to stop redrawing the whole graph after every interaction. What a bummer.
The text is all there, isn't? The first demo I liked at used svg to rearrange the page, but all the text would render like normal. Probably even works with a text only browser.
This is a very inspirational presentation. I'm blown away. SVG can be the solution our next wave of interaction now that Flash has almost completely died.
1. SVG has all these seemingly useful features that have non-obvious gotchas. Example: you can give rendering hints for svg or any child shape nodes, like "crispEdges" so that straight lines are aligned to the pixel grid (plus it might turn off anti-aliasing, but that's another matter). Great-- I've got boxes with 1-pixel borders that should always be pixel aligned to look sharp, so I choose that.
Then I notice that when I drag one of my "crispEdges" boxes to the right with the mouse, I get this weird flickering due to the "crisping" algorithm aliasing the sides of the box to the pixel grid in a way that changes the width of the visible box. (I.e., if I move the box 1 pixel to the right, the left side might align to the grid that is greater than xpos, while the right side might choose the grid that is floor(xpos).) As a result it looks like the box is "crawling" across the screen, or up the screen if you drag it vertically.
So I went back to manually aligning those boxes to the pixel grid to guarantee consistent box size.
2. The "paint server" concept is an over-engineered mess. It's incompatible with CSS gradient spec which makes it a pain to figure out how to make CSS and future of SVG play well. Sane frameworks like Snap.svg abstract away that and anything else you'd likely find inside <defs> tags. (Also, someone here on HN mentioned that <defs> junk depends on the id to reference content, which easily creates nameclashes if you use multiple inline svgs.)
3. There's some churn in the DOM interface for SVG-related utils. For example, at some point I wanted to get access to normalized path instructions for a given SVG path. But Chrome recently deprecated the old way of doing that and is in the midst of replacing it with a new geometry interface.
4. The syntax for specifying an arc inside an SVG path is weird. Like, so weird that code in an SVG library I read obviously just went straight through the instructions listed in F.6.4/F.6.5 of the SVG spec (using the exact same variable names) to simply hand off the values to Cairo, and the library still had a bug somewhere. That one isn't really a big deal-- I'm just fascinated by how the spec writers favored endpoint parameterization consistency over the user's ability to draw a pie chart without having to ask questions on StackOverflow.
5. The complexity of the spec and its interaction with the other HTML5 specs is obviously a pain point for browser devs. Sometimes I use devTools to make a quick-and-dirty realtime codepen inside about:blank which just parses a contentEditable div and injects it as innerHTML of an SVG. It's nice because you can prototype things with patterns and gradients quite easily this way. Except you can't reference gradients/patterns/etc. in Firefox this way because of god-knows-what-conflict between about:blank's baseURL and SVG's funcIRI. (Although you can base64-encode the data and inject it as the src of an img under Firefox.)
You see things like that all over. For example, the burgeoning web animations API looks really nice and works with SVG. But it works on CSS properties and not SVG attributes.
Wow, svg sits there and does mostly nothing on my phone. Just like Flash! Can't pinch to zoom to read the text that was too small, just like Flash! Half the supposedly neat interactive gewgaws like "turn this gear" didn't react to any presses or gestures at all. Just like Flash!
Events can be attached to SVG elements just like any other element in the dom. Pinch to zoom / pan etc can all be implemented fine. Your complaints might hold true with certain demos, but they're not limitations of SVG
Flash has the "advantage" that it's used almost exclusively for advertisments. Mostly pretentious people (artists, photographers etc) have websites made of flash. So, by turning off Flash, you block the bulk of annoying ads. And you lose little by disabling Flash.
Would the same be true for SVG ? Would it be used mostly for ads, too ? Or even, can you selectively block only the SVG used for advertisments ?
Of course the opposite is actually a brilliant idea (at least at a time when XML was still popular): Take an XML dataset and visualise it in SVG using XSLT transformations (well... yeah... doing it all in XSLT is still insane, but you get the idea).
Anyway, we built a very high performance SVG viewer (for the time, anyway) from scratch. We built an SVG/Javascript widget library. We built an incredibly impressive data manipulation library in XSLT (ok... yeah... insane).
Fun times. And all nearly 20 years ago. It really was ahead of its time. Of course the end finally had to come. The PGMs sold this thing to a certain aviation company with the promise that it would automatically build circuit diagrams from their XML chipset database (because.... XSLT!)
When Vector took over Corel, they very rightly dropped our division like a hot potato (we had something like 3 PGMs per developer). It was quite unfortunate because the developers and QA people I worked with there were some of the best I've every had the pleasure of working with. I've always waited for something to come of SVG and really wish we had been able to release something that wasn't crazy so that people could see what the potential was.
Edit: In my old age I'm losing track of time. It seems that Vector acquired Corel in 2003, so that's only 15 years ago :-)