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.
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.
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.
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
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.
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.
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).
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.
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.
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
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.
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.
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.
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.
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.
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).
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.
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.")
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.
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
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?
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.
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.
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.
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?
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.
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.
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.
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.
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)
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 :)
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.
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/
> 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.
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?
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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 :-)
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.
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.
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.
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'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.
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.
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.
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. :)
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?
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.
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.
201 comments
[ 7.0 ms ] story [ 209 ms ] threadHave you ever looked at a text dump of a PDF?
Assuming it's a text-PDF in the first place, there's no guarantee that it's in any sensible order.
Of course, most Web writing is pastiche anyway.
They will if more people use it.
SVG in Chrome can be particularly painful due to their mediocre support of some things (sometimes outright contradicting the spec).
That’s a vendor issue tho, nothing intrinsic to the format.
Or advanced CSS.
- loading bar until website is fully loaded
- animated buttons that bounce and flash
- full screen 2 second transitions from page to page
- all in one page, no urls!
feels like 2010 again : ]
Did it in about 900 bytes.
HTML plus 11 images in just 26KB.
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.
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.
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.
Rasterizing expensive operations before drawing to screen is usually job one of a rendering pipeline
Rasterising ahead-of-time is all well and good, but it's not something you should have to employ just to draw simple polygons.
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.
Here's a demo of it in action with a smaller SVG
https://www.countfire.com/product-demo/
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.
[1] https://www.dropbox.com/s/xf89s2txvp9jb3k/Big%20SVG%20%28150...
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.
That's one of the issue i have with SVG browser implementation varies so much. Our product that is performant in Chrome sucks in IE11
What's the slow bit in IE? Is it the svgs?
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.
¹ Unless written like this one: https://upload.wikimedia.org/wikipedia/commons/4/4e/Sierpins...
Some gotchas:
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.
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).
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.
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 still here! It's now branded Animate CC[1], and (naturally) focuses on other output formats.
[1] http://www.adobe.com/products/animate.html
The product itself can export to SVG (https://helpx.adobe.com/animate/how-to/export-image-svg.html), but I get the impression that's only for individual frames.
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.")
Also what does "ml" mean?
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.
Shameless plug, one of my first experiments with SVG+react (+cljs): https://polymeris.github.io/carlos/ Done in one day, without knowing the tech.
[core.cljs] https://github.com/polymeris/carlos/blob/master/src/carlos/c... and [svg.cljs] https://github.com/polymeris/carlos/blob/master/src/carlos/s...
Look clear enough for me to follow. Thank you.
Will work on this, too:
* edit: clearer even unrenderedFor anybody interested in some example code mixing React and SVG the PipelineGraph component is here: https://github.com/jenkinsci/blueocean-plugin/blob/master/je...
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)
http://celtic-knotwork.online
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.
But I could also say these were minor quibbles.
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.
[0] http://linnarssonlab.org/flamemaps/
does it? Any examples of responsive grid system on SVG? What would be interesting.
SVG can't be, shouldn't be and never will be the replacement for HTML/CSS/JS.
It's called the [Bellamy salute](https://en.wikipedia.org/wiki/Bellamy_salute), which is based on the [Roman salute](https://en.wikipedia.org/wiki/Roman_salute). For those that want to know more :)
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.
https://www.w3.org/TR/SVGTiny12/styling.html https://www.w3.org/TR/SVGTiny12/script.html
nanosvg is pretty good:
https://github.com/memononen/nanosvg
https://github.com/ajstarks/svgo https://speakerdeck.com/ajstarks/svgo-code-plus-picture-exam...
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.
https://github.com/GNOME/librsvg
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.
This means it is inevitable that SVG should be Turing-complete.
And even so, it still has no hairline. All line widths are finite and change when zooming.
It's implemented as vector-effect: vector-effect="non-scaling-stroke"
There's an example here https://gist.github.com/lightjs/5372867
https://github.com/openfl/svg
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.
What about as part of a text format? Would anyone find that useful?
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 :-)
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.
1: https://en.wikipedia.org/wiki/Program_management
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.
Hope that was more understandable/informative!
It's not without its wobbly bits, but show me a language that isn't.
I don't think I agree about responsive css, but that's another discussion.
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.
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.
[0]: https://github.com/lovullo/tame [1]: https://github.com/lovullo/liza-proguic/tree/master/src [2]: https://github.com/lovullo/literate-xsl with example output https://mikegerwitz.com/hoxsl/manual/
cacheAsBitmap brought a major performance boost to Flash when used wisely though. Maybe some libraries can handle this for you nowadays?
Unless I misread it?
Totally agree with you!
ImageTracer is a simple raster image tracer and vectorizer that outputs SVG, 100% free, Public Domain.
Available in JavaScript (works both in the browser and with Node.js), "desktop" Java and "Android" Java:
https://github.com/jankovicsandras/imagetracerjs
https://github.com/jankovicsandras/imagetracerjava
https://github.com/jankovicsandras/imagetracerandroid
[1]https://vectormagic.com/
Inkscape calls Potrace, but you can you use Potrace directly from the command line, too.
https://en.wikipedia.org/wiki/Potrace
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.